Arkadiy Vertleyb wrote:
"Tobias Schwinger" <tschwinger@neoscientists.org> wrote
A single-rooted approach might still be better:
boost/a/typeof/boost/a/b/c.hpp
or even (although Arkadiy pointed out it would be less CVS-friendly)
boost/typeof_support/boost/a/b/c.hpp
Now I could switch my include path to contain boost/a/typeof or to boost/typeof_support respectively and thus enable typeof support for lib a without changing my source code (as suggested by Andy elsewhere in this thread).
Note that disabling typeof support seems to be easily achieved by just defining BOOST_TYPEOF_NATIVE, which forces all the registrations to be no-op.
Yeah, right. Although that's not quite the same, is it? 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). 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. Regards, Tobias