In C++ do you need to overload operator== in both directions?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
31
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







share|improve this question



















  • 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
    yesterday







  • 4




    related All you always dreamed to know about operator overloading but never cared to ask.
    – YSC
    yesterday






  • 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
    yesterday







  • 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
    yesterday







  • 3




    @TobySpeight - eel.is/c++draft/over.match.oper#3.4
    – StoryTeller
    yesterday














up vote
31
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







share|improve this question



















  • 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
    yesterday







  • 4




    related All you always dreamed to know about operator overloading but never cared to ask.
    – YSC
    yesterday






  • 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
    yesterday







  • 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
    yesterday







  • 3




    @TobySpeight - eel.is/c++draft/over.match.oper#3.4
    – StoryTeller
    yesterday












up vote
31
down vote

favorite
2









up vote
31
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







share|improve this question















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited yesterday









StoryTeller

88.8k12179245




88.8k12179245










asked yesterday









hehe3301

291312




291312







  • 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
    yesterday







  • 4




    related All you always dreamed to know about operator overloading but never cared to ask.
    – YSC
    yesterday






  • 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
    yesterday







  • 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
    yesterday







  • 3




    @TobySpeight - eel.is/c++draft/over.match.oper#3.4
    – StoryTeller
    yesterday












  • 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
    yesterday







  • 4




    related All you always dreamed to know about operator overloading but never cared to ask.
    – YSC
    yesterday






  • 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
    yesterday







  • 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
    yesterday







  • 3




    @TobySpeight - eel.is/c++draft/over.match.oper#3.4
    – StoryTeller
    yesterday







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
yesterday





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
yesterday





4




4




related All you always dreamed to know about operator overloading but never cared to ask.
– YSC
yesterday




related All you always dreamed to know about operator overloading but never cared to ask.
– YSC
yesterday




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
yesterday





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
yesterday





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
yesterday





@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
yesterday





3




3




@TobySpeight - eel.is/c++draft/over.match.oper#3.4
– StoryTeller
yesterday




@TobySpeight - eel.is/c++draft/over.match.oper#3.4
– StoryTeller
yesterday












2 Answers
2






active

oldest

votes

















up vote
49
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






share|improve this answer


















  • 5




    So theoretically one could implement different behaviour for Foo==String and String==Foo
    – hehe3301
    yesterday






  • 39




    Yes, you could. But you definitely shouldn't.
    – Matthieu Brucher
    yesterday










  • @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
    yesterday







  • 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
    yesterday










  • @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
    17 hours ago

















up vote
4
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.






share|improve this answer


















  • 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
    yesterday










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',
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


















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








up vote
49
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






share|improve this answer


















  • 5




    So theoretically one could implement different behaviour for Foo==String and String==Foo
    – hehe3301
    yesterday






  • 39




    Yes, you could. But you definitely shouldn't.
    – Matthieu Brucher
    yesterday










  • @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
    yesterday







  • 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
    yesterday










  • @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
    17 hours ago














up vote
49
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






share|improve this answer


















  • 5




    So theoretically one could implement different behaviour for Foo==String and String==Foo
    – hehe3301
    yesterday






  • 39




    Yes, you could. But you definitely shouldn't.
    – Matthieu Brucher
    yesterday










  • @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
    yesterday







  • 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
    yesterday










  • @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
    17 hours ago












up vote
49
down vote



accepted







up vote
49
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






share|improve this answer














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







share|improve this answer














share|improve this answer



share|improve this answer








edited yesterday

























answered yesterday









StoryTeller

88.8k12179245




88.8k12179245







  • 5




    So theoretically one could implement different behaviour for Foo==String and String==Foo
    – hehe3301
    yesterday






  • 39




    Yes, you could. But you definitely shouldn't.
    – Matthieu Brucher
    yesterday










  • @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
    yesterday







  • 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
    yesterday










  • @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
    17 hours ago












  • 5




    So theoretically one could implement different behaviour for Foo==String and String==Foo
    – hehe3301
    yesterday






  • 39




    Yes, you could. But you definitely shouldn't.
    – Matthieu Brucher
    yesterday










  • @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
    yesterday







  • 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
    yesterday










  • @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
    17 hours ago







5




5




So theoretically one could implement different behaviour for Foo==String and String==Foo
– hehe3301
yesterday




So theoretically one could implement different behaviour for Foo==String and String==Foo
– hehe3301
yesterday




39




39




Yes, you could. But you definitely shouldn't.
– Matthieu Brucher
yesterday




Yes, you could. But you definitely shouldn't.
– Matthieu Brucher
yesterday












@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
yesterday





@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
yesterday





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
yesterday




@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
yesterday












@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
17 hours ago




@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
17 hours ago












up vote
4
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.






share|improve this answer


















  • 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
    yesterday














up vote
4
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.






share|improve this answer


















  • 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
    yesterday












up vote
4
down vote










up vote
4
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.






share|improve this answer














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.







share|improve this answer














share|improve this answer



share|improve this answer








edited yesterday

























answered yesterday









Matthieu Brucher

5,5211128




5,5211128







  • 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
    yesterday












  • 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
    yesterday







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
yesterday




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
yesterday

















 

draft saved


draft discarded















































 


draft saved


draft discarded














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





















































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






-

Popular posts from this blog

How to check contact read email or not when send email to Individual?

Image
Clash Royale CLAN TAG #URR8PPP up vote 1 down vote favorite I'm using WordPress 4.9.8, CiviCRM to 5.5.1, I usually send email to contact by Search> Find contacts View contact details Action> Send email Send email ok, Contact received mail ok like picture But status only Email sent though contact read email or not. So, can CiviCRM can change status to Email read when contact read email? wordpress email share | improve this question asked Sep 26 at 0:12 ToanLuong 49 9 add a comment  |  up vote 1 down vote favorite I'm using WordPress 4.9.8, CiviCRM to 5.5.1, I usually send email to contact by Search> Find contacts View contact details Action> Send email Send email ok, Contact received mail ok like picture But status only Email sent though contact read email or not. So, can CiviCRM can change status to Email read when contact read email? wordpress email share | improve this question asked Se
Read more

Bahrain

Image
For other uses, see Bahrain (disambiguation). Sovereign island state in the Persian Gulf Kingdom of Bahrain مملكة البحرين   (Arabic) Mamlakat al-Baḥrayn Flag Coat of arms Anthem:  نشيد البحرين الوطني Bahrainona Our Bahrain Location of   Bahrain    (circled in red) Capital and largest city Manama 26°13′N 50°35′E  /  26.217°N 50.583°E  / 26.217; 50.583 Official languages Arabic Ethnic groups (2010 [1] ) 50.7% Arab (46% Bahrani, 4.7% other Arabs) 45.5% Asian 1% European 1.2% Others Religion Islam Demonym(s) Bahraini Government Unitary constitutional monarchy • King Hamad bin Isa Al Khalifa • Crown Prince Salman bin Hamad bin Isa Al Khalifa • Prime Minister Khalifa bin Salman Al Khalifa Legislature National Assembly • Upper house Consultative Council • Lower house Council of Representatives Independence • Declared Independence [2] 14 August 1971 • from United Kingdom [1] 15 August 1971 • Admitted to the United Nations 21 September 1971 • Kingdom of Bahrain 14 February 2002
Read more

Postfix configuration issue with fips on centos 7; mailgun relay

Image
Clash Royale CLAN TAG #URR8PPP up vote 0 down vote favorite I am trying to setup postfix to relay all mail generated on the local machine via SMTP to a mailgun relay. I have used the mailgun relay before with success on an ubuntu server, but I am migrating to a Centos 7 server which I will be running in FIPS mode. There error log is below, slightly sanitized. I have a small enough network that I choose to have each machine reach out to mailgun individually (this the loopback-only, 127.0.0.0/8 restrictions) and no firewall open port allowing smtp in to the machine. I assume the FIPS mode (and with it disabling of MD5) is causing problems, but I don't know how to overcome it or if it is even possible for tls_fprint to use some supported hash such as sha256 or sha512. However, the relay=none is slightly concerning since I have relayhost set, but perhaps that is because the smtp process is failing? Any help would be appreciated! postconf -n: alias_database = hash:/etc/alia
Read more