
On 6/5/2016 5:55 PM, Rob Stewart wrote:
On June 4, 2016 10:59:16 PM EDT, Edward Diener
wrote: On 6/4/2016 9:28 PM, Rob Stewart wrote:
Edward, you've missed that Vicente doesn't see that importing either
a Boost or a Standard Library solution, into a common namespace requires anything more of the user.
The user would always use the new, common namespace name for
something, regardless of its original namespace. For example, foo::x is the common name, but x may have been introduced into the foo namespace, by a using directive, from the boost or the std namespace.
In the end, the user always includes the foo header and uses the foo
name. There are no macros in the user's code. Both solutions select one implementation or the other. Yours refers to the namespace of the selected implementation with a macro, while his just uses namespace foo.
It does involve more work and macros are still being used, although not
to name the namespace. I honestly think that CXXD's solution is cleaner
and more flexible. Lifting constructs which are normally accessed through one namespace to another namespace in that way seems to me a kludge. I am not sure of all the ramifications of doing this but I would be wary of doing such a thing myself.
You also don't have the technique of overriding the dual library choice
that you have with CXXD, unless you manually change some source, which you may not have access to in the first place. But if you think the CXXD macros are going to cause problems, just because they are macros and therefore "evil', by all means roll your own solution as Vicente has done.
See whether you still think so after reading my reply to Niall.
My thought is generally that CXXD represents the easiest approach and that importing either side of a dual library's namespace into another common namespace, no matter how it is controlled, does not represent anything better than what CXXD has to offer. Furthermore, although I haven't had the time or knowledge to work through all possible situations I believe that Vicente's approach could have problems involving customization points for a library, ADL, and/or template specializations. Vicente's approach is essentially changing the namespace in which constructs operate and any prior extensions to those constructs, in whichever side of the dual library is chosen, seem like they could be lost. The extensions will refer to a namespace in which the rest of the constructs are no longer operating or the extensions will be written in a namespace in which the rest of the constructs will no longer be operating. Either way I anticipate some C++ name lookup problems along the lines of using constructs in the common namespace no longer finding template specializations or extension points in a different namespace or referring, through ADL, to a different namespace. Of course I could be wrong about this and everything just "works" despite the different namespace in which all those constructs are now operating. But why deal with those possible problems in the first place. In CXXD the namespace stays the same and I think this is much safer. The fact that a simple object-like macro refers to the correct namespace at all times bothers me not at all simply because it is a macro.