[boost] Poisoning Koenig lookup

From: George A. Heintzelman (georgeh_at_[hidden])
Date: 2002-10-28 17:00:04

So, I was writing a new iterator today:

namespace MyNS {
  class Iterator: public boost::bidirectional_iterator_helper<...> {
  };

// I need some utility functions on the iterators:
  int type(Iterator it);
};

int main() {
   Iterator it;
   type(it);
}

Boom. The error I get is:

`template<class T> class boost::type' is not a function, conflict with `int MyNS::type(MyNS::Iterator)' in call to `type'

So I went to my trusty standard and found out that, sure enough, it was correct to reject this code according to the section on name-dependent argument lookup (given that I had indirectly included boost/type.hpp). This is because MyNS and boost are both associated namespaces of MyNS::Iterator.

So... What this means is that deriving (however indirectly) from any namespace entity means that all those names are now effectively poisoned for the purpose of finding it via Koenig lookup. When that namespace is boost, that could really become a problem. 

Is there anything I (or boost) can do? Is this a known problem with the standard? It's inducing me to write the code in boost::bidirectional_iterator_helper for my own use instead, in this case, but I can see that in more complex cases I might get really unhappy about the duplication.

My preference would be that the namespaces searched in the lookup get some ordering (the same as the ordering of the base classes, I presume) to them, but that could get complicated...

George Heintzelman
georgeh_at_[hidden]