Arkadiy Vertleyb wrote:
"Tobias Schwinger" <tschwinger@neoscientists.org> 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