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>
^^^^ 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 -):
+ 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
+ library authors can freely choose the granularity level for doing the
+ it can be used in combination with #1 in cases where more fine grained
control over Typeof support makes sense
- it's quite complicated
+ it's very simple
- only global support is possible
- it uses a macro for the configuration
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk