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

From: Daryle Walker (darylew_at_[hidden])
Date: 2006-07-10 23:46:30

On 7/6/06 5:20 AM, "Martin Bonner" <martin.bonner_at_[hidden]> wrote:

>> Daryle Walker wrote:
[SNIP]
>>> Conversely, calling code must not
>>> hard code use of "operator <"
> agreed.
>>> or "std::less<>",
> disagree
>>> unless that code
>>> requires types with a natural ordering.  (The standard algorithms
>>> have variants that either assume "operator <" or take in a
>>> comparison parameter.)
> 
> I think specializing std::less<> for types that don't have a natural
> order is /exactly/ the right way to enable such types to be stored in an
> associative container.

Looking at this part of the Boost shared_ptr docs:

> [Operator< has been preferred over a std::less specialization for consistency
> and legality reasons, as std::less is required to return the results of
> operator<, and many standard algorithms use operator< instead of std::less for
> comparisons when a predicate is not supplied. Composite objects, like
> std::pair, also implement their operator< in terms of their contained
> subobjects' operator<.
>
> The rest of the comparison operators are omitted by design.]

in <http://www.boost.org/libs/smart_ptr/shared_ptr.htm>, even these authors
agree with me that it's wrong to define "std::less<>" inconsistently with
"operator <" (in this case by providing only the former and not the latter).
I obviously disagree with them providing a fake "operator <" in the first
place, though.

If you are modeling data that has a standardized order, then it's OK to
define (all) the ordering operators.  If the order is something that you
made up, and doesn't naturally flow with the model, then leave it out as a
separate function (object).  Don't shove in an ordering scheme via
operators, especially if there more than one way to do it[1].  The Standard
function and class templates provide ways to override the comparison
routines, use them.

> The algorithms are a different case.  sort doesn't make sense for a type
> that doesn't have a natural order, and in that case the user needs to
> provide an appropriate comparison.
[TRUNCATE]

[1] If you make a fake order for "std::complex<>", would you compare real
components then imaginary components, or would you use magnitude then angle?

-- 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT hotmail DOT com