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.
Related
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.
Let's say I have a class:
class A
{
//...
};
With well defined operator +=:
A& operator +=(const A&) {return *this;} //class without members
So let's try to overload operator+ also (as non-friend). I don't want to use class name to call constructor of temporary object (kinda want this make generic code):
A operator +(const A& other) const
{
return auto(*this)(*this) += other; //error: invalid use of auto
// /\/\/\/\/\ /\
// type of *this ||
// constructor call
}
auto is no good here. Let's try decltype.
A operator +(const A& other) const
{
return decltype(*this)(*this) += other; //error: 'A& A::operator+=(const A&)' discards
// /\/\/\/\/\/\/\ /\ qualifiers [-fpermissive] return
// type of *this || decltype(*this)(*this) += other;
// constructor call ^
}
This managed to get the type out of *this, but operator+ is declared const, so we got const A deduced (that's what I thought). So let's go on:
A operator +(const A& other) const
{
return typename std::remove_const<decltype(*this)>::type(*this) += amount;
//same error as previous
}
Now I got mindblown. Even thought I removed constness, it still discards
qualifier. Well, maybe that's because all I was doing was just CASTING. So stupid. To call a constructor I would have to generate code that (besides type) has ::Constructor (so I even tried to make an alias for constructor, but at this point I failed so hard). My broken brain gave up, but rest of my consciousness gave me an solution (which is generic in writing, so that's good):
// outside of class
template<class A>
inline A&& make_rvalue(A copy)
{
return std::move(copy);
}
// inside of class
A operator +(const A& other) const
{
return make_rvalue(*this) += other; // such generic code
}
That's what I ended with. But is there some trick that doesn't involve any other function call?
EDIT: I know classic methods of doing this, but what I search is described below:
operator is reduced to {return /*...*/;}
doesn't involve names of class methods or global functions
takes to account overloads with other types - it cannot take argument(s) by value, since class A != class B, argument int over const int& doesn't help much with Matrix class (but proxy operator that calls target operator with exchanged arguments is OK)
takes to account (possible) order of operation (x#y != y#x), where both should should have same return statement
return statement should be exacly the same for given operator# is every class that has overloaded operator +=
If you create a function like this:
template <typename T>
T add(T temp,const T &b)
{
temp += b;
return temp;
}
You can use it like this:
A operator+(const A& other) const { return add(*this,other); }
I'm going to go on record as saying this whole line of thinking/coding is going the wrong way. You already know that (in this case) the return type is A. Your code seems to be putting a lot of work into saying A in the most complex, indirect way possible.
A operator +(const A& other) const {
A ret {*this};
ret += other;
return ret;
}
Since you seem to really want to use C++11 features (even though in this case almost none of them provides any real help) I used a braced initializer, so it uses something from C++11. And no, this isn't one line, but it is readable.
Note that the same style is fine in generic code as well. For example, in a non-member overload of operator+, we might have something like this:
template <class T>
T operator+(T const &a, T const &b) {
T ret {a};
ret += b;
return ret;
}
This can be simplified a bit as well though:
template <class T>
T operator+(T ret, t const &b) {
ret += b;
return ret;
}
Again, we lose precisely nothing from the fact that older compilers can and will accept the code without problem.
I define a global non-member method for + overloading
Like
ClassA operator+(const ClassA& a, const ClassB& b);
{
blah blah ;
}
In the communicative one, I can use
1)
ClassA operator+(const ClassB& b, const ClassA& a)
{
return operator+(a,b);
}
2)
ClassA operator+(const ClassB& b, const ClassA& a)
{
return a + b;
}
Any difference between 1 and 2?
Beyond the obvious difference pointed out first by #barakmanos in the comments ("the second one is more readable"), there is another technical difference.
Assume for a second, the following definitions:
struct B;
struct A
{
void operator+(B const&) const { ::std::cout << "member\n"; }
friend void operator+(A const&, B const&) { ::std::cout << "friend\n"; }
};
struct B { };
Now, consider the following three statements:
operator+(A(), B());
A().operator+(B());
A() + B();
The first one obviously calls the friend (free) function, the second one calls the member. However, the third one would call either if the other was not defined. In this special case, it cannot find a better match and would thus be ill formed. There are a few ways to modify this behaviour, e.g. if the member function was different in const-requirements, the expression could be correct and just lead to a larger overload set.
This demonstrates the difference in your two expressions: operator+(a,b) only considers free functions and not member functions overloading the binary plus operator.
In fact, the C++ standard has an example for another difference:
A() + B() only does argument dependent lookup, while operator+(A(), B()) does a normal function lookup. This means that the following is an error (taken from C++11 ยง13.3.1.2.10):
struct A { };
void operator + (A, A);
struct B {
void operator + (B);
void f ();
};
A a;
void B::f() {
operator+ (a,a); // error: global operator hidden by member
a + a; // OK: calls global operator+
}
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.
The assignment operator can be declared as
T& operator= (const t&);
in a class, but the arithmetic operators cannot be defined that way. It has to be friend function. I don't understand why? Can you please explain ?
It is not mandatory that arithmetic operators should be friend
Well you can define like this:
MyClass MyClass::operator + (const MyClass& t) const
{
MyClass ret(*this);
ret += t;
return ret;
}
The a + b is really a syntax sugar, the compiler will expand it to a.operator+(b). The previous sample will work if all your objects are MyClass instances, but will not work if you have to operate with others types, ie 1 + a, will not work, this can be solved by using friends.
MyClass operator + (int i, const MyClass& t)
{
MyClass ret(i);
ret += t;
return ret;
}
This has to be done when the left hand side of the + operator is not a class, or it is a class but you can't add operator + to its definition.
I think that C++ FAQ Lite will give you a definitive answer.
They ideally should be globals and not necessarily friends, so that you can write:
yourtype v = 1;
yourtype w = 1 + v;
Since, 1 is not an object of yourtype, if the operator+ were a member it would throw a fit. However, making it global makes it convert the 1 to yourtype and then perform the operation. Making it a friend helps to extract and manipulate the members of yourtype as required -- though not required. As an example: You can implement the member function operator+= and use it in the implementation of the operator+.
The problem is that if you do something like this:
class A
{
A& operator+(int n);
// ...
}
int main()
{
A my_var;
int integer = 1;
A + integer; // compiles
integer + A // error: no function operator+(int, A) defined
}
it will not compile.
A solution is to define operator+(int, A) and operator+(A, int) as friends of A.
As a side note, the Boost Operators library makes this process very easy.