views:

209

answers:

5

I this post, I've seen this:

class MonitorObjectString: public MonitorObject {
    // some other declarations
    friend inline bool operator==(/*const*/ MonitorObjectString& lhs,
                                  /*const*/ MonitorObjectString& rhs)
    { return lhs.fVal==rhs.fVal; }
}


Before we can continue, THIS IS VERY IMPORTANT:

  • I am not questioning anyone's ability to code.
  • I am just wondering why someone would need non-const references in a comparison.
  • The poster of that question did not write that code.

This was just in case. This is important too:

  • I added both /*const*/s and reformatted the code.


Now, we get back to the topic:

I can't think of a sane use of the equality operator that lets you modify its by-ref arguments. Do you?

+5  A: 

Most likely they forgot the const. Operator overloads should behave consistently and not perform 'out of character' actions.

As a general rule, an equality operator should never modify any of the objects it is comparing. Declaring const enforces this at the compiler level. However, it is often left out. "Const correctness" is very often overlooked in C++.

Andrew Rollings
+1  A: 

There's clearly no requirement for non-const args in this case and, like you, I wouldn't think there's any general case for it either.

However, it's certainly the case that const-correctness problems can push their way up from lower levels of the code, and if you can't correct them low-down, then you might have to work around them higher up. Perhaps that's what happened here at some point?

Will Dean
+5  A: 

Perhaps the classes use a form of lazy initialization. When the data is accessed, proper initialization must occur, and the data must be fetched. This may change class members.

However, lazy initialization can be formed so that modification to the class isn't necessary. This can be accomplished by using the Pimpl idiom (by a pointer to a private class) or by using the mutable keyword (not recommended!).

strager
Or the class members that may change could be declared as `mutable`.
Eduardo León
@Eduardo, C++? Could you elaborate a little please?
strager
I've never seen code in other languages that cares if your objects are constants. The only other language I know that cares about that is C, but it doesn't allow operator overloading.
Eduardo León
You always prefer to have the parameters const. Principle of least surprise. If your class does something behind the scenes, for example caching, you should be using mutable to mask off those side effects.
Greg Rogers
This doesn't necessarily follow.See: http://www.parashift.com/c++-faq-lite/const-correctness.html#faq-18.10
Andrew Rollings
@Eduardo, Just Googled "C++ mutable" and I was suprised! I never knew such thing existed in C++ (and I'm glad I didn't!). Still, he's asking why the parameters are non-const, not how to correct the problem. I still believe my answer (pointers) is better. =]
strager
Ignore prior comment. Answer has been edited to take it into account.
Andrew Rollings
@stranger: They're non-const because the function was badly written. Comparison functions should be pure functions, i.e. have no side effects.
rlbond
+2  A: 

There's a more baffling problem with the issue you bring up.

If I have two MonitorObjectStrings that are already const, I can't use this equality function.

Shmoopty
Yes, that's the problem.
Eduardo León
+1  A: 

If you can't use const because you're modifying operands, you're badly misusing operator overloading.

If you can't use const because the implementation calls non-const functions, you really should clean those up, or at least provide const alternatives.

If you're calling into code you can't change which doesn't use const, I'd use the const anyway, use const_cast at the deepest available point, and comment it.

As Shmoopty pointed out, the operator is a lot less useful than it should be since it can't be used on const objects, even if only one of them is const. A numeric equality operator that wouldn't support "a == 5" would violate the Law of Least Astonishment in a big way.

David Thornley