Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk