non-const operator overloads not invoked about catch2 HOT 6 CLOSED

That's an interesting one! I hadn't thought of a non-const member function . . .

I think I'm with you on this one - if you must have one, then the canonical form of a member op==() is 'const'.

Perhaps you could capture the non-const case and issue a more sensible compile time error ?

from catch2.

@colonelsammy I could possibly force a descriptive error message - but it would still be limiting your options - what if you don't control the source?
I think providing a non-const operator ==, or an operator == that takes its argument by non-const ref, are the lesser two of four evils (when you add in providing const and non-const overloads and making them do something different). After all the first two are probably just an oversight. The other two are deliberately malicious!
That's why I'm leaning towards supporting the former two at the expense of the latter two.

from catch2.

About limiting your options, remember that the operator== can be defined outside the class, so even if you can't modify the class in question, you can always define a non-member const operator==. It's up to you to decide if it's reasonable to put this burden on the library user though. ;)

(But it does seem like a very rare case, and if it saves you a lot of trouble, it may be worth it)

from catch2.

Thanks for the comments.
I've gone with the const_cast approach for now but I may revisit this in the future.

from catch2.

Reading through the comments, I'm having a hard time tracking exactly what is and isn't supported.

I believe these are the four options - which ones are supported? I'm trying to figure out if my current experience is the expected behavior or not.

MyClass {
  public:
   bool operator==(MyClass &rhs); /* supported ? */
   bool operator==(const MyClass &rhs); /* supported ? */
   bool operator==(MyClass &rhs) const; /* supported ? */
   bool operator==(const MyClass &rhs) const; /* supported ? */
};

from catch2.

Only the last one is.

from catch2.