Arkadiy Vertleyb wrote:
"Tobias Schwinger" <tschwinger@neoscientists.org> 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
"Tobias Schwinger" <tschwinger@neoscientists.org> wrote library
in between user and Boost code.
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
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
In my above statement replace "Spirit" with "third party library". What is going to change? path, 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.
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
OK, understood. 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: