Boost logo

Boost :

From: Ed Brey (brey_at_[hidden])
Date: 1999-12-18 10:08:03


> From: John Maddock [mailto:John_Maddock_at_[hidden]]
> >The detail
> namespace should only ever be referenced by boost code, and so the
> reference will always come from within the "namespace boost {}"
> scoping, so even if there is a "detail" namespace at global scope, the
> boost::detail namespace will be unambiguously chosen over it.<
>
> Agreed, however the situation I envisioned was one where there was a class
> of the same name in ::detail and ::boost::detail - the user doesn't know
> about boost::detail - he/she wants the one in ::detail, but because he's
> added a "using namespace boost" declaration, both namespaces are in fact
> visible to him.

OK, but keep in mind then that the fact that _detail is reserved at the global
namespace is only a partial solution. A user class that would have a name
like "detail" is probably more likely to exist within a namespace anyway than
at the global namespace. I would expect that the namespace collision is more
likely to occur in a situation with user code like this:

namespace foo {
  namespace _detail {
     // user's name-conflicting details
  }

  using namespace boost;
  struct bar {...};
  counted_ptr<bar> gimme_bar();
}

In this case, putting the underscore before detail isn't any better than not
having it. About the only real way to "ensure" no collision is to use
something like boost_detail. I don't think it's worth it though. Instead, I
think that boost should publish that it will use "detail" as the detail
namespace, as a warning that it should be avoided if the user uses "using
namespace boost". Furthermore, we should discourage "using namespace boost"
in the first place, since it can unforeseen conflicts as names are added to
boost.

Since conflicting with "detail" is just the tip of the iceberg with regard to
pulling in all of namespace boost, we should jump through hoops to work around
it.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk