Re: [boost] Please don't define a fake"operator<"just for ordered containers

From: Sean Parent (sparent_at_[hidden])
Date: 2006-07-13 16:44:45

Christoph Ludwig posted the correct reason why std::complex should  
not have an operator < () defined - sorry, my follow up using  
addition was poorly constructed.

What I am proposing is that std::less should be defined for  
std::complex.

> >> std::less is ambiguous. It could be that you wanted merely the
> >> function object representation of operator<, or it could be that  
> you
> >> wanted the default map/set ordering relation. It is not clear which
> >> of the two std::less is supposed to be.
> >
> > If shared_ptr doesn't support operator< it's not a problem, is it?
>
> The context is:
>
> - If we had a separate relation for set/map we would use that for
> settable/mappable objects.
> - Why is a separate relation better than just using less<>?
> - Because it is evident from the design of the standard library  
> that less<>
> isn't meant for that, not consciously, at least.
>
> "What should shared_ptr do" is a separate question. Under the  
> current status
> quo, it defines operator< to order pair< shared_ptr<>, int > as  
> well. Under
> a revised standard, it may well need to do something else,  
> depending on how
> the standard is changed.
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  
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.]

For pair<shared_ptr<>, int> - what makes shared_ptr special? This  
doesn't work pair<T*, int> today - I don't see why we should special  
case shared_ptr - especially in a way which should likely change in  
the future. Rather I'd recommend specializing std::less - note that  
you could also specialize std::less<> for std::pair<shared_ptr<>, T>  
(and the two other variants) if this is _really_ a big concern. I  
haven't run across a need to order pairs with shared_ptr (nor a pair  
with pointers for that matter).

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.

std::less is supposed to be operator <, unless operator < is not  
defined in which case std::less provides a total ordering. It isn't  
ambiguous.

Sean