boost::detail namespace
Hi, Most boost projects use boost::detail namespace to implement hidden, private functionality. What prevents name clashes in that namespace? Marcin
From: "Marcin Kalicinski" <kalita@poczta.onet.pl>
Most boost projects use boost::detail namespace to implement hidden, private functionality. What prevents name clashes in that namespace?
Many libraries create a detail namespace within their own namespace. Those that put their code directly into the boost namespace won't necessarily have a separate detail namespace. Then again, they already have to be careful with name clashes. Some libraries, however, have their own namespace but put things into boost::detail. Those libraries can have or contribute to clashes. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Rob Stewart <stewart@sig.com> writes:
Some libraries, however, have their own namespace but put things into boost::detail. Those libraries can have or contribute to clashes.
What libraries are doing that? The authors might need a dope-slap. I hope it's not one of mine! ;-) -- Dave Abrahams Boost Consulting www.boost-consulting.com
From: David Abrahams <dave@boost-consulting.com>
Rob Stewart <stewart@sig.com> writes:
Some libraries, however, have their own namespace but put things into boost::detail. Those libraries can have or contribute to clashes.
What libraries are doing that? The authors might need a dope-slap. I hope it's not one of mine! ;-)
This isn't exhaustive, but here are a few examples that I found (I tried to skip related matches): detail/atomic_count.hpp:83 detail/binary_search.hpp:34 detail/call_traits.hpp:32 detail/compressed_pair.hpp:39 detail/dynamic_bitset.hpp:26 detail/lwm_nop.hpp:23 detail/named_template_params.hpp:21 detail/quick_allocator.hpp:33 detail/shared_count.hpp:40 graph/adjacency_list.hpp:230 iterator/counting_iterator.hpp:24 pool/pool.hpp:71 test/execution_monitor.hpp:51 thread/condition.hpp:31 type_traits/add_pointer.hpp:19 utility/enable_if.hpp:78 The following are examples in which another namespace is created inside boost::detail rather than a detail namespace within the library namespace. This keeps the names separate, but still seems inverted. detail/allocator_utilities.hpp:23 function/function_base.hpp:106 multi_array/algorithm.hpp:46 variant/get.hpp:59 -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Rob Stewart <stewart@sig.com> writes:
From: David Abrahams <dave@boost-consulting.com>
Rob Stewart <stewart@sig.com> writes:
What libraries are doing that? The authors might need a dope-slap. I hope it's not one of mine! ;-)
This isn't exhaustive, but here are a few examples that I found (I tried to skip related matches):
detail/atomic_count.hpp:83 detail/binary_search.hpp:34 detail/call_traits.hpp:32 detail/compressed_pair.hpp:39 detail/dynamic_bitset.hpp:26 detail/lwm_nop.hpp:23 detail/named_template_params.hpp:21 detail/quick_allocator.hpp:33 detail/shared_count.hpp:40 graph/adjacency_list.hpp:230 iterator/counting_iterator.hpp:24 pool/pool.hpp:71 test/execution_monitor.hpp:51 thread/condition.hpp:31 type_traits/add_pointer.hpp:19 utility/enable_if.hpp:78
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. Whether or not enable_if should be in a subnamespace is a different fight. The same applies to iterator/counting_iterator.hpp, for example. The ones in detail/ are mostly components that were deemed to be of general utility within Boost but whose authors were not ready to give them a "public face" (i.e. review, documentation). They do not officially "belong" to any specific library and are often used across several libraries. Having them in boost::detail makes sense.
The following are examples in which another namespace is created inside boost::detail rather than a detail namespace within the library namespace. This keeps the names separate, but still seems inverted.
detail/allocator_utilities.hpp:23 function/function_base.hpp:106 multi_array/algorithm.hpp:46 variant/get.hpp:59
Yep, that's a little weird. I can say from experience that in a subnamespace of boost it can be awkward to have both boost::subnamespace::detail and boost::detail in scope, so it is sometime better to use another name (like aux:: a la MPL). -- Dave Abrahams Boost Consulting www.boost-consulting.com
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. 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. Detail name clashes can be very frustrating because they only manifest when certain header file combinations are included into one translation unit. 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. cheers, Marcin
From: "Marcin Kalicinski" <kalita@poczta.onet.pl>
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. 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. Detail name clashes can be very frustrating because they only manifest when certain header file combinations are included into one translation unit.
The point you make is valid, but the problem is that those headers don't belong to a library. Still, detail/enable_if.hpp could fabricate detail::enable_if or something like that. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
"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
utf8_codecvt_facet is there. This is used by serialization and by program options but we couldn't convince anyone that it should be "promoted" to public status in spite of its demonstrated utility, correctness and documentation. This was the only "neutral" place for it. Prior to that it was duplicated in each library which was also deemed unacceptable. Vladimir and I are forming a line to get our "dope-slaps" Robert Ramey David Abrahams wrote:
What libraries are doing that? The authors might need a dope-slap. I hope it's not one of mine! ;-)
"Robert Ramey" <ramey@rrsd.com> writes:
utf8_codecvt_facet is there. This is used by serialization and by program options but we couldn't convince anyone that it should be "promoted" to public status
You proposed it for possible review and nobody was interested?
in spite of its demonstrated utility, correctness and documentation.
Wow. I don't know enough about facets (or, to be sure, Unicode) to be much of an authority, but it sounds important to me. I think it should get a review.
This was the only "neutral" place for it. Prior to that it was duplicated in each library which was also deemed unacceptable.
Vladimir and I are forming a line to get our "dope-slaps"
Sorry to dissapoint, but what you did is perfectly fine. utf8_codecvt_facet doesn't "belong" to either of those libraries. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On 8/18/05, Robert Ramey <ramey@rrsd.com> wrote:
utf8_codecvt_facet is there. This is used by serialization and by program options but we couldn't convince anyone that it should be "promoted" to public status in spite of its demonstrated utility, correctness and documentation. [...]
I wouldn't question utf8_codecvt_facet's utility, nor its documentation. I don't see why it shouldn't have gotten a review long ago. At the moment, however, Graham and I are making progress on a full Unicode library. We're of course hoping to submit this library-to-be for a review. This library will contain a UTF-8 codecvt facet (I've just finished writing it). It will have the advantage of a 32-bits internal type by default and nicely integrate with UTF-16, UTF-32, and byte order mark detection. (It will also be more conformant to the current Unicode standard by checking for the shortest encoding and restricting input and output to "Unicode scalar values".) In conclusion, assuming that we can really produce a Unicode library any time soon, this may not be the right time for submitting your utf8_codecvt_facet for review. (Whether the assumption is correct only time will tell, of course.) Regards, Rogier
"Marcin Kalicinski" <kalita@poczta.onet.pl> writes:
Hi,
Most boost projects use boost::detail namespace to implement hidden, private functionality. What prevents name clashes in that namespace?
Not much. Most boost projects should be doing most of their work in a subnamespace of boost anyway, so they should have boost::someproject::detail to protect them from name clashes. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (5)
-
David Abrahams -
Marcin Kalicinski -
Rob Stewart -
Robert Ramey -
Rogier van Dalen