From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2006-01-21 10:55:06
Arkadiy Vertleyb wrote:
> "Tobias Schwinger" <tschwinger_at_[hidden]> wrote
>>They definitely should (although it won't solve the hypothetical problem
> Why not? I don't understand... If, for example, a Spirit header includes
> an MPL header, the corresponding Spirit registration header would include
> the corresponding MPL registration header.
> So, if I include the Spirit registration header, I automatically get needed
> MPL types registered, won't I?
Spirit and MPL are both part of Boost. I was talking about a third party library
in between user and Boost code.
> I think we pretty much have two main alternatives now (if I am missing
> something, please correct me):
> 1) The user gets typeof support for the whole project _automatically_
> (possibly after defining some preprocessor constant, changing include path,
> etc.). The main drawback here seems to be the price to pay for inclusion
> typeof headers and registering types even in the translation units that
> never use typeof.
> 2) The user has to explicitly specify where he wants to use typeof (probably
> by the means of including registration headers instead of regular library
> headers). This does introduce some extra work, since as typeof is applied,
> the #include statements need to be modified. But, in general, this approach
> gives a more fine grain control over where typeof is included, and so will
> probably result in faster compiles (although I can't claim I have any idea
> on how noticable this will be).
The post starting this discussion branch was about considering to allow 1) as a
special case of 2).
A directory structure like this could allow it
a directory structure like this does (although it won't allow to switch typeof
support on and off on a per-library basis) too
a directory structure like this
does not. I'm not at all sure it's a good idea in the first place. Further the
former two alternatives require us to
(that is if the include dir switch should work) and I don't know whether this is a
clean solution, either.
However, I think we should carefully investigate opportunities like this one
because once we decide on something we should stick to it. If there's written code
it will be tedious work to change it...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk