Re: [boost] Interested? Simplify usage of std::rel_ops

From: Christopher Eltschka (celtschk_at_[hidden])
Date: 2006-07-15 16:20:36

Kevin Spinar schrieb:
> On 7/13/06, Christopher Eltschka <celtschk_at_[hidden]> wrote:
>> operator< and operator== of course can be defined anywhere the
>> std::rel_ops operators will find them (e.g. they could be defined as
>> class members instead).
> 
> Note that you really only have to define operator< as operator== could
> be written as
> 
> template<class T, class U>
> bool operator==(const T &lhs, const U &rhs) {
>    return !(lhs < rhs) && !(rhs < lhs);
> }
> 
> and the user could still define operator== themselves for optimization
> purposes (then you should make sure to define operator!= in terms of
> operator==).

I would have expected an ambiguity in that case (because both are found
with Koenig lookup), but a quick test with operator!= showed that at
least with gcc, indeed it works! Thinking about it, it probably works
because the one in std::rel_ops is a template, so the non-template
operator== takes precedence. I'm not sure if there are reasonable cases
where this would break with a templated user-defined operator.

However, one could make different base classes providing dofferent set
of operators, say

class A: rel::ops_from_less { ... }

derived all operators from operator< and

class A: rel::ops_from_less_and_equal { ... }

doesn't derive equal from less.

One could also make a version which derives all those operators from a
"3-way comparison function" a la strcmp. In that case one would have to
select a standardized name for that function as well. Maybe just
"compare3way"? In that case, maybe it would also make sense to define
that function for the other cases (i.e. automatically derive compare3way
from operator<).

> Are you going to allow comparision of different types (like I showed
> above) or strictly comparision among objects of the same type?

Well, at the moment I just delegate to std::rel_ops, so only comparing
strictly the same type is supported. However, it's trivial to change
this (i.e. write those functions again with two separate template type
arguments) so that arbitrary types can be compared. However I'm not sure
if it's a good idea: After all, it might trigger in a situation where we
don't want it (I'm not sure if such a situation could happen, however
it's something one should consider).

>> Alternatively it could be extended to support other typical operator implementations
>> not covered by the standard, e.g. defining operator@ in terms of operator@=.
> 
> Sounds good.

Doing some brainstorming, I get the following candidate list for useful
automatic operators:

* comparison operators from operator< and operator==
* operator @ from operator @=
* posfix operator++/-- from prefix one
* unary operator+ (returning just the object)
* maybe also binary - from + and unary -?

Any other good candidates?

Christopher Eltschka