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 09:43:27

"Tobias Schwinger" <tschwinger_at_[hidden]> wrote

> Arkadiy Vertleyb wrote:
> > "Tobias Schwinger" <tschwinger_at_[hidden]> wrote
> >
> >>Say I have an existing project and want to start using Typeof. There
might me a
> >>lot of already-written source code and I'd have to change all the
includes therein
> >>that refer to the libraries I want Typeof support for.
> >>As an end user, I would definitely prefer changing my include directory
over
> >>changing all the includes (especially considering your own point that
the Typeof
> >>library is only a temporary solution).
> >
> >
> > OTOH, it doesn't seem very likely that somebody would need such a global
> > one-time switch to typeof support.
> > Most likely typeof is going to be introduced gradually, as new features
> > are added, and the old ones are re-factored.
>
> The assumption is based on ... ?

I think we are talking about a large project (for small projects almost any
strategy will be fine).  In such large projects big amount of code is never
touched.  So, if somebody is working with some particular piece of code, and
wants to use (or try) typeof for it, why rebuild everything?  Also, even
though the inclusion of typeof is quite cheap now (especially after your
last improvement), it still has some price (mostly related to the
preprocessing).  Why pay this price compiling files that don't use typeof?

> I guess here's a misunderstanding: my argumentation comes from an
end-user's
> perspective (I'm not talking about library development).

I understand this.

> An exemplary use case could be to optimize an existing Spirit parser with
Typeof.
>
> > In such case changing the include dir would cause undesirable
> > rebuild of the whole project.  It's easier to imagine the global
backward
> > switch from typeof, though...
>
> A rebuild should still be faster (and more fun -- get some coffee ;-) )
than
> manually applying repetitive changes. If it's not, your project is
probably too
> large and you should factor something out into a library.
>
> >>The situation becomes even more delicate if I use a library that in turn
uses a
> >>some part of Boost. Now I can either go through the foreign code and
figure out
> >>what needs to be included or include Typeof support for the whole part
of Boost my
> >>library depends on.
>
> Just to ensure we understand each other correctly:
>
>     Boost.<LIB>
>        ^
>        |
>     third pary library (externalizes types from Boost.<LIB>)
>        ^
>        |
>     user code (wants to use Typeof on the types externalized by the
library)
>
>     (the arrow denotes a "depends on" relationship)
>
>
> > Can the registration headers mirror dependency structure of the original
> > files, such as:
> >
> > boost/<LIB>/h.hpp
> >
> > #include "boost/<LIB>/h1.hpp"
> > #include "boost/<LIB>/h2.hpp"
> > ...
> >
> > boost/<LIB>/typeof/h.hpp
> >
> > // include original file
> > #include "boost<LIB>/h.hpp"
> >
> > // register types in the original file
> > REGISTER_TYPE...
> >
> > // register included types
> > #include "boost/<LIB>/typeof/h1.hpp"
> > #include "boost/<LIB>/typeof/h2.hpp"
> >
> > ?
>
> 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?

===

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

Regards,
Arkadiy