In C++ do you need to overload operator== in both directions?
53
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& fooObj, const std::string& strObj)
return (fooObj.name == strObj);
Do I also need to re-implement the same logic in reverse?
bool operator==(const std::string& strObj, const Foo& fooObj)
return (strObj == fooObj.name);
c++ operator-overloading
asked Nov 14 '18 at 12:21
hehe3301hehe3301
401412
|
show 3 more comments
53
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& fooObj, const std::string& strObj)
return (fooObj.name == strObj);
Do I also need to re-implement the same logic in reverse?
bool operator==(const std::string& strObj, const Foo& fooObj)
return (strObj == fooObj.name);
c++ operator-overloading
asked Nov 14 '18 at 12:21
hehe3301hehe3301
401412
21
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 '18 at 12:29
4
related All you always dreamed to know about operator overloading but never cared to ask.
– YSC
Nov 14 '18 at 12:33
3
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 '18 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 '18 at 17:04
3
@TobySpeight - eel.is/c++draft/over.match.oper#3.4
– StoryTeller
Nov 14 '18 at 17:13
|
show 3 more comments
53
53
53
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& fooObj, const std::string& strObj)
return (fooObj.name == strObj);
Do I also need to re-implement the same logic in reverse?
bool operator==(const std::string& strObj, const Foo& fooObj)
return (strObj == fooObj.name);
c++ operator-overloading
asked Nov 14 '18 at 12:21
hehe3301hehe3301
401412
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& fooObj, const std::string& strObj)
return (fooObj.name == strObj);
Do I also need to re-implement the same logic in reverse?
bool operator==(const std::string& strObj, const Foo& fooObj)
return (strObj == fooObj.name);
c++ operator-overloading
c++ operator-overloading
asked Nov 14 '18 at 12:21
hehe3301hehe3301
401412
asked Nov 14 '18 at 12:21
hehe3301hehe3301
401412
edited Dec 7 '18 at 15:08
hehe3301
asked Nov 14 '18 at 12:21
hehe3301hehe3301
401412
asked Nov 14 '18 at 12:21
hehe3301hehe3301
401412
asked Nov 14 '18 at 12:21
hehe3301hehe3301
401412
401412
21
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 '18 at 12:29
4
related All you always dreamed to know about operator overloading but never cared to ask.
– YSC
Nov 14 '18 at 12:33
3
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 '18 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 '18 at 17:04
3
@TobySpeight - eel.is/c++draft/over.match.oper#3.4
– StoryTeller
Nov 14 '18 at 17:13
|
show 3 more comments
21
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 '18 at 12:29
4
related All you always dreamed to know about operator overloading but never cared to ask.
– YSC
Nov 14 '18 at 12:33
3
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 '18 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 '18 at 17:04
3
@TobySpeight - eel.is/c++draft/over.match.oper#3.4
– StoryTeller
Nov 14 '18 at 17:13
21
21
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 '18 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 '18 at 12:29
4
4
related All you always dreamed to know about operator overloading but never cared to ask.
– YSC
Nov 14 '18 at 12:33
related All you always dreamed to know about operator overloading but never cared to ask.
– YSC
Nov 14 '18 at 12:33
3
3
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 '18 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 '18 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 '18 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 '18 at 17:04
3
3
@TobySpeight - eel.is/c++draft/over.match.oper#3.4
– StoryTeller
Nov 14 '18 at 17:13
@TobySpeight - eel.is/c++draft/over.match.oper#3.4
– StoryTeller
Nov 14 '18 at 17:13
|
show 3 more comments
2 Answers
2
active
oldest
votes
74
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 '18 at 12:23
StoryTellerStoryTeller
101k12210276
8
So theoretically one could implement different behaviour forFoo==StringandString==Foo
– hehe3301
Nov 14 '18 at 12:25
54
Yes, you could. But you definitely shouldn't.
– Matthieu Brucher
Nov 14 '18 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 '18 at 13:46
22
@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 '18 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 '18 at 9:12
add a comment |
5
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 '18 at 12:25
Matthieu BrucherMatthieu Brucher
16.4k32143
12
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 '18 at 21:02
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
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
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
74
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 '18 at 12:23
StoryTellerStoryTeller
101k12210276
8
So theoretically one could implement different behaviour forFoo==StringandString==Foo
– hehe3301
Nov 14 '18 at 12:25
54
Yes, you could. But you definitely shouldn't.
– Matthieu Brucher
Nov 14 '18 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 '18 at 13:46
22
@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 '18 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 '18 at 9:12
add a comment |
74
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 '18 at 12:23
StoryTellerStoryTeller
101k12210276
8
So theoretically one could implement different behaviour forFoo==StringandString==Foo
– hehe3301
Nov 14 '18 at 12:25
54
Yes, you could. But you definitely shouldn't.
– Matthieu Brucher
Nov 14 '18 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 '18 at 13:46
22
@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 '18 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 '18 at 9:12
add a comment |
74
74
74
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 '18 at 12:23
StoryTellerStoryTeller
101k12210276
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 '18 at 12:23
StoryTellerStoryTeller
101k12210276
edited Nov 14 '18 at 12:27
answered Nov 14 '18 at 12:23
StoryTellerStoryTeller
101k12210276
answered Nov 14 '18 at 12:23
StoryTellerStoryTeller
101k12210276
answered Nov 14 '18 at 12:23
StoryTellerStoryTeller
101k12210276
101k12210276
8
So theoretically one could implement different behaviour forFoo==StringandString==Foo
– hehe3301
Nov 14 '18 at 12:25
54
Yes, you could. But you definitely shouldn't.
– Matthieu Brucher
Nov 14 '18 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 '18 at 13:46
22
@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 '18 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 '18 at 9:12
add a comment |
8
So theoretically one could implement different behaviour forFoo==StringandString==Foo
– hehe3301
Nov 14 '18 at 12:25
54
Yes, you could. But you definitely shouldn't.
– Matthieu Brucher
Nov 14 '18 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 '18 at 13:46
22
@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 '18 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 '18 at 9:12
8
8
So theoretically one could implement different behaviour for
Foo==String and String==Foo– hehe3301
Nov 14 '18 at 12:25
So theoretically one could implement different behaviour for
Foo==String and String==Foo– hehe3301
Nov 14 '18 at 12:25
54
54
Yes, you could. But you definitely shouldn't.
– Matthieu Brucher
Nov 14 '18 at 12:25
Yes, you could. But you definitely shouldn't.
– Matthieu Brucher
Nov 14 '18 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 '18 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 '18 at 13:46
22
22
@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 '18 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 '18 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 '18 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 '18 at 9:12
add a comment |
5
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 '18 at 12:25
Matthieu BrucherMatthieu Brucher
16.4k32143
12
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 '18 at 21:02
add a comment |
5
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 '18 at 12:25
Matthieu BrucherMatthieu Brucher
16.4k32143
12
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 '18 at 21:02
add a comment |
5
5
5
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 '18 at 12:25
Matthieu BrucherMatthieu Brucher
16.4k32143
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 '18 at 12:25
Matthieu BrucherMatthieu Brucher
16.4k32143
edited Nov 14 '18 at 21:47
answered Nov 14 '18 at 12:25
Matthieu BrucherMatthieu Brucher
16.4k32143
answered Nov 14 '18 at 12:25
Matthieu BrucherMatthieu Brucher
16.4k32143
answered Nov 14 '18 at 12:25
Matthieu BrucherMatthieu Brucher
16.4k32143
16.4k32143
12
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 '18 at 21:02
add a comment |
12
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 '18 at 21:02
12
12
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 '18 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 '18 at 21:02
add a comment |
draft saved
draft discarded
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
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
21
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 '18 at 12:29
4
related All you always dreamed to know about operator overloading but never cared to ask.
– YSC
Nov 14 '18 at 12:33
3
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 '18 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 '18 at 17:04
3
@TobySpeight - eel.is/c++draft/over.match.oper#3.4
– StoryTeller
Nov 14 '18 at 17:13