Overloaded assignment operator

Discussion in 'C++' started by Bruno Panetta, Oct 18, 2007.

  1. 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.
     
    Bruno Panetta, Oct 18, 2007
    #1
    1. Advertising

  2. Bruno Panetta

    Kai-Uwe Bux Guest

    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
     
    Kai-Uwe Bux, Oct 18, 2007
    #2
    1. Advertising

  3. Bruno Panetta

    James Kanze Guest

    On Oct 18, 8:44 am, Kai-Uwe Bux <> wrote:
    > 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:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Oct 18, 2007
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Nitin Bhardwaj
    Replies:
    8
    Views:
    938
    Andrey Tarasevich
    Jul 14, 2003
  2. August1
    Replies:
    9
    Views:
    522
    Risto Lankinen
    Sep 20, 2004
  3. saxman
    Replies:
    2
    Views:
    438
    saxman
    Jun 12, 2007
  4. Replies:
    8
    Views:
    446
    terminator
    Aug 29, 2007
  5. Replies:
    4
    Views:
    333
    James Kanze
    Jun 27, 2008
Loading...

Share This Page