Boost logo

Boost :

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

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

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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at