"Marcin Kalicinski" <kalita@poczta.onet.pl> writes:
I can't speak for all of these, but some of them are libraries that don't have their own namespace (e.g. enable_if). As long as enable_if is directly in namespace boost, it makes sense that its detail is in boost::detail.
I don't subscribe to that. I think details of every distinct library should be in a separate namespace.
I agree, but until enable_if is moved out of namespace boost and the boost "utility library" umbrella, it isn't a distinct library. That's a separate (though real) problem.
The reason is detail stuff is not documented and changes frequently, so no library writer can actually add safely any new name to boost::detail. This means that boost::detail should not exist at all, unless it is used only by 1 library.
That leaves common implementation facilities that don't "belong" to any one library (e.g. detail/indirect_traits.hpp) out in the cold.
Detail name clashes can be very frustrating because they only manifest when certain header file combinations are included into one translation unit.
In theory. We haven't actually had a problem with it that I've noticed.
While libraries residing in boost::libraryname can use boost::libraryname::detail, the ones that are in boost namespace directly could safely use someting like boost::libraryname_detail.
Sure. But should anything really be in the boost namespace directly? I don't think very much should. I don't mind the idea of bringing some things in with using declarations, though. -- Dave Abrahams Boost Consulting www.boost-consulting.com