You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Similar to #384, would be nice to have a virtual inheritance or templated base class for etl::message_router as well.
This would allow to create custom interface classes for certain kinds of routers.
For what I saw having a templated base class as for etl::message won't work with the pre-C++17 implementation, because supposedly the template argument for the base class should have a default value and that requires a specific ordering of such arguments.
Probably the virtual inheritance solution would work. Why was it discarded for the related issue?
The text was updated successfully, but these errors were encountered:
I wasn’t clear enough with that statement.
I wanted to say that the solution for selecting a custom base class, existing for `etl::message`, which provides an optional template argument for specifying the base interface, won’t work in the case of `etl::message_router`, because the latter has already many optional template arguments (in the pre C++17 version).
—
Edoardo
On 27 Jan 2024 at 11:02 +0100, John Wellbelove ***@***.***>, wrote:
For what I saw having a templated base class as for etl::message won't work with the pre-C++17 implementation
Did you mean etl::message_router?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
Similar to #384, would be nice to have a virtual inheritance or templated base class for
etl::message_router
as well.This would allow to create custom interface classes for certain kinds of routers.
For what I saw having a templated base class as for
etl::message
won't work with the pre-C++17 implementation, because supposedly the template argument for the base class should have a default value and that requires a specific ordering of such arguments.Probably the virtual inheritance solution would work. Why was it discarded for the related issue?
The text was updated successfully, but these errors were encountered: