Re: [boost] [typeof-users] Looking for a consistent scheme for adding Typeof support to Boost libraries

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
>>described above)!
> 
> 
> 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

     boost/<LIB>/a.hpp
     boost/<LIB>/a/a1.hpp
     boost/<LIB>/a/a2.hpp
     boost/<LIB>/b.hpp
     boost/<LIB>/b/b1.hpp
     boost/<LIB>/b/b2.hpp
     boost/<LIB>/typeof/boost/<LIB>/a.hpp
     boost/<LIB>/typeof/boost/<LIB>/a/a1.hpp
     boost/<LIB>/typeof/boost/<LIB>/a/a2.hpp
     boost/<LIB>/typeof/boost/<LIB>/b.hpp
     boost/<LIB>/typeof/boost/<LIB>/b/b1.hpp
     boost/<LIB>/typeof/boost/<LIB>/b/b2.hpp

a directory structure like this does (although it won't allow to switch typeof 
support on and off on a per-library basis) too

     boost/<LIB>/a.hpp
     boost/<LIB>/a/a1.hpp
     boost/<LIB>/a/a2.hpp
     boost/<LIB>/b.hpp
     boost/<LIB>/b/b1.hpp
     boost/<LIB>/b/b2.hpp
     typeof_support/boost/<LIB>/a.hpp
     typeof_support/boost/<LIB>/a/a1.hpp
     typeof_support/boost/<LIB>/a/a2.hpp
     typeof_support/boost/<LIB>/b.hpp
     typeof_support/boost/<LIB>/b/b1.hpp
     typeof_support/boost/<LIB>/b/b2.hpp

a directory structure like this

     boost/<LIB>/a.hpp
     boost/<LIB>/typeof/a.hpp
     boost/<LIB>/a/a1.hpp
     boost/<LIB>/a/typeof/a1.hpp
     boost/<LIB>/a/a2.hpp
     boost/<LIB>/a/typeof/a2.hpp
     boost/<LIB>/b.hpp
     boost/<LIB>/typeof/b.hpp
     boost/<LIB>/b/b1.hpp
     boost/<LIB>/b/typeof/b1.hpp
     boost/<LIB>/b/b2.hpp
     boost/<LIB>/b/typeof/b2.hpp

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

    #include <../../../boost/<LIB>/whatever.hpp>

(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...

Regards,

Tobias