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

From: George A. Heintzelman (georgeh_at_[hidden])
Date: 2002-10-30 09:51:41

Peter Dimov wrote:
> From: "George A. Heintzelman" <georgeh_at_[hidden]>
> > Yes, this is so. The question is, what should the set of reachable
> > namespaces be? Do we really want deriving from boost::noncopyable to
> > pull in the whole of boost's interface? That's really what I'm arguing
> > against in the end.
> 
> It depends on the circumstances. I agree that deriving from
> boost::noncopyable probably shouldn't add boost to the reachable namespaces.

I chose boost::noncopyable as the most obvious of these cases, but then 
I think the argument extends well to most of the other classes intended 
to be derived from, such as the operators.hpp classes and quite likely 
the iterator adaptors as well.

> 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 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. 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?

> 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.

[snip]
> The usual approach is to make only function (template) names visible. 
[snip]
> 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.

George Heintzelman
georgeh_at_[hidden]