Sean Parent wrote:
Why would we have a separate default relation for set/map then std::less? std::less is intended to map to operator <() on the type _or_ to a total ordering for the type if operator <() is not defined. That's what the standard says - it is intentional (Alex would have had operator <() defined even for types such as complex - but
That is also how I interpret his intent based on what is currently in the standard, and that is why I maintain that *under the current standard*, the appropriate way to make a type ordered (even if only for the associatives) is via defining operator<.
couldn't get that through the standard - he was especially concerned with pointer comparisons to separate containers because this is very useful. Not being able to change the language he at least got the change for std::less (not being there this is probably a misrepresentation of history - but the Alex's intent was that a total ordering should be present nearly everywhere) - he was using operator <() even in the cases he new it was "wrong", because there is no operator [glyph for < with a loop at the small end]. I convinced him that std::less<> is a reasonable way to spell [glyph for < with a loop at the small end.]
OK, let's get back to:
Why would we have a separate default relation for set/map then std::less?
and:
As for what I expect std::greater<> et al. to do - I had that in my earlier 6 point note - they _better_ be defined consistently with std::less.
If the standard was written with this in mind, greater<>, less_equal<> and greater_equal<> would have been defined in terms of less<>. It is not reasonable to provide four customization points that the user is supposed to keep in sync. For me the fact that less_equal returns x <= y is strong evidence that it is not supposed to be a customization point, but a function object alias of operator<=.
For pair<shared_ptr<>, int> - what makes shared_ptr special?
Why should it be special? If a type K is ordered, pair<K, int> should also be.