[maxlybbert]

Maybe "doesn't work" is the wrong phrase. Usually, it does what people expect (except that the library ignores any "operator==" or "operator!=", which surprises people who went through the trouble to define them). And depending on what "operator<" does, it's possible for distinct values (a.k.a., not-equal values) to compare "equal." So to avoid confusion, people start using phrases like "equivalent" instead of "equal." But usually there's no real confusion: if you sort a list of strings by length, nobody's surprised when "hello" and "green" compare "equal," even though they have different contents. Everybody realizes that they have equal lengths, not equal contents.

The main things I've actually had to watch out for are floating point values that could have not-a-numbers (e.g., https://en.cppreference.com/w/cpp/numeric/math/isunordered.h... ), and possibly Unicode strings that aren't normalized ( https://unicode.org/reports/tr15/ ), but those act weird in all software I'm familiar with. Because people forget about the relevant edge cases.

[spyrja]

Yep, exactly. NAN's truly are a great example of just how weird an edge case can get too!

  #define isNan(X) ((X) != (X))

[metadat]

For anyone else who forgot this or is unfamiliar with why / how it "works":

> #define isNan(X) ((X) != (X))

> Works by exploiting a unique property of NaN (Not a Number) values in the IEEE-754 floating point standard: a NaN is not equal to itself. In other words, if you compare a floating-point variable to itself and the result is false ((X) != (X)(X)!=(X)), then X X is NaN.

Fantastic example, thank you @spyrja!