I hadn't thought of that, and judging by the almost exlusively
T& result assignment operators around, just about nobody else
has either (although presumably the author of the book the OP
mentioned, Mr. Deitel, had).
That's because you're too young. When I was just starting C++,
it was a much debated point; all of my original operator=
returned const references. After some discussion with Scott
Meyer, I changed my policy---on the sole grounds that a
non-const reference is closer to what the built-in operator
does, and so closer to what users expect. The only more or less
valid use for it is in something like:
MyType&
operator+=( MyType& lhs, MyType rhs )
{
return lhs = lhs + rhs ;
}
In such cases, I far prefer using two statements, but I'm not
the only person in the world, and since this works with the
built in operator= (or the compiler generated default one),
people reasonable expect it to work with a user defined one.
I think I'll adopt that convention, for expressions with
internal side effects are generally ungood.
As I said, the point was strongly argued in the early 1990's.
Today, there seems to be a consensus for the non-const reference
(perhaps due to the influence of people like Scott Meyers). And
of course, you can't put an object whose operator= returns a
const reference in a standard container---the Assignable
requirements are that the expression t = u returns T&.
(Formally, at least. It works with both g++ and VC++, including
with concept checking activated in g++. Presumable, however, if
concepts ever get into the standard, all compilers will be
required to reject it.)
In the end, the point which convinced me (somewhat against my
better judgement) was the fact that when moving from a compiler
generated assignment operator to a user defined one, you don't
want the function signature to change, especially in a way that
might break user code (even if you don't like the style of said
user code).
perator=( const Test &rc_Test )