In C++ do you need to overload operator== in both directions?
up vote
34
down vote
favorite
2
Say I am working with a class:
class Foo{
public:
std:string name;
/*...*/
}/*end Foo*/
and I provide an overload for operator==
bool operator==(const Foo& objA, const std::string& objB) {
return (objA.name == objB);
}
Do I also need to re-implement the same logic in reverse?
bool operator==(const std::string& objA, const Foo& objB) {
return (objA == objB.name);
}
c++ operator-overloading
edited Nov 14 at 13:46
StoryTeller
88.9k12179245
asked Nov 14 at 12:21
hehe3301
306312
|
show 3 more comments
up vote
34
down vote
favorite
2
Say I am working with a class:
class Foo{
public:
std:string name;
/*...*/
}/*end Foo*/
and I provide an overload for operator==
bool operator==(const Foo& objA, const std::string& objB) {
return (objA.name == objB);
}
Do I also need to re-implement the same logic in reverse?
bool operator==(const std::string& objA, const Foo& objB) {
return (objA == objB.name);
}
c++ operator-overloading
edited Nov 14 at 13:46
StoryTeller
88.9k12179245
asked Nov 14 at 12:21
hehe3301
306312
17
By the way, in c++20 you will be able to define just one new operator and the compiler will do the juggling. It'soperator <=>.
– StoryTeller
Nov 14 at 12:29
4
related All you always dreamed to know about operator overloading but never cared to ask.
– YSC
Nov 14 at 12:33
2
The bigger question, IMO, is whether the concept of equality between aFooand a string is a valid concept or an inherent category error. A thing is not equivalent to its name, and the idea that it is is arguably part of what confuses people so much about pointers and references.
– cHao
Nov 14 at 15:03
1
@StoryTeller - I must have missed the bit whereoperator<=>will reorder arguments of different types (your first comment) - can you point to the section that specifies that?
– Toby Speight
Nov 14 at 17:04
3
@TobySpeight - eel.is/c++draft/over.match.oper#3.4
– StoryTeller
Nov 14 at 17:13
|
show 3 more comments
up vote
34
down vote
favorite
2
up vote
34
down vote
favorite
2
2
Say I am working with a class:
class Foo{
public:
std:string name;
/*...*/
}/*end Foo*/
and I provide an overload for operator==
bool operator==(const Foo& objA, const std::string& objB) {
return (objA.name == objB);
}
Do I also need to re-implement the same logic in reverse?
bool operator==(const std::string& objA, const Foo& objB) {
return (objA == objB.name);
}
c++ operator-overloading
edited Nov 14 at 13:46
StoryTeller
88.9k12179245
asked Nov 14 at 12:21
hehe3301
306312
Say I am working with a class:
class Foo{
public:
std:string name;
/*...*/
}/*end Foo*/
and I provide an overload for operator==
bool operator==(const Foo& objA, const std::string& objB) {
return (objA.name == objB);
}
Do I also need to re-implement the same logic in reverse?
bool operator==(const std::string& objA, const Foo& objB) {
return (objA == objB.name);
}
c++ operator-overloading
c++ operator-overloading
edited Nov 14 at 13:46
StoryTeller
88.9k12179245
asked Nov 14 at 12:21
hehe3301
306312
edited Nov 14 at 13:46
StoryTeller
88.9k12179245
asked Nov 14 at 12:21
hehe3301
306312
edited Nov 14 at 13:46
StoryTeller
88.9k12179245
edited Nov 14 at 13:46
StoryTeller
88.9k12179245
edited Nov 14 at 13:46
StoryTeller
88.9k12179245
88.9k12179245
asked Nov 14 at 12:21
hehe3301
306312
asked Nov 14 at 12:21
hehe3301
306312
asked Nov 14 at 12:21
hehe3301
306312
306312
17
By the way, in c++20 you will be able to define just one new operator and the compiler will do the juggling. It'soperator <=>.
– StoryTeller
Nov 14 at 12:29
4
related All you always dreamed to know about operator overloading but never cared to ask.
– YSC
Nov 14 at 12:33
2
The bigger question, IMO, is whether the concept of equality between aFooand a string is a valid concept or an inherent category error. A thing is not equivalent to its name, and the idea that it is is arguably part of what confuses people so much about pointers and references.
– cHao
Nov 14 at 15:03
1
@StoryTeller - I must have missed the bit whereoperator<=>will reorder arguments of different types (your first comment) - can you point to the section that specifies that?
– Toby Speight
Nov 14 at 17:04
3
@TobySpeight - eel.is/c++draft/over.match.oper#3.4
– StoryTeller
Nov 14 at 17:13
|
show 3 more comments
17
By the way, in c++20 you will be able to define just one new operator and the compiler will do the juggling. It'soperator <=>.
– StoryTeller
Nov 14 at 12:29
4
related All you always dreamed to know about operator overloading but never cared to ask.
– YSC
Nov 14 at 12:33
2
The bigger question, IMO, is whether the concept of equality between aFooand a string is a valid concept or an inherent category error. A thing is not equivalent to its name, and the idea that it is is arguably part of what confuses people so much about pointers and references.
– cHao
Nov 14 at 15:03
1
@StoryTeller - I must have missed the bit whereoperator<=>will reorder arguments of different types (your first comment) - can you point to the section that specifies that?
– Toby Speight
Nov 14 at 17:04
3
@TobySpeight - eel.is/c++draft/over.match.oper#3.4
– StoryTeller
Nov 14 at 17:13
17
17
By the way, in c++20 you will be able to define just one new operator and the compiler will do the juggling. It's
operator <=>.– StoryTeller
Nov 14 at 12:29
By the way, in c++20 you will be able to define just one new operator and the compiler will do the juggling. It's
operator <=>.– StoryTeller
Nov 14 at 12:29
4
4
related All you always dreamed to know about operator overloading but never cared to ask.
– YSC
Nov 14 at 12:33
related All you always dreamed to know about operator overloading but never cared to ask.
– YSC
Nov 14 at 12:33
2
2
The bigger question, IMO, is whether the concept of equality between a
Foo and a string is a valid concept or an inherent category error. A thing is not equivalent to its name, and the idea that it is is arguably part of what confuses people so much about pointers and references.– cHao
Nov 14 at 15:03
The bigger question, IMO, is whether the concept of equality between a
Foo and a string is a valid concept or an inherent category error. A thing is not equivalent to its name, and the idea that it is is arguably part of what confuses people so much about pointers and references.– cHao
Nov 14 at 15:03
1
1
@StoryTeller - I must have missed the bit where
operator<=> will reorder arguments of different types (your first comment) - can you point to the section that specifies that?– Toby Speight
Nov 14 at 17:04
@StoryTeller - I must have missed the bit where
operator<=> will reorder arguments of different types (your first comment) - can you point to the section that specifies that?– Toby Speight
Nov 14 at 17:04
3
3
@TobySpeight - eel.is/c++draft/over.match.oper#3.4
– StoryTeller
Nov 14 at 17:13
@TobySpeight - eel.is/c++draft/over.match.oper#3.4
– StoryTeller
Nov 14 at 17:13
|
show 3 more comments
2 Answers
2
active
oldest
votes
up vote
51
down vote
accepted
You do if you want to support comparisons where the string is on the left and the Foo is on the right. An implementation won't reorder the arguments to an overloaded operator== to make it work.
But you can avoid repeating the implementation's logic, though. Assuming your operator should behave as expected:
inline bool operator==(const std::string& objA, const Foo& objB) {
return objB == objA; // Reuse previously defined operator
}
answered Nov 14 at 12:23
StoryTeller
88.9k12179245
5
So theoretically one could implement different behaviour forFoo==StringandString==Foo
– hehe3301
Nov 14 at 12:25
39
Yes, you could. But you definitely shouldn't.
– Matthieu Brucher
Nov 14 at 12:25
@StoryTeller Do we get op!= for free with this as !(op==) or should that be implemented both directions as well? (expecting the answer no)
– hehe3301
Nov 14 at 13:46
19
@hehe3301 - I'm afraid all the overloads you want will need to be implemented explicitly. Although again, the body can be!(lhs == rhs). That's whyoperator <=>generates so much excitement. Because it can cut down on a lot of boilerplate.
– StoryTeller
Nov 14 at 13:50
@hehe3301: You can use boost/operators.hpp, which provides classes to inherit from which fill in operators based on your provided ones. For instance, if you inherit fromequality_comparable<T, U>and provideoperator==(T, U), it will supplybool operator==(const U&, const T&),bool operator!=(const U&, const T&), andbool operator!=(const T&, const U&)for you.
– Kundor
Nov 15 at 9:12
add a comment |
up vote
5
down vote
Yes, you do. Just like in lots of other languages, C++ takes sides and comparisons between two objects of different types will lead to calls to two different comparison operators depending on the order.
Of course, you want them to be consistent and not surprising, so the second should be defined in terms of the first.
answered Nov 14 at 12:25
Matthieu Brucher
6,1501231
10
Re: "Just like in other languages": Overloading works sufficiently differently from one language to the next that I don't think this sort of sweeping statement is helpful.
– ruakh
Nov 14 at 21:02
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
51
down vote
accepted
You do if you want to support comparisons where the string is on the left and the Foo is on the right. An implementation won't reorder the arguments to an overloaded operator== to make it work.
But you can avoid repeating the implementation's logic, though. Assuming your operator should behave as expected:
inline bool operator==(const std::string& objA, const Foo& objB) {
return objB == objA; // Reuse previously defined operator
}
answered Nov 14 at 12:23
StoryTeller
88.9k12179245
5
So theoretically one could implement different behaviour forFoo==StringandString==Foo
– hehe3301
Nov 14 at 12:25
39
Yes, you could. But you definitely shouldn't.
– Matthieu Brucher
Nov 14 at 12:25
@StoryTeller Do we get op!= for free with this as !(op==) or should that be implemented both directions as well? (expecting the answer no)
– hehe3301
Nov 14 at 13:46
19
@hehe3301 - I'm afraid all the overloads you want will need to be implemented explicitly. Although again, the body can be!(lhs == rhs). That's whyoperator <=>generates so much excitement. Because it can cut down on a lot of boilerplate.
– StoryTeller
Nov 14 at 13:50
@hehe3301: You can use boost/operators.hpp, which provides classes to inherit from which fill in operators based on your provided ones. For instance, if you inherit fromequality_comparable<T, U>and provideoperator==(T, U), it will supplybool operator==(const U&, const T&),bool operator!=(const U&, const T&), andbool operator!=(const T&, const U&)for you.
– Kundor
Nov 15 at 9:12
add a comment |
up vote
51
down vote
accepted
You do if you want to support comparisons where the string is on the left and the Foo is on the right. An implementation won't reorder the arguments to an overloaded operator== to make it work.
But you can avoid repeating the implementation's logic, though. Assuming your operator should behave as expected:
inline bool operator==(const std::string& objA, const Foo& objB) {
return objB == objA; // Reuse previously defined operator
}
answered Nov 14 at 12:23
StoryTeller
88.9k12179245
5
So theoretically one could implement different behaviour forFoo==StringandString==Foo
– hehe3301
Nov 14 at 12:25
39
Yes, you could. But you definitely shouldn't.
– Matthieu Brucher
Nov 14 at 12:25
@StoryTeller Do we get op!= for free with this as !(op==) or should that be implemented both directions as well? (expecting the answer no)
– hehe3301
Nov 14 at 13:46
19
@hehe3301 - I'm afraid all the overloads you want will need to be implemented explicitly. Although again, the body can be!(lhs == rhs). That's whyoperator <=>generates so much excitement. Because it can cut down on a lot of boilerplate.
– StoryTeller
Nov 14 at 13:50
@hehe3301: You can use boost/operators.hpp, which provides classes to inherit from which fill in operators based on your provided ones. For instance, if you inherit fromequality_comparable<T, U>and provideoperator==(T, U), it will supplybool operator==(const U&, const T&),bool operator!=(const U&, const T&), andbool operator!=(const T&, const U&)for you.
– Kundor
Nov 15 at 9:12
add a comment |
up vote
51
down vote
accepted
up vote
51
down vote
accepted
You do if you want to support comparisons where the string is on the left and the Foo is on the right. An implementation won't reorder the arguments to an overloaded operator== to make it work.
But you can avoid repeating the implementation's logic, though. Assuming your operator should behave as expected:
inline bool operator==(const std::string& objA, const Foo& objB) {
return objB == objA; // Reuse previously defined operator
}
answered Nov 14 at 12:23
StoryTeller
88.9k12179245
You do if you want to support comparisons where the string is on the left and the Foo is on the right. An implementation won't reorder the arguments to an overloaded operator== to make it work.
But you can avoid repeating the implementation's logic, though. Assuming your operator should behave as expected:
inline bool operator==(const std::string& objA, const Foo& objB) {
return objB == objA; // Reuse previously defined operator
}
answered Nov 14 at 12:23
StoryTeller
88.9k12179245
edited Nov 14 at 12:27
answered Nov 14 at 12:23
StoryTeller
88.9k12179245
answered Nov 14 at 12:23
StoryTeller
88.9k12179245
answered Nov 14 at 12:23
StoryTeller
88.9k12179245
88.9k12179245
5
So theoretically one could implement different behaviour forFoo==StringandString==Foo
– hehe3301
Nov 14 at 12:25
39
Yes, you could. But you definitely shouldn't.
– Matthieu Brucher
Nov 14 at 12:25
@StoryTeller Do we get op!= for free with this as !(op==) or should that be implemented both directions as well? (expecting the answer no)
– hehe3301
Nov 14 at 13:46
19
@hehe3301 - I'm afraid all the overloads you want will need to be implemented explicitly. Although again, the body can be!(lhs == rhs). That's whyoperator <=>generates so much excitement. Because it can cut down on a lot of boilerplate.
– StoryTeller
Nov 14 at 13:50
@hehe3301: You can use boost/operators.hpp, which provides classes to inherit from which fill in operators based on your provided ones. For instance, if you inherit fromequality_comparable<T, U>and provideoperator==(T, U), it will supplybool operator==(const U&, const T&),bool operator!=(const U&, const T&), andbool operator!=(const T&, const U&)for you.
– Kundor
Nov 15 at 9:12
add a comment |
5
So theoretically one could implement different behaviour forFoo==StringandString==Foo
– hehe3301
Nov 14 at 12:25
39
Yes, you could. But you definitely shouldn't.
– Matthieu Brucher
Nov 14 at 12:25
@StoryTeller Do we get op!= for free with this as !(op==) or should that be implemented both directions as well? (expecting the answer no)
– hehe3301
Nov 14 at 13:46
19
@hehe3301 - I'm afraid all the overloads you want will need to be implemented explicitly. Although again, the body can be!(lhs == rhs). That's whyoperator <=>generates so much excitement. Because it can cut down on a lot of boilerplate.
– StoryTeller
Nov 14 at 13:50
@hehe3301: You can use boost/operators.hpp, which provides classes to inherit from which fill in operators based on your provided ones. For instance, if you inherit fromequality_comparable<T, U>and provideoperator==(T, U), it will supplybool operator==(const U&, const T&),bool operator!=(const U&, const T&), andbool operator!=(const T&, const U&)for you.
– Kundor
Nov 15 at 9:12
5
5
So theoretically one could implement different behaviour for
Foo==String and String==Foo– hehe3301
Nov 14 at 12:25
So theoretically one could implement different behaviour for
Foo==String and String==Foo– hehe3301
Nov 14 at 12:25
39
39
Yes, you could. But you definitely shouldn't.
– Matthieu Brucher
Nov 14 at 12:25
Yes, you could. But you definitely shouldn't.
– Matthieu Brucher
Nov 14 at 12:25
@StoryTeller Do we get op!= for free with this as !(op==) or should that be implemented both directions as well? (expecting the answer no)
– hehe3301
Nov 14 at 13:46
@StoryTeller Do we get op!= for free with this as !(op==) or should that be implemented both directions as well? (expecting the answer no)
– hehe3301
Nov 14 at 13:46
19
19
@hehe3301 - I'm afraid all the overloads you want will need to be implemented explicitly. Although again, the body can be
!(lhs == rhs). That's why operator <=> generates so much excitement. Because it can cut down on a lot of boilerplate.– StoryTeller
Nov 14 at 13:50
@hehe3301 - I'm afraid all the overloads you want will need to be implemented explicitly. Although again, the body can be
!(lhs == rhs). That's why operator <=> generates so much excitement. Because it can cut down on a lot of boilerplate.– StoryTeller
Nov 14 at 13:50
@hehe3301: You can use boost/operators.hpp, which provides classes to inherit from which fill in operators based on your provided ones. For instance, if you inherit from
equality_comparable<T, U> and provide operator==(T, U), it will supply bool operator==(const U&, const T&), bool operator!=(const U&, const T&), and bool operator!=(const T&, const U&) for you.– Kundor
Nov 15 at 9:12
@hehe3301: You can use boost/operators.hpp, which provides classes to inherit from which fill in operators based on your provided ones. For instance, if you inherit from
equality_comparable<T, U> and provide operator==(T, U), it will supply bool operator==(const U&, const T&), bool operator!=(const U&, const T&), and bool operator!=(const T&, const U&) for you.– Kundor
Nov 15 at 9:12
add a comment |
up vote
5
down vote
Yes, you do. Just like in lots of other languages, C++ takes sides and comparisons between two objects of different types will lead to calls to two different comparison operators depending on the order.
Of course, you want them to be consistent and not surprising, so the second should be defined in terms of the first.
answered Nov 14 at 12:25
Matthieu Brucher
6,1501231
10
Re: "Just like in other languages": Overloading works sufficiently differently from one language to the next that I don't think this sort of sweeping statement is helpful.
– ruakh
Nov 14 at 21:02
add a comment |
up vote
5
down vote
Yes, you do. Just like in lots of other languages, C++ takes sides and comparisons between two objects of different types will lead to calls to two different comparison operators depending on the order.
Of course, you want them to be consistent and not surprising, so the second should be defined in terms of the first.
answered Nov 14 at 12:25
Matthieu Brucher
6,1501231
10
Re: "Just like in other languages": Overloading works sufficiently differently from one language to the next that I don't think this sort of sweeping statement is helpful.
– ruakh
Nov 14 at 21:02
add a comment |
up vote
5
down vote
up vote
5
down vote
Yes, you do. Just like in lots of other languages, C++ takes sides and comparisons between two objects of different types will lead to calls to two different comparison operators depending on the order.
Of course, you want them to be consistent and not surprising, so the second should be defined in terms of the first.
answered Nov 14 at 12:25
Matthieu Brucher
6,1501231
Yes, you do. Just like in lots of other languages, C++ takes sides and comparisons between two objects of different types will lead to calls to two different comparison operators depending on the order.
Of course, you want them to be consistent and not surprising, so the second should be defined in terms of the first.
answered Nov 14 at 12:25
Matthieu Brucher
6,1501231
edited Nov 14 at 21:47
answered Nov 14 at 12:25
Matthieu Brucher
6,1501231
answered Nov 14 at 12:25
Matthieu Brucher
6,1501231
answered Nov 14 at 12:25
Matthieu Brucher
6,1501231
6,1501231
10
Re: "Just like in other languages": Overloading works sufficiently differently from one language to the next that I don't think this sort of sweeping statement is helpful.
– ruakh
Nov 14 at 21:02
add a comment |
10
Re: "Just like in other languages": Overloading works sufficiently differently from one language to the next that I don't think this sort of sweeping statement is helpful.
– ruakh
Nov 14 at 21:02
10
10
Re: "Just like in other languages": Overloading works sufficiently differently from one language to the next that I don't think this sort of sweeping statement is helpful.
– ruakh
Nov 14 at 21:02
Re: "Just like in other languages": Overloading works sufficiently differently from one language to the next that I don't think this sort of sweeping statement is helpful.
– ruakh
Nov 14 at 21:02
add a comment |
draft saved
draft discarded
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53300142%2fin-c-do-you-need-to-overload-operator-in-both-directions%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
17
By the way, in c++20 you will be able to define just one new operator and the compiler will do the juggling. It's
operator <=>.– StoryTeller
Nov 14 at 12:29
4
related All you always dreamed to know about operator overloading but never cared to ask.
– YSC
Nov 14 at 12:33
2
The bigger question, IMO, is whether the concept of equality between a
Fooand a string is a valid concept or an inherent category error. A thing is not equivalent to its name, and the idea that it is is arguably part of what confuses people so much about pointers and references.– cHao
Nov 14 at 15:03
1
@StoryTeller - I must have missed the bit where
operator<=>will reorder arguments of different types (your first comment) - can you point to the section that specifies that?– Toby Speight
Nov 14 at 17:04
3
@TobySpeight - eel.is/c++draft/over.match.oper#3.4
– StoryTeller
Nov 14 at 17:13