Re: [boost] namespace organization (was Poisoning Koenig lookup)

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-10-30 10:11:08

From: "George A. Heintzelman" <georgeh_at_[hidden]>
>
> > On the other hand, sometimes it is necessary to add the base class
namespace
> > to the list, if the base class provides a service via ADL. Consider
> >
> > namespace boost
> > {
> >     void intrusive_ptr_add_ref(counted_base *);
> > }
> >
> > The intent here is to enable intrusive_ptr_add_ref to work on derived
> > classes.
>
> Right. So here I would suggest that counted_base should also live in
> its own namespace, which intrusive_ptr_add_ref would also live in. This
> makes sense, because intrusive_ptr_add_ref is part of counted_base's
> interface. Then this namespace quite legitimately is found by ADL when
> intrusive_ptr_add_ref is referenced. I don't see this as a problem with
> my proposal.

I did not say that. It implies that the subnamespace must be documented, and
not an implementation detail, but it's not a problem.

> > I don't want to downplay the importance of your proposed technique. I
have
> > used it in the past as a matter of style; I dropped it because compilers
> > often had problems with using declarations, especially when applied to
> > template names. The technique is good, and useful. But it doesn't solve
the
> > problem in general, only the portion that you have encountered.
Consider:
> >
> > std::vector< boost::shared_ptr<int> > v;
> >
> > type(v.begin());
> >
> > Will this work? Nobody knows.
>
> Because it depends on whether the iterator is a separate class or a
> pointer.

Not only that; even when the iterator is a separate class, boost may still
be an associated namespace.

> Right. But this is only an issue if I'm trying to do ADL on a
> std::vector< something >::iterator. I don't think I'm entitled to ever
> expect MyNS::type(std::vector<something>::iterator) to be found by ADL,
> so the issue shouldn't arise. I suppose I might or might not get a
> conflict if I'm actually defining things within MyNS at the time, but I
> think that's an uncertainty I could live with -- it's the developers of
> MyNS, instead of the users of MyNS, who would have to deal with
> resolving the ambiguity.
>
> Am I missing something more serious here?

Suppose that you have

template<class It> ... type(It it);

visible, to catch the general case, and do something sensible by default,
while still relying on ADL for specialized 'type' definitions for some
iterator types. Now boost::type<> may break the code.

> > But wait, there's more. You are probably using g++, right?
>
> Yes, but I get the same problem with our backup compiler, Intel's
> (which is an EDG front end). I think by the standard as written it is
> correct or at least justified in its behavior.

Yes, Borland C++ 5.5.1 has the same problem, it seems. Comeau 4.3b1 and VC
7.1 eat my example just fine.

> > The usual approach is to make only function (template) names visible.
> > This is core active issue 218.
>
> That would certainly make matters simpler, and I'm all for it, but I
> don't think it's a complete solution.

Of course not. It solves your specific problem. As does your suggestion.