Overloaded assignment operator

[Bruno Panetta]

I am going through Deitel & Deitel's C++ book (section 8.8 of the
fourth edition), in which they construct an Array class and show how
to overload operators. The assignment operator is overloaded as
follows:

const Array &operator=(const Array &);

According to D&D, the const return is designed to avoid (a1 = a2) =
a3. My questions are:

1) Why is this necessary? After all, an assignment like (a1 = a2) = a3
works for ordinary variables.

2) What if you want to use this method on a non-constant Array object,
or if you want it to return a non-constant Array? I can see it still
works, but why don't the const declarations get in the way?

Thanks.

[Kai-Uwe Bux]

Bruno Panetta wrote:

I am going through Deitel & Deitel's C++ book (section 8.8 of the
fourth edition), in which they construct an Array class and show how
to overload operators. The assignment operator is overloaded as
follows:

const Array &operator=(const Array &);

According to D&D, the const return is designed to avoid (a1 = a2) =
a3. My questions are:

1) Why is this necessary? After all, an assignment like (a1 = a2) = a3
works for ordinary variables.

It is not necessary. It's a design decision, and a debatable one. Note that
the standard describes the Assignable requirement in Table 64 as follows:
the expression t=u has to have the postcondition that t be equivalent to u
and the return type T&. It follows that classes whose assignment operator
returns a const reference are not assignable. Consequently, something like

std::vector< Array >

is not required to compile. (Although in practice, only the most zealous
concept checking libraries will snap at that.)
Also note that the standard containers all have an assignment operator that
return a non-const reference (in fact, this is a container requirement). I
don't see a good reason to depart from this pattern.

2) What if you want to use this method on a non-constant Array object,

No problem.

or if you want it to return a non-constant Array?

Then you should make the return type non-const.

I can see it still works, but why don't the const declarations get in the
way?

Huh?

Please provide a piece of code that illustrates your worries.
Best

Kai-Uwe Bux

[James Kanze]

On Oct 18, 8:44 am, Kai-Uwe Bux <[e-mail]:

Bruno Panetta wrote:

I am going through Deitel & Deitel's C++ book (section 8.8 of the
fourth edition), in which they construct an Array class and show how
to overload operators. The assignment operator is overloaded as
follows:

const Array &operator=(const Array &);

According to D&D, the const return is designed to avoid (a1 = a2) =
a3. My questions are:

1) Why is this necessary? After all, an assignment like (a1 = a2) =a3
works for ordinary variables.

Note that the above assignment *doesn't* work for basic types or
pointers, but rather has undefined behavior (in C++ -- in C, it
shouldn't compile).

It is not necessary. It's a design decision, and a debatable
one. Note that the standard describes the Assignable
requirement in Table 64 as follows: the expression t=u has to
have the postcondition that t be equivalent to u and the
return type T&.

It's entirely possible that Deitel & Deitel wrote their work
before the STL became generally used. Given the constraints of
the STL, today, I don't think that there's any question to the
fact that the return type should be T&, and not T const&.
Before the STL became wide spread, there was considerable room
for discussion: the return of a const reference is as close as
you can come to similating the C behavior of the built-in types.
And many people don't agree with C++'s loosening of the rules
here. The use of a const reference here was a fairly wide
spread convention in earlier days.

It follows that classes whose assignment operator returns a
const reference are not assignable. Consequently, something
like

std::vector< Array >

is not required to compile. (Although in practice, only the
most zealous concept checking libraries will snap at that.)

One could argue that it is overspecified. IMHO, Assignable
should only require that assignment works as expected, with no
real constraints on the type of the return value (other than
that it can safely be ignored).

Also note that the standard containers all have an assignment
operator that return a non-const reference (in fact, this is a
container requirement). I don't see a good reason to depart
from this pattern.

Not departing from the general pattern is a different argument.
I dropped the const early myself, simply to be compatible with
the built-in types, even though it only affects programming
styles that I don't like to begin with.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]