Re: [boost] operators.hpp issue

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-06-28 10:23:01

Helmut,

What you're saying makes sense, but I think we need to be careful. A
conforming compiler will generate these functions even if unused, so it
could break code.

Actually, I thought of a pretty strong counterexample: take a look at
random_access_iterator_helper. It makes sense to subtract the distance type
from the iterator type. Does it make sense to convert the distance type to
the iterator type? I don't think so.

So, I think we'd better stay with what we've got, or at most, add an
additional operator template.

-Dave
----- Original Message -----
From: <helmut.zeisel_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, June 28, 2001 10:21 AM
Subject: [boost] operators.hpp issue

> In operators.hpp,
> the commutative two-type versions of the operators,
> such as addable2 have both versions of the operators defined:
>
> struct addable2 : B
> {
>      friend T operator+(T x, const U& y) { return x += y; }
>      friend T operator+(const U& y, T x) { return x += y; }
> };
>
> the non-commutative versions, such as subtractable2
>
> have only one version:
>
> struct subtractable2 : B
> {
>      friend T operator-(T x, const U& y) { return x -= y; }
> };
>
> Shouldn't there be a second version such as
>
>      friend T operator-(const U& x, const T& y)
>

>        T x1(x);
>        return x1 -= y;
>      }
>
> IMHO, it does not make much sense to provide the
> two-type versions of the operators when U is not convertible to T.
>
> Helmut
>
>
>
>
>
> Info: http://www.boost.org  Unsubscribe:
<mailto:boost-unsubscribe_at_[hidden]>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>