From: David Abrahams (dave_at_[hidden])
Date: 2005-08-19 11:02:02
"Marcin Kalicinski" <kalita_at_[hidden]> 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
> 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