3

Is it a bad practice to overload global operator == and != for floating points ? I'm using fast floating-points in a game environement, and i was thinking about using fuzzy comparison everywhere as i can't imagine a situation where i don't expect extremely close numbers not to be equals.

Any advice ?

taocp
  • 23,276
  • 10
  • 49
  • 62
Adrian Goudard
  • 115
  • 1
  • 9
  • Sounds good, go for it. – andre May 28 '13 at 15:34
  • If every aspect of the game should treat all floating points like that, then I see no problem with it. Just let your other developers know what's happening so they aren't confused later. If you are using an encapsulated float object, I'd probably just add a method to it like `fuzzyCompare()` or something, though. – crush May 28 '13 at 15:35
  • 1
    No it doesn't sound good. Just use a normal function like `floatcompare(f1,f2)` when you need a custom comparison. – stardust May 28 '13 at 15:36

3 Answers3

11

You can't. C++ operator overloads must involve at least one user-defined type.

And even if you could, it would probably be a bad idea. Users expect equality to be transitive, i.e. if a == b and b == c, then a == c. It sounds like your fuzzy comparison would not be transitive.

Oliver Charlesworth
  • 267,707
  • 33
  • 569
  • 680
  • 1
    He could use a wrapper type everywhere that more or less transparently acts like a floating point number. But the second point is still a nasty issue. It would be far too easy to let some standard library function try to use them and cause UB. – aschepler May 28 '13 at 15:46
  • This is a consequence that i will have to deal with anyway. Transitivity shall be assume by shared computations. But as you say if it's not supported by c++, no reason to discuss about it. I'll just use a function FuzzyCompare( float x, float y );. – Adrian Goudard May 28 '13 at 16:16
1

Other posts mentioned technical problems, from another perspective:

Its a bad practice because nobody expects these operators to be overloaded, while reasonable people will expect an almostEquals function. Its strange and odd and masks what is really going on.

Mikhail
  • 7,749
  • 11
  • 62
  • 136
0

The problem is: if you could actually do that, and in the code you saw something like:

if ( a == b ) {
    // more things...
}

Would you know if it is invoking the regular comparison or the, say, fuzzyCompare() function? In order to distinguish between both, you would have to look up in the code what is the type of a and b... You wouldn't be able to read your own code without asking yourself a lot of questions, and probably cross-referencing a lot of variables with their types.

This is exactly the scenario in which operator overloading becomes a nightmare, and the reason its abuse led it to be dropped for languages such as Java.

Hope this helps.

Baltasarq
  • 12,014
  • 3
  • 38
  • 57
  • But then one invokes the standard counterargument, which is that `equals(a, b)` is just as opaque... – Oliver Charlesworth May 28 '13 at 15:47
  • Sorry, @Oli, I don't understand what you mean. Can you elaborate? – Baltasarq May 28 '13 at 16:19
  • I'm referring to the argument that operator overloads hide information about what's going on. It's true. But then it's also true about equivalent code written without operator overloads (e.g. `equals()` instead of `operator==`, `plus()` instead of `operator+`). – Oliver Charlesworth May 28 '13 at 16:29
  • Sorry, still don't follow. if ( a.equals( b ) ) is nearly literal for me, it does not hide anything going on. Are you talking from a general point of view or you refer to the specific case of the equals() method in Java? That latter case actually hides a few things. – Baltasarq May 28 '13 at 16:54
  • I'm saying that an overloaded operator hides no more information than a "proper" named function does. In both cases, if you want to know what's really going on, you're going to need to find the function definition. – Oliver Charlesworth May 28 '13 at 16:55
  • Well, @Oli, provided the code is well built, an appropriately named function should be straightforward to understand. Maybe you'll have to go to the function definition in order to know what technique exactly uses, etc., but at least in the worst case, this will happen only once, you won't doubt continously in the case that operator == would be overloaded. – Baltasarq May 28 '13 at 19:37