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

From: Martin Bonner (martin.bonner_at_[hidden])
Date: 2006-07-06 05:20:48

> Daryle Walker wrote:
>> ??? Wrote
>>> Because operator== has only one purpose in C++: comparison for
>>> equality. Operator<, on the other hand, has two common roles.
>>> 
>>> For classes that have natural ordering, it should define this
>>> ordering, and then all the other operators (> <= >=) should be
>>> defined as well. Classes that doesn't have this natural ordering,
>>> often still define operator< just to be able to be used in ordered
>>> containers. In such cases, operator< doesn't define a natural
>>> ordering because there isn't any. Instead, it just defines an
>>> ordering "that works" for ordered containers, nothing more. It
>>> doesn't need to compatible with operator== and !=, and defining
>>> operators >, <=, >= is misleading and should be avoided.
>> 
>> The later role is invalid.  The reason is that the version of STL
>> that made it into the Standard specifies an extra parameter for
>> ordered containers for a comparison operation.  It allows two
>> containers of the same element type to use different comparison
>> criteria (at compile- and/or run-time).  This invalidates the need
>> for a fake "operator <" since you can always package the comparison
>> routine in an extra parameter. 

>> 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.

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.
>> 
>> Making a fake "operator <" just for ordered containers invalidates
>> the work of those who added comparison parameters in standard
>> classes/functions. 
> 
> You have a point there, no doubt. On the other hand, Library writers
> should supply some kind of functor to be used with their types in
> conjunction with ordered containers (when appropriate, and
> boost::variant is of course appropriate). How should this functor be
> called? You might say there should be some convention, but there isn't
> any right now, and some libraries use operator< for this purpose. Is
> it 
> that bad if operator< is the convention? I'm not sure. It's sure is
> convenient to use ordered containers like that... And it seems to me
> that there is no major drawback to this, because no other order
> operator 
> is provided. But I guess it's highly dependent on taste...
> 
>> The issue is different for the "==" and "!=" operators because two
>> objects can have their state checked for equivalence without having
>> a standardized order.  The "std::complex<>" template classes are an
>> example. 
> 
> std::complex doesn't have operator<. std::tr1::shared_ptr does. So it
> seems the standard isn't very helpfully consistent here...
> 
>>> boost::shared_ptr is a good example of such a class with no natural
>>> ordering, with operator== and !=, with operator<, but without the
>>> other operators. And shared_ptr is of TR1 strength...
>> 
>> Ordering for pointers is generally defined if both pointers are part
>> of the same array segment.  (Either one or both of the pointers can
>> be at the "one-past-the-end" point of said segment.)  If two
>> "shared_ptr" objects can be used for points in an array segment[1],
>> then comparison can be allowed with ALL four operators ("<", ">",
>> "<=", and ">=").  Otherwise, none of those operators should be
>> defined and any current existence of such operators should be
>> considered a bug. 
> 
> I didn't quite understand that last paragraph. shared_ptrs doesn't
> have 
> to point to objects in array (actually, they better not), but there
> can 
> be arrays of shared_ptrs. So should the shared_ptr class provide order
> operators or shouldn't it? Anyway, the committee already made up it
> mind 
> about the answer to this question...
> 
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost 

-- 
Martin Bonner
Martin.Bonner_at_[hidden]
Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ,
ENGLAND Tel: [phone]