|
Boost : |
From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2006-01-19 13:09:30
Arkadiy Vertleyb wrote:
> "Tobias Schwinger" <tschwinger_at_[hidden]> wrote
>>
>> // [...]
>>
>>--- at the end of every source file:
>>
>> #if defined(<LIB>_TYPEOF_SUPPORT)
>> # include <boost/<LIB>/typeof_support.hpp>
>> #endif
>
^^^^ The conditional could be factored out into another header file...
>
> OK, understand. The last lines above make this solution intrusive, and #3
> is intrusive as well...
>
Why is "intrusiveness" undesirable in this context?
> What are the drawbacks of #1?
OK let's summarize pro (donted by +) and contra (denoted by -):
1)
+ fine grained control for the user
+ global typeof support could be made possible by adding include
directory (when there is a 'boost' directory)
- it dictates the granularity and thus imposes a lot of work on the
library authors who want to add Typeof support
- we'll end up with a huge ammount of headers, each with a license
and an include guard and most of these headers will only contain one
or two lines of effective code, thus bloating up the Boost distribution
- the "non-intrusiveness" can be seen as a drawback, because the
otherwise there is a "reminder" to each header not to forget the
Typeof registration when changing things (granted, it's an arguable
point).
2)
+ library authors can freely choose the granularity level for doing the
registration
+ it can be used in combination with #1 in cases where more fine grained
control over Typeof support makes sense
- it's quite complicated
3)
+ it's very simple
- only global support is possible
- it uses a macro for the configuration
Regards,
Tobias
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk