Boost logo

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