gcc doesn't try Koenig lookup

[Jean-Louis Leroy]

I'm trying to compile the following code with gcc (version below). I
would expect the compile to try the operator ==() declared in
Tangram::Backend because of Koenig lookup. But it doesn't happen. Is
it me or the compiler?

namespace Tangram {
namespace Backend {

struct RELATIONAL;

template<typename B>
struct Expression_Handle {
Expression_Handle();
Expression_Handle(int);
};

template<typename B>
struct Predicate_Handle {
};

template<typename B>
Predicate_Handle<B> operator ==(const Expression_Handle<B>&, const Expression_Handle<B>&);
}

namespace Relational {
using Backend::RELATIONAL;
typedef Backend::Expression_Handle<RELATIONAL> Expression;
}
}

void foo() {
using namespace Tangram::Relational;
Expression expr;
expr == Expression(666); // ok
expr == 666; // error: no match for 'operator==' in 'expr == 666'
}

Here's my gcc:
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,java,f95,ada --enable-java-awt=gtk --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --host=i386-redhat-linux
Thread model: posix
gcc version 4.0.1 20050727 (Red Hat 4.0.1-5)
--
Jean-Louis Leroy
Sound Object Logic
http://www.soundobjectlogic.com

[Greg]

Jean-Louis Leroy wrote:

I'm trying to compile the following code with gcc (version below). I
would expect the compile to try the operator ==() declared in
Tangram::Backend because of Koenig lookup. But it doesn't happen. Is
it me or the compiler?

namespace Tangram {
namespace Backend {

struct RELATIONAL;

template<typename B>
struct Expression_Handle {
Expression_Handle();
Expression_Handle(int);
};

template<typename B>
struct Predicate_Handle {
};

template<typename B>
Predicate_Handle<B> operator ==(const Expression_Handle<B>&, const Expression_Handle<B>&);
}

namespace Relational {
using Backend::RELATIONAL;
typedef Backend::Expression_Handle<RELATIONAL> Expression;
}
}

void foo() {
using namespace Tangram::Relational;
Expression expr;
expr == Expression(666); // ok
expr == 666; // error: no match for 'operator==' in 'expr == 666'
}

The operator== is found in the appropriate namespace as this variation
shows:

namespace Tangram {
namespace Backend
{

struct RELATIONAL;

struct Expression_Handle
{
Expression_Handle() {};
Expression_Handle(int) {};
};

struct Predicate_Handle { };

Predicate_Handle
operator ==(const Expression_Handle&, const Expression_Handle&)
{
return Predicate_Handle();
}
}

namespace Relational
{
using Backend::RELATIONAL;
typedef Backend::Expression_Handle Expression;
}
}

int main()
{
using namespace Tangram::Relational;
Expression expr;
expr == Expression(666); // ok
expr == 666; // ok
}

The problem is not the name lookup, but the fact that expr == 666 is
not enough for the compiler instantiate the template class
Backend::Expression_Handle<RELATIONAL> implicitly.

One solution would be add an int conversion method to Expression. But
since implicit conversions are best avoided, a more straightforward
solution would be to implement the == operator for integer values:

template<typename B>
Predicate_Handle<B>
operator ==(const Expression_Handle<B>& lhs, int rhs)
{
return lhs == Predicate_Handle<B>(rhs);
}

Greg

[Jean-Louis Leroy]

> The problem is not the name lookup, but the fact that expr == 666 is

not enough for the compiler instantiate the template class
Backend::Expression_Handle<RELATIONAL> implicitly.
I wonder what the standard has got to say on this (unfortunately my
copy is at the other side of town and I haven't navigate the thing for
a while). But this flies in the face of intuition IMO. Mine says that
the template declares an infinite set of overloaded 'operator =()'
functions that should contribute to the set of candidate
functions. One of them happens to be viable (and the only one at that)
at the cost of one user-defined conversion.
One solution would be add an int conversion method to Expression.
Actually no, the code I posted is a simplification of a fragment of an
object-relational mapper. The goal is to produce an AST that will be
translated to SQL.
But since implicit conversions are best avoided, a more
straightforward solution would be to implement the == operator for
integer values:

template<typename B>
Predicate_Handle<B>
operator ==(const Expression_Handle<B>& lhs, int rhs)
{
return lhs == Predicate_Handle<B>(rhs);
}

Yeah, that's the workaround I use but I have to do it for all
operators :-(
--
Jean-Louis Leroy
Sound Object Logic
http://www.soundobjectlogic.com