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
For 1, ProgOptions can be made a forward declaration, but at at a price of forcing user to include ProgOptions.h wherever fConfig or GetConfig are used, which in majority of cases will be a small breaking change (due to missing include statements on user side).
For 2, I can actually remove Properties class entirely from FairMQChannel, it will only involve small amount of refactoring.
Ideally we would hide boost::signals from EventManager, but I don't see how it can be done, because the template types it takes propagate through to the user interface. Same thing goes for hiding EventManager in ProgOptions/Properties.
What do you think?
We also should consider the trade-off between compile time and potential runtime optimizations compiler can make. For config code this is probably not critical, but we don't have precise measurements for this atm.
The text was updated successfully, but these errors were encountered:
Let's think how we can get rid of boost::signals in EventManager. If we switch to C++17 now anyways I am sure we have enough tools to re-implement it much more lightweight.
@dennisklein My thoughts on this comment.
The question is if
boost::signals
can be hidden from public headers (or specificallyFairMQDevice.h
).boost::signals
propagates toFairMQDevice.h
through:FairMQDevice.h --> ProgOptions.h --> EventManager.h --> boost::signals
,FairMQDevice.h --> FairMQChannel.h --> Properties.h --> EventManager.h --> boost::signals
.For 1,
ProgOptions
can be made a forward declaration, but at at a price of forcing user to includeProgOptions.h
whereverfConfig
orGetConfig
are used, which in majority of cases will be a small breaking change (due to missing include statements on user side).For 2, I can actually remove Properties class entirely from FairMQChannel, it will only involve small amount of refactoring.
Ideally we would hide
boost::signals
fromEventManager
, but I don't see how it can be done, because the template types it takes propagate through to the user interface. Same thing goes for hidingEventManager
inProgOptions
/Properties
.What do you think?
We also should consider the trade-off between compile time and potential runtime optimizations compiler can make. For config code this is probably not critical, but we don't have precise measurements for this atm.
The text was updated successfully, but these errors were encountered: