Re: [boost] SafeInt code proposal

Subject: Re: [boost] SafeInt code proposal
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2009-06-22 17:06:01

AMDG

Niels Dekker - address until 2010-10-10 wrote:
> Steven Watanabe wrote:
>> I don't think that non-template friends should be defined inline in a 
>> class template because they are always supposed to be instantiated 
>> regardless of whether they are used or not (unlike ordinary members).
>
> Thanks, Steven.  Do I understand correctly that when you look at the 
> following example, you find the definition of operator+ preferable to 
> operator- ?
>
>   //////////////////////////////////////////////////////////
>   template <typename> class safe_int;
>
>   template <typename T>
>   safe_int<T> operator+(safe_int<T>, safe_int<T>);
>
>   template <typename T> class safe_int
>   {
>   public:
>     friend safe_int operator+ <>(safe_int, safe_int);
>
>     inline friend safe_int operator-(safe_int, safe_int)
>     {
>       throw "operator- not yet implemented.";
>     }
>   };
>
>   template <typename T>
>   safe_int<T> operator+(safe_int<T>, safe_int<T>)
>   {
>     throw "operator+ not yet implemented.";
>   }
>   //////////////////////////////////////////////////////////
>
> I still hesitate, because the non-template inline friend, operator-, 
> appears to support implicit conversions more intuitively... I think.

Sorry.  I reacted automatically, because of the problems that
I've had with inline friends.  In this case, I think it's not a problem
to define them inline.  The cases that cause problems are like:

template<class Iterator>
struct reverse_iterator {
    friend reverse_iterator operator+(typename Iterator::difference_type 
n, reverse_iterator iter) {
        return(reverse_iterator(iter.base() - n)); // oops... early 
error if Iterator is not a RandomAccessIterator
    }
};

For safe_int, you could only run into problem by both
a) supporting user-defined type.  I don't see the point of this.
b) only requiring the underlying type to support division (e.g.) if
    the user tries to divide two safe_ints.

> Isn't support of such conversions (in a symmetrical way) the main 
> reason to declare such operators as non-members, rather than as member 
> functions?

Maybe.  For me it's more important that the operators are defined
consistently and there is no way to overload an operator as a member
with the first argument being of a different type.  In any case, it's
okay to support implicit conversions for both arguments or neither,
as far as I am concerned.  It's the matter of supporting implicit 
conversions
only for the second argument that makes the member operator really
unattractive.

In Christ,
Steven Watanabe