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

From: Arkadiy Vertleyb (vertleyb_at_[hidden])
Date: 2006-01-21 14:56:42

"Tobias Schwinger" <tschwinger_at_[hidden]> wrote

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

In my above statement replace "Spirit" with "third party library".  What  is
going to change?

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

OK, understood.

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

I don't think I like this.  Somehow I am not really comfortable with the
idea of using the include path to "trick" the compiler into including the
registration file when it seems from the code that just the regular header
is included...

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

It would be helpful to also get the opinion of other library authors that
are planning/considering to add typeof support to their libraries.  After
all, Boost libraries are maintained independently, and, in order to
implement any effective policy, we need to reach a consensus.

Regards,
Arkadiy
>
>
> Regards,
>
> Tobias
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>