From: Ivan Godard (igodard_at_[hidden])
Date: 2005-08-04 22:22:49
May I suggest that the type_traits identifiers all be placed in a
boost::type_traits namespace, with one indirect #include file to grandfather
existing usage?
The added file, say hide_type_traits.hpp, would include all the detail .hpp
files the way that type_traits.hpp does now. The individual detail files would
wrap each API declaration in "namespace type_traits{...}". The present
type_traits.hpp would simply:
#include "hide_type_traits.hpp"
namespace boost {
using namespace type_traits;
}
The effect is that current usage will still work if you include type_traits.hpp
as at present, but those of us who want the type_traits names (bit not the rest
of boost) in the file namespace can do a "using boost::type_traits;" to achieve
that.
What prompts this note is a desire to prepare for TR1 while continuing to
support old compilers. We attempted to say (in a file included when using an
older compiler):
namespace std {
#include "boost/type_traits.hpp"
}
so that the boost type_traits identifiers would appear in the std namespace
under an old compiler just as they would in a compiler that implements TR1.
However, this blows up because the boost type_traits library transitively
includes other boost stuff it uses, and that stuff does *not* like to be in std
:-)
Of course, we could leave all the identifiers in the boost space and pick them
out one by one with using statements; that's in fact what we are doing. But
that means we have to track your library with our using's, a maintenance
nuisance.
Lastly, may I suggest that future libraries with lots of identifiers should
routinely use a per-module namespace, like the mpl library does now? That would
obviate this nuisance should the library later be standardized.
Ivan