[LC++]Compiles with g++-3.2 but later versions flakey. Why?

[Dr Mark H Phillips]

On Tue, 2005-10-25 at 21:49 +0200, Carlo Wood wrote:
> I had not much time last time, lemme add some remarks now.

Thanks!

> Obviously, the correct way to interpret dummyx::dummyFunct(d) is to first
> evaluate dummyx::dummyFunct and then call operator()(Dummy) on it.  Thus,
> it should do the same as (dummyx::dummyFunct)(d).

I think you're probably right, g++-3.3 has a bug here.

> Because dummyFunct is only declared in namespace dummyx, it is not
> declared in main(), hence, the last line should always fail.

But this doesn't take into account Koenig lookup.  "dummyFunct" is
being used as a function, so if we can't find this identifier in the
visible namespaces, we look at the namespaces of the arguments.  In this
case the argument is d, of type dummyx::Dummy, so dummyFunct should
become visible.  Which explains the following:

> The error is a bit weird though "cannot be called as function"
> should be "is not declared".

So obviously g++ is using Koenig to find the "dummyFunct" identifier,
but for some reason is not allowing it to be applied, even though it
is a functoid object (ie has an operator()).

If I do:

namespace dummyx {

  // as before but also include the following

  DummyFunct myDummyFunct;

}

int main() {

  ::dummyx::Dummy const d;

  std::cout<<"myDummyFunct(d) = "<<myDummyFunct(d)<<std::endl;

}

This compiles fine on everything.

So obviously there is no problem with using Koenig lookup for 
functoids in general.  It appears that problems only arise when
we try to use references to such an object.

Surely this is a bug?  Or perhaps there's some obscure C++ standard
rule which disallows this?

Cheers,

Mark.