Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Executor doesn't implement cetl::rtti #398

Open
thirtytwobits opened this issue Nov 14, 2024 · 2 comments
Open

Executor doesn't implement cetl::rtti #398

thirtytwobits opened this issue Nov 14, 2024 · 2 comments
Assignees

Comments

@thirtytwobits
Copy link
Contributor

For example: https://github.com/OpenCyphal-Garage/libcyphal/blob/main/include/libcyphal/executor.hpp#L108
We have the same methods defined but they are not virtual and the cetl::rtti interface is not used.

@serges147
Copy link
Collaborator

serges147 commented Nov 14, 2024

The line you mention is not really about IExecutor but its Callback::Interface. But you are right - I need review all places where rtti is implemented. The reason why it's working currently (and not causing any problems I'm aware of) is b/c cetl::rtti_cast<> implementation is not requiring currently to inherit from cetl::rtti interface - @pavel-kirienko Pavel, is it a feature or a bug? ;)
IMO on one hand it could be a feature, namely:

  • if you have very strict and predictable scenario from which type to what type you gonna rtti_cast
  • then you don't really need it be polymorphic - executor's callback stuff proves it (for better or worse)

On the other hand, it is probably not good that we have rtti interface defined but don't enforce it properly... f.e. if I add to the interface a new pure virtual method then I would expect to see compilation failures about classes being abstract...

@pavel-kirienko
Copy link
Member

That interface is mostly needed for the rtti_helper, so consider it a feature. We should implement that interface at least for regularity, though (making it final to avoid vtable lookup overheads where possible).

@serges147 serges147 self-assigned this Nov 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants