Say I had class/struct Foo
struct Foo {
int a, b;
bool operator< (Foo const& r){
return a < r.a;
}
bool operator== (Foo const& r){
return a==r.a&&b==r.b;
}
};
Foo bar = { 5, 1 };
Foo baz = { 5, 2 };
Now bar == baz is false but so are bar < baz and baz < bar.
Note that here the ordering completely ignores b but b is part of the equality relation.
Technically yes, you are ordering them by the
amember directly, which should be fine for eg.std::set. Basically they behave like integers, ie. if a < b and b < c then a < c, etc. I don’t think operator == affects the validity of the ordering implied by operator <.However – it is a bad idea to define two operators on the same class which imply different things about it, because it is likely to prove confusing to users of that class. As far as I know it wouldn’t directly break any STL containers since they use only one of the two operators, but it would certainly confuse me that you can have this case where !(bar < baz) and !(baz < bar) but !(bar == baz).
In a case like this I would prefer to provide as a member only the operator that is more natural for the class, and make the other available through a standalone struct that can be supplied as a template parameter to the STL container. To me that makes it clearer that it’s a way of ordering instances of the class which isn’t necessarily equivalent to the other member operators.