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
"Tobias Schwinger" <tschwinger@neoscientists.org> wrote 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).
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 ;-) )
manually applying repetitive changes. If it's not, your project is
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
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
I understand this. than probably too figure out 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