In article <2.2.32.19970822191032.0030d8ac@central.beasys.com>,
David R Tribble  <david.tribble@central.beasys.com> wrote:
>I will also point out that (2) can be rewritten as:
>
>    a = b;      // (2a), operator =() can be const
>    a = c;      // (2b), operator =() can be const

But replace a with a more complex expression and the justification makes a
little more sense, e.g.

(a[foo(bar(b[i++]))+func(c++)] = d) = e;

The reason why C doesn't need this rule is because such an expression in C
is silly; '(a = b) = c;' would be equivalent to 'b; a = c;' unless a were
volatile.  In C++, since user-written assignment operators can have side
effects, this equivalence doesn't hold.

--
Barry Margolin, barmar@bbnplanet.com
BBN Corporation, Cambridge, MA
Support the anti-spam movement; see <http://www.cauce.org/>
Please don't send technical questions directly to me, post them to newsgroups.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Benedikt Weber wrote:
>
> The draft standard describes in the complex class:
>
> complex<T>& operator= (const T&)
>
> However, it does not say (at least I cannot find it) what the meaning
> should be. ...

It was an oversight in the draft. The declarations of the
various versions of operator= have been removed, since they
are covered by the section quoted below. That section also
applies to the draft where the declarations were included,
of course. Since no specification was given for the assignment
operator, it must have the default assignment operator
semantics.
---
Steve Clamage, stephen.clamage@eng.sun.com

-----------------------------
17.2.2.2 Functions within classes

For the sake of exposition, Clauses 18 through 27 do not describe
copy constructors, assignment operators, or (non-virtual) destructors
with the same apparent semantics as those that can be generated by
default (12.1, 12.4, 12.8).

It is unspecified whether the implementation provides explicit
definitions for such member function signatures, or for virtual
destructors that can be generated by default.
-----------------------------
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Benedikt Weber mentioned the '=' operator in the STL:
> The draft standard describes in the complex class:
>   complex<T>& operator= (const T&)

Steve Clamage <stephen.clamage@eng.sun.com> pointed out:
> Since no specification was given for the assignment
> operator, it must have the default assignment operator
> semantics.

I'm curious.  Is there a reason why operator=() does not return a const
reference?

Unless I'm mistaken, the default semantics for assignment are that the
lvalue must be assignable, but that the result of the assignment expression
is not itself an assignable lvalue.  I.e., given 'a = b', the 'a' must be
an assignable lvalue all right, but the result of the 'a = b' expression as
a whole is not an lvalue.

Is this rule subverted in the STL, and if so, why?

Also, if the compiler generates a default operator=() for a class, does it
also return a non-const reference?

C++, the PL/1 of the 90s.
--------------------.      BEA Systems, Inc. ,-.  +1-972-738-6125 Office
David R. Tribble     \   ,------------------'   \ +1-972-738-6111 Fax
http://www.beasys.com `-'  Dallas, TX 75248      `-----------------------
david.tribble@noSPAM.beasys.com            http://www.flash.net/~dtribble
-------------------------------------------------------------------------
Send junk to: postmaster@agis.net mrchig@easynet.co.uk
 emailer@qlink2info.com simrem@answerme.com office@canma.dyn.ml.org
 markdan3@earthlink.net clover@earthfriends.com office@savetrees.com
 abuse@cyberpromo.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

David R Tribble wrote:
>
> Benedikt Weber mentioned the '=' operator in the STL:
> > The draft standard describes in the complex class:
> >   complex<T>& operator= (const T&)
>
> Steve Clamage <stephen.clamage@eng.sun.com> pointed out:
> > Since no specification was given for the assignment
> > operator, it must have the default assignment operator
> > semantics.
>
> I'm curious.  Is there a reason why operator=() does not return a const
> reference?
>
> Unless I'm mistaken, the default semantics for assignment are that the
> lvalue must be assignable, but that the result of the assignment expression
> is not itself an assignable lvalue.

You are thinking of C. The C++ rule is looser.

>From the C++ draft standard, 5.17 "Assignment operators":
"The result of the assignment operation is the value stored in the left
operand after the assignment has taken place; the result is an lvalue."

Since the left side of any assignment must in all cases be assignable
(non-const), it would be contradictory if the default copy-assignment
operator returned a reference to const. Consequently, the default
copy-assignment operator always returns a reference to the (non-const)
left side of the assignment.

A copy-assignment operator is one which has the form
 T& T::operator=( cv T& );
where "cv" is empty or is some combination of "const" and "volatile".

--
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <2.2.32.19970819205208.00347168@central.beasys.com> David R Tribble <david.tribble@central.beasys.com> writes:

> Unless I'm mistaken, the default semantics for assignment are that the
> lvalue must be assignable, but that the result of the assignment expression
> is not itself an assignable lvalue.  I.e., given 'a = b', the 'a' must be
> an assignable lvalue all right, but the result of the 'a = b' expression as
> a whole is not an lvalue.

You are mistaken.  The statement is true of C, but not of C++.
--
    --Andrew Koenig
      ark@research.att.com
      http://www.research.att.com/info/ark
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Steve Clamage <stephen.clamage@Eng.Sun.COM> wrote:

>You are thinking of C. The C++ rule is looser.
>
>>From the C++ draft standard, 5.17 "Assignment operators":
>"The result of the assignment operation is the value stored in the left
>operand after the assignment has taken place; the result is an lvalue."
>
>Since the left side of any assignment must in all cases be assignable
>(non-const), it would be contradictory if the default copy-assignment
>operator returned a reference to const. Consequently, the default
>copy-assignment operator always returns a reference to the (non-const)
>left side of the assignment.
>
>A copy-assignment operator is one which has the form
> T& T::operator=( cv T& );
>where "cv" is empty or is some combination of "const" and "volatile".

Robert Murray claims on pg 33 of "C++ Strategies and Tactics" that
returning an lvalue from an assignment is not a good idea.  His argument
is:

   "By returning a const refernce, we prevent assignment from being used
    as an lvalue:

        (a = b) = c;

    Not only does this look strange, but its behavior is surprisingly
    subtle.  For instance, consider what happens if a and c are
    references to the same location."

Is this outdated?  Is it really an issue at all?

--Bob

====================================================================
Bob Steagall                                 steagall@deltalogic.com
DeltaLogic, Inc.                           http://www.deltalogic.com
1537 Kew Road                                   Voice (216) 321-8200
Cleveland Hts, OH 44118-1204                    Fax   (216) 321-6976
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

The draft standard describes in the complex class:

complex<T>& operator= (const T&)

However, it does not say (at least I cannot find it) what the meaning
should be. Obviously, it should be

complex<T>& operator= (const T& re)
{ re_ = re;  im_ = 0.0; return *this; }

However one of my compilers does

complex<T>& operator= (const T& re)
{ re_ = re; return *this; }

and leaves the imaginary part untouched. While this behaviour might be
resonable for the general template class, it is not acceptable for
complex<double>. Consider

   complex<double> c(1.0, 2.0);
   c= 10.0;

This would return c as (10.0, 2.0) instead of the expected value
(10.0, 0.0).

I think the behaviour should be documented in the draft standard!!

Benedikt Weber, ETH Zurich
weber@ibk.baum.ethz.ch
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Benedikt Weber <weber@ibk.baum.ethz.ch> writes:

[snip]
> However one of my compilers does
>
> complex<T>& operator= (const T& re)
> { re_ = re; return *this; }
>
> and leaves the imaginary part untouched. While this behaviour might be
> resonable for the general template class, it is not acceptable for
> complex<double>.

 This is rather a bug in the implementation of the library you
use. On page 680, chapter 22, section 5. Complex Arithmetic, "The C++
Programming language" (third edition, 1997) says :

 template <class T> class std::complex {
  // ...
  complex<T>& operator=(const T& z) // assign complex(z, 0)
  //...
 };


-- Gaby
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]