Re: template operator== not working

* Ben Voigt [C++ MVP]:


Nope. An expression is not necessarily a constant, and in particular, in C++,
an rvalue is not necessarily a constant. For class types it is in most cases
not constant, e.g. the std::vector<T>().swap(v) idiom for clearing a vector v
relies on this, and the rvalue non-constness is also used in the code below.

Applying my well-known telepathic powers, I think you're perhaps confusing an
expectation about the result of '*' in e.g. mathematics, with operator results
in C++.

The technique of using constants on the lhs has two common cases: literal, or
something named and declared 'const', which for the above and a class Rational
would mean

   Rational const product = a*b;
   if( product = c ) // Oops.

Unfortunately, in this context, operator= is one of those that can't be defined
as a free-standing function. If it could then the above would not even be
potential problem, because a temporary can't be bound to reference to non-const.
  With member operator= you can't directly prohibit assignment to non-const
rvalue (which is generally preferable, especially for optimization).

An alternative is to change the syntax for assignment, so that '=' simply isn't
valid. Examples: 'a.value() = b', or 'a.assignFrom( b )', or 'a ^= b'. The
'^=' syntax on the assumption that exclusive-or assignment isn't useful on its
own for this class.

Example that illustrates all three assignment syntaxes mentioned above (I would
not, however, do this, because I don't think =/== is a real problem):

<code>
template< typename T >
class AssignableRef
{
private:
     T* myRef;
public:
     AssignableRef( T& v ): myRef( & v ) {}
     T& operator=( T const& v ) { return myRef->assignFrom( v ); }
};

class Rational
{
private:
     Rational& operator=( Rational const& ); // No such.

public:
     Rational( int = 0 ) {}
     void swap( Rational& ) {}

     Rational& assignFrom( Rational const other )
     {
         Rational( other ).swap( *this );
         return *this;
     }

     Rational& operator^=( Rational const& other )
     {
         return assignFrom( other );
     }

     AssignableRef<Rational> value()
     {
         return AssignableRef<Rational>( *this );
     }

     Rational& operator*=( Rational const& ) { return *this; }
     bool operator==( Rational const& ) { return true; }
};

Rational operator*( Rational const& a, Rational const& b )
{
     return Rational( a ) *= b;
}

int main()
{
     Rational a, b, c;

     a ^= b; // OK, this is an assignment.
     a.assignFrom( b ); // OK, this is also an assignment.
     a.value() = b; // OK. this is also an assignment.

     if( a*b == c ) {} // OK, this is a comparision.
     //if( a*b = c ) {} // Oops, does not compile (which is OK).
}
</code>

The question is though, is the potential error detection really worth the
non-standard notation? If it isn't, then that means the potential error isn't
really that much of a problem in practice. And then the cost of a 'const'
result, in particular prohibiting optimization, is counter-indicated.

There are also other alternatives, such as the extremely dirty trick (formally
UB if you use the standard library) of redefining 'if' so that it /requires/ a
'bool' value. But that extremely dirty trick doesn't help with ?:, nor does it
help with assignment to bool... Another alternative: it might be that the
compiler can produce a warning that can be turned into an error, but this
alternative is compiler-specific. A third is, as mentioned, the convention
always writing something const on the left hand side of '==', although the logic
of that is questionable, for what if you forget, how can you detect that?

Best: simply don't write '=' instead of '==', and test the software so that any
such slip-ups are detected.

If '=' instead of '==' passes all tests, then, after all, it doesn't matter.


Cheers, & hth.,

- Alf

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?