Consider the following example:
namespace X {
struct A { static const A aaa; };
const A A::aaa = {};
}
bool operator == (const X::A &a, const X::A &b) { return true; }
bool workaround (const X::A &a, const X::A &b) { return a == b; }
namespace Y {
using X::A;
struct B { const A & an_a() const { static A a; return a; } };
bool operator == (const B &a, const B &b) { return true; }
bool foo (const B &b) {
return b.an_a() == A::aaa;
//return workaround(b.an_a(), A::aaa);
}
}
int main () {}
This code fails to compile foo because the == operator resolves the one in namespace Y rather than the one in the global namespace.
.code.tio.cpp:17:25: error: invalid operands to binary expression ('const X::A' and 'const X::A')
return b.an_a() == A::aaa;
~~~~~~~~ ^ ~~~~~~
.code.tio.cpp:14:10: note: candidate function not viable: no known conversion from 'const X::A' to 'const Y::B' for 1st argument
bool operator == (const B &a, const B &b) { return true; }
^
1 error generated.
I think I understand this is due to the way ADL has been defined for C++, which seems to explicitly exclude searching the global namespace if the class belongs to a namespace. But, it still seems counter-intuitive to me. Is there an explanation of why the global namespace could not be included in the set of namespaces to be searched for operator==?
For consistency, operators are considered to be just function names, and a function hides any in an enclosing scope (even if the parameter types differ). (The latter rule is presumably intended to prevent unexpected overload resolution interaction between functions declared in different scopes).
Your ::operator==(const X::A&,const X::A&) is hidden (within Y) by Y::operator==(const B&,const B&), and it's not considered to be part of the interface of X::A (because it's not in the immediate namespace X), so you can't find it.
If you're willing to change the spelling of the comparison, you can use the ugly, explicit ::operator==(b.an_a(), A::aaa) instead of adding workaround.
Related
I'm using a C struct (that I do not control) and wrote a freestanding operator== implementation for it in a namespace. I have another class that has that C struct as a member and that also has an operator== implementation. Originally I had:
#include <tuple>
struct Foo
{
int x;
};
struct Bar
{
Foo foo;
int y;
};
namespace foo_ops
{
bool operator==(const Foo& f1, const Foo& f2)
{
return f1.x == f2.x;
}
}
bool operator==(const Bar& b1, const Bar& b2)
{
using namespace foo_ops;
return b1.foo == b2.foo && b1.y == b2.y;
}
which works. I'd like to change the operator==(const Bar&, const Bar&) to use std::tuple instead:
bool operator==(const Bar& b1, const Bar& b2)
{
using namespace foo_ops;
auto asTuple = [](const Bar& b)
{
return std::tie(b.foo, b.y);
};
return asTuple(b1) == asTuple(b2);
}
but that fails to resolve because the compiler won't choose foo_ops::operator== when comparing the Foo members. Argument-dependent lookup doesn't help here since the Foo struct is declared in a different namespace from the corresponding operator==.
It apparently does work if I add a using foo_ops::operator==; declaration in the global scope. That declaration does not help if used in the function's scope. A globally-scoped using namespace foo_ops; directive also does not help.
My questions:
Is there any way to get std::tuple::operator== to choose foo_ops::operator== without a globally-scoped using declaration? (Or perhaps I should give up on having operator==(const Foo&, const Foo&) live in a separate namespace and move it to the global one?) I suspect that the answer is no, and using foo_ops::operator==; isn't too bad, but maybe I'm missing some alternative.
Not that I'd really want to use a globally-scoped using namespace foo_ops; directive, but why does that fail when using foo_ops::operator==; succeeds?
Given a simple class template with multiple implicit conversion functions (non-explicit constructor and conversion operator), as in the following example:
template<class T>
class Foo
{
private:
T m_value;
public:
Foo();
Foo(const T& value):
m_value(value)
{
}
operator T() const {
return m_value;
}
bool operator==(const Foo<T>& other) const {
return m_value == other.m_value;
}
};
struct Bar
{
bool m;
bool operator==(const Bar& other) const {
return false;
}
};
int main(int argc, char *argv[])
{
Foo<bool> a (true);
bool b = false;
if(a == b) {
// This is ambiguous
}
Foo<int> c (1);
int d = 2;
if(c == d) {
// This is ambiguous
}
Foo<Bar> e (Bar{true});
Bar f = {false};
if(e == f) {
// This is not ambiguous. Why?
}
}
The comparison operators involving primitive types (bool, int) are ambiguous, as expected - the compiler does not know whether it should use the conversion operator to convert the left-hand template class instance to a primitive type or use the conversion constructor to convert the right-hand primitive type to the expected class template instance.
However, the last comparison, involving a simple struct, is not ambiguous. Why? Which conversion function will be used?
Tested with compiler msvc 15.9.7.
According to [over.binary]/1
Thus, for any binary operator #, x#y can be interpreted
as either x.operator#(y) or operator#(x,y).
According to this rule, in the case of e == f, the compiler can only interpret it as e.operator==(f), not as f.operator==(e). So there is no ambiguity; the operator== you defined as a member of Bar is simply not a candidate for overload resolution.
In the case of a == b and c == d, the built-in candidate operator==(int, int) (see [over.built]/13) competes with the operator== defined as a member of Foo<T>.
Operator overloads implemented as member functions don't allow for implicit conversion of their left-hand operand, which is the object on which they are called.
It always helps to write out the explicit call of an operator overload to better understand exactly what it does:
Foo<Bar> e (Bar{true});
Bar f = {false};
// Pretty explicit: call the member function Foo<Bar>::operator==
if(e.operator ==(f)) { /* ... */ }
This can't be confused with the comparison operator in Bar, because it would require an implicit conversion of the left-hand side, which is impossible.
You can trigger an ambiguity similar to the ones you see with the built-in types when you define Bar and its comparison operator like this:
struct Bar { bool m; };
// A free function allows conversion, this will be ambiguous:
bool operator==(const Bar&, const Bar&)
{
return false;
}
This is nicely demonstrated and explained in Scott Meyers's Effective C++, Item 24.
I have a strange issue defining == for one of my class.
I simplified the code here to an example that i tested on my visual 2013;
MyClass is defined in namespace N
This does compile:
N::MyClass a, b;
bool test = a == b;
This too:
const N::MyClass a, b;
bool test = a == b;
This does not compile
std::map<int, N::MyClass> a, b;
bool test = a == b;
For your information the == operator is declared like this :
bool operator==(const N::MyClass & a, const N::MyClass & b);
here is the error I get : error C2678: binary '==' : no operator found which takes a left-hand operand of type 'const MyClass' (or there is no acceptable conversion)
But from what I know the map operator is defined : map == reference on cppreference.com
could someone explain me why this is wrong ?
Thank you in advance.
I did not find an answer and I'm sorry if this is stupid.
[solution]
If I mode the operator into the namespace it works :
bool N::operator==(const MyClass & a, const MyClass & b);
But I don't know why I need to do that, is it in the language definition ? (I guess yes)
Based on your description, I guess your equality operator is not defined in the same namespace as your class. The following demonstrates the situation:
#include <map>
namespace foo
{
class bar
{
};
}
using namespace foo;
bool operator== (bar const&, bar const&) { return true; }
int main()
{
bar const b;
b == b; // OK
std::map<int, bar> mb;
mb == mb; // ERROR
}
The obvious fix is to define the equality operator in the same namespace as the class. The reason it doesn't work is the two-phase name look-up in templates: when a templates is instantiated it only does second phase name look-up, i.e., it only finds functions relating to template arguments based on explicit qualification or argument dependent look-up. The equality operator isn't qualified in std::map<K, V> (well, it is never qualified when using operator notation to call it) and, thus, it needs to be found by argument dependent look-up.
Your MyClass::operator== needs to be marked const. For example:
bool operator ==(const MyClass&) const;
Note that your operator:
bool operator==(const MyClass & a, const MyClass & b);
will not work. operator== only takes one argument and compares this and the passed argument.
Unless it's not a class member operator, but a non-member one. In this case, it's correct and should work. Since it doesn't, it suggests to me that you forgot to #include the header file where your operator is declared.
Consider the following code:
class C {
public:
int operator-(int x) {
return 3-x;
}
};
class wrapper {
public:
operator C() {
static C z;
return z;
}
} wrap;
int main() {
return wrap-3;
}
it gives this error on g++:
test.cpp: In function ‘int main()’:
test.cpp:17:17: error: no match for ‘operator-’ in ‘wrap - 3’
The conversion operator seems to be working because this version works:
class wrapper {
public:
operator int() {
static int z=3;
return z--;
}
} wrap;
int main() {
return wrap-3;
}
operator- also seems to be working because this code compiles:
class C {
public:
int operator-(int x) {
return 3-x;
}
};
int main() {
C c
return c-3;
}
What's wrong with the combination of these two? Why can't an operator be applied after implicit conversion? Are there any workarounds to this problem?
Implicit conversions aren't performed on the first operand when a member function is matched. Just make your operator a non-member, perhaps a friend:
class C {
};
int operator-(C c, int x) {
return 3-x;
}
From [over.match.oper]:
— If T1 is a complete class type, the set of member candidates is the result of the qualified lookup of T1::operator# (13.3.1.1.1); otherwise, the set of member candidates is empty.
It doesn't compile (using GCC) because it would neet to chain two user-defined conversions to get from wrapper to int: first to C, then to int. The standard doesn't allow this. See David Rodriguez' answer in another thread.
When you do return wrap-3; the compiler dosn't know to convert wrapper to a C in order
for the calculation to take place, it is looking for a operator- in wrapper, or a
conversion in wrapper to a numeric type. Just because C has a operator- dosn't make the
compiler implicitly convert to it, you could have multiple conversion operators in wrapper,
which one should the compiler convert to?
Either explicitly tell the compiler to convert to C, of add the operator- to wrapper like this..
class wrapper {
public:
operator C() {
static C z;
return z;
}
int operator-(int x) {
return C()-x;
}
} wrap;
This piece of code compiles and runs as expected on GCC 3.x and 4.x:
#include <stdio.h>
typedef union buggedUnion
{
public:
// 4 var init constructor
inline buggedUnion(int _i) {
i = _i;
}
friend inline const buggedUnion operator - (int A, const buggedUnion &B) {
return buggedUnion(A - B.i);
}
friend inline const buggedUnion operator - (const buggedUnion &A, const buggedUnion &B) {
return buggedUnion(A.i - B.i);
}
int i;
} buggedUnion;
int main()
{
buggedUnion first(10);
buggedUnion second(5);
buggedUnion result = 10 - (first - second);
printf("%d\n", result.i); // 0
return 0;
}
MSVC, however, will not compile that code, complaining:
main.cpp(60) : error C3767: '-': candidate function(s) not accessible
could be the friend function at 'main.cpp(41)' : '-' [may be found via argument-dependent lookup]
or the friend function at 'main.cpp(45)' : '-' [may be found via argument-dependent lookup]
main.cpp(60) : error C2676: binary '-' : 'buggedUnion' does not define this operator or a conversion to a type acceptable to the predefined operator
Which of the compilers is correct? How can this be resolved? I'm trying to achieve clean code (no outside friend methods) while maintaining portability, flexibility and self-documenting code.
Some notes:
This is a test-case to show the problem, the original data-type is much more sophisticated and carefully designed, albeit not working in MSVC (main compiler is GCC, though MSVC compatibility is also desired).
Adding 'public:' at the start of the union declaration does not resolve it.
Adding 'public:' before each operator does not resolve it
Converting the test case to a struct/class does fix it, but this is not desired (Please no flames, I got reasons. Most of them are limitations of the C++ language)
Operator method is to be left at global scope (not a member function)
Optimal solution would not rely on moving the declaration outside of the union definition for aestetic reasons (over 24 different combinations of operators and operands), but will be done if there is no other solution.
It is difficult to say which one is right, since unnamed structs are not allowed by the standard (although they are a common extension), and as such the program is ill-formed.
Edit: It does seem to be a bug in msvc, since the following code, which is perfectly valid, fails to compile.
union buggedUnion
{
friend buggedUnion operator - (int A, const buggedUnion &B) {
return B;
}
friend buggedUnion operator - (const buggedUnion &A, const buggedUnion &B) {
return A;
}
int i;
};
int main()
{
buggedUnion first = { 1 };
buggedUnion second = { 1 };
buggedUnion result = 3 - (first - second);
}
You can work around this by defining the functions outside the class.
union buggedUnion
{
int i;
};
buggedUnion operator - (int A, const buggedUnion &B) {
return B;
}
buggedUnion operator - (const buggedUnion &A, const buggedUnion &B) {
return A;
}
You can even retain the friend status by declaring the functions inside the class (but still defining them outside), but I doubt you'd ever need that in a union.
Note that I removed the unnecessary typedef and inlines.
The following code compiles correctly in Visual C++ 2008:
union buggedUnion
{
int i;
friend buggedUnion operator - (int A, const buggedUnion &B);
friend buggedUnion operator - (const buggedUnion &A, const buggedUnion &B);
};
buggedUnion operator - (int A, const buggedUnion &B)
{
return B;
}
buggedUnion operator - (const buggedUnion &A, const buggedUnion &B)
{
return A;
}
While the MSDN documentation states that writing the definition of the friend function inside a class actually puts the function in file scope, this appears to not work for unions. Since it works for class and struct, I suspect this may be a bug. Since the implementation I have given above should work on GCC, I think it can be considered a suitable workaround and the bug will likely not be fixed in MSVC.
You need to declare those friend function in the enclosing scope, as once you declare them within the class, they're no longer visible in the external scope. So either move the function body out of the class as avakar said, or keep them in the class and add the following line to reintroduce the name into the enclosing scope:
extern const buggedUnion operator-(const buggedUnion& A, const buggedUnion&B);
int main()
{
...etc
Hope this helps. Not sure whether it's a bug but it appears (?) to me to be correct behavior, now implemented correctly, which many compilers used to interpret differently. See: --ffriend-injection in http://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html.