14 ms·
I'm not sure I grok the `<=>` operator and the example they show seems to just show that `a == b`. Can someone explain what's going on with that?
by DeepYogurt 7y ago
I'm not sure I grok the `<=>` operator and the example they show seems to just show that `a == b`. Can someone explain what's going on with that?
- htfy96 7y agoPreviously you need to override all six operators (==, <=, <, >, >=, !=) to provide total order comparators. Now you only need to provide one method.
- bleair 7y agoHtfy96 is right. This post gives more examples. https://devblogs.microsoft.com/cppblog/simplify-your-code-with-rocket-science-c20s-spaceship-operator/ https://devblogs.microsoft.com/cppblog/simplify-your-code-wi... Along with automatic synthesis of all the operators, c++ 20 also clarified rules about overload-matching and automatic construction of objects for purposes of comparison, so you don’t have to write the friend methods to for example compare int to your type if you have trivial int-taking constructor for your type. Also if your == operator or != is more efficient than a full lexigrapgical comparison the compiler will now do the right thing
- inetknght 7y ago> I'm not sure I grok the `<=>` operator Think of `strcmp` which returns an int. The int can be <0, ==0, or >0. That same `strcmp` can then be used to implement all other standard comparison functions. `operator <=>` is the generalized version of that.
- johannes1234321 7y agoAn important part there is: Most users will never call <=> themselves. However somebody implementing a type can implement a single function and the compiler will translate usage of <, <=, ==, !=< >=, > to the single function. Reduces boiler plate in the implementation. (Think about it - most implementations of > or < will often use the same logic already, spelling this out is "annoying"; mind that for performance reasons it can still be worthwhile to implement a == explicitly as equal comparison is often faster than ordering, but that's something the type designer can chose)
- inetknght 7y ago> Think about it - most implementations of > or < will often use the same logic already, spelling this out is "annoying"; mind that for performance reasons it can still be worthwhile to implement a == explicitly as equal comparison is often faster than ordering, but that's something the type designer can chose Yup. My C++ code would often include a `int T.compare(const T& a)` member function. Then any comparison operator would be custom written too -- but only to delegate to the custom compare and check its result. This one feature alone will eliminate several lines of boilerplate.
- cogman10 7y agoDo you have an example of when == would be faster than a comparison? I can't think of any case that would have any appreciable difference in speed. Is it mostly around eliminating branching logic? Wouldn't there be a good chance that might be inlined and optimized away anyways?
- johannes1234321 7y agoOn case is string comparison. When implementing == I can shortcut if length doesn't matter the string can't be equal. When implementing <=> I however have to iterate in any case. (While there the question then is if the shortcut is really efficient, as the iteration might already stop on first character ...)