namespace and operator==

[Xavier Decoret]

The following code does not compoile with gcc-3.2.3

namespace dummy
{
//++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
// Interface of Foo
//++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
class Foo
{
public:

friend bool operator==(const Foo& f0,const Foo& f1);
private:
int a_;
};
}
//************************************************************
// Implementation of Doo
//************************************************************
bool
operator==(const dummy::Foo& f0,const dummy::Foo& f1)
{
return f0.a_ == f1.a_;
}


After a while, I figured that operator== is actually declared in
namespace dummy:: so the compiler error is legitimate. Therefore I can
fix the implementation with:

bool
dummy:perator==(const dummy::Foo& f0,const dummy::Foo& f1)
{
std::cout<<"in dummy:perator=="<<std::endl;
return f0.a_ == f1.a_;
}

But then I am quite surprise that the following does compile:
int
main(int,char**)
{
dummy::Foo f0;
dummy::Foo f1;
return f0 == f1;
}

Because it should not find the operator== since namespace dummy is not
opened. But I am sure that it is the one called (thanks to the cout).

Then I tried to make operator== be in global namespace with
//++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
// Interface of Foo
//++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
friend bool :perator==(const Foo& f0,const Foo& f1);

//************************************************************
// Implementation of Doo
//************************************************************
bool
operator==(const dummy::Foo& f0,const dummy::Foo& f1)
{
std::cout<<"in :perator=="<<std::endl;
return f0.a_ == f1.a_;
}

But then it refuses to compile with:
main.C:11: `bool operator==(const dummy::Foo&, const dummy::Foo&)'
should have
been declared inside `::'

So my question is: is my concern legal? Do I really want to have
operator== in namespace dummy? Is it legal that gcc finds that there is
an dummy:perator== even if the namespace is not opened?

Thanks for insights.


--
+-------------------------------------------------+
| Xavier Décoret - Post Doct |
| Graphics Lab (LCS) - MIT |
| mailto: (e-mail address removed) |
| home : http://www.graphics.lcs.mit.edu/~decoret|
+-------------------------------------------------+

 

[Victor Bazarov]

[...]
So my question is: is my concern legal?

It's legal. Whether it's valid or not is a different question.
In order to answer it, one needs to know what your concern is.

Do I really want to have
operator== in namespace dummy?

I don't know. Do you?

Is it legal that gcc finds that there is
an dummy:perator== even if the namespace is not opened?

Yes, it is. See 3.4.2/1. The call to operator== is a function
call. Namespaces of the operands are considered in the name
lookup along with all visible scopes.

Victor

 

[Andrey Tarasevich]

The following code does not compoile with gcc-3.2.3

namespace dummy
{
//++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
// Interface of Foo
//++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
class Foo
{
public:

friend bool operator==(const Foo& f0,const Foo& f1);
private:
int a_;
};
}
//************************************************************
// Implementation of Doo
//************************************************************
bool
operator==(const dummy::Foo& f0,const dummy::Foo& f1)
{
return f0.a_ == f1.a_;
}


After a while, I figured that operator== is actually declared in
namespace dummy:: so the compiler error is legitimate. Therefore I can
fix the implementation with:

It is not really declared yet. But yes, the above 'friend' declaration
refers to the 'operator ==' from namespace 'dummy'.

bool
dummy:perator==(const dummy::Foo& f0,const dummy::Foo& f1)
{
std::cout<<"in dummy:perator=="<<std::endl;
return f0.a_ == f1.a_;
}

But then I am quite surprise that the following does compile:
int
main(int,char**)
{
dummy::Foo f0;
dummy::Foo f1;
return f0 == f1;
}

Because it should not find the operator== since namespace dummy is not
opened. But I am sure that it is the one called (thanks to the cout).

The correct 'operator ==' is found by argument-dependent name lookup.
There's no need to "open" any namespaces here, whatever that means.

Then I tried to make operator== be in global namespace with
//++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
// Interface of Foo
//++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
friend bool :perator==(const Foo& f0,const Foo& f1);

//************************************************************
// Implementation of Doo
//************************************************************
bool
operator==(const dummy::Foo& f0,const dummy::Foo& f1)
{
std::cout<<"in :perator=="<<std::endl;
return f0.a_ == f1.a_;
}

But then it refuses to compile with:
main.C:11: `bool operator==(const dummy::Foo&, const dummy::Foo&)'
should have
been declared inside `::'

If I'm not mistaken, you cannot refer to an unknown name in a friend
declaration, unless this name is supposed to belong to immediate
enclosing namespace scope. In other words, you friend declaration can
introduce any names that will (or do already) belong to namespace
'dummy', but if you want to "befriend" anything from global scope, that
thing must be already declared in advance. For example, this will compile

namespace dummy { class Foo; };
bool operator==(const dummy::Foo& f0,const dummy::Foo& f1);

namespace dummy
{
class Foo
{
public:
friend bool :perator==(const Foo& f0,const Foo& f1);
private:
int a_;
};
}

bool operator==(const dummy::Foo& f0,const dummy::Foo& f1)
{
return f0.a_ == f1.a_;
}

int main()
{
dummy::Foo f0;
dummy::Foo f1;
return f0 == f1;
}

So my question is: is my concern legal?

What concern is that?

Do I really want to have operator== in namespace dummy?

Well, you should really ask yourself. It is perfectly legal to have it
there.

Is it legal that gcc finds that there is
an dummy:perator== even if the namespace is not opened?

Yes, it is. Read about argument-dependent name lookup. Sometimes it is
also referred to as Koenig lookup.