Boost logo

Boost :

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.

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

George Heintzelman

Boost list run by bdawes at, gregod at, cpdaniel at, john at