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 07:11:05

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

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

And we can optimize boost/<LIB>/typeof/h.hpp to look like

   // Include Typeof
   #include <boost/typeof/typeof.hpp>
   // this header ^^^ should contain "#pagma once" for gcc >= 3.? and MSVC

   // Dependencies
   // (do not read and preprocess lots of files that will be empty anyway
   // for natively supported typeof)
   #if !defined(BOOST_TYPEOF_NATIVE)
   #include <boost/<LIB>/typeof/h1.hpp>
   #include <boost/<LIB>/typeof/h2.hpp>
   #endif

   // Original file
   #include <boost/<LIB>/h.hpp>

   // Registration
   BOOST_TYPEF_REGISTER_*

, though.

Regards,

Tobias