On Fri, 18 Jun 2004 14:57:12 +0100, "John Harrison"
<jo*************@hotmail.com> wrote in comp.lang.c++:
"Matthew Polder" <ma***************@kodak.com> wrote in message
news:40***************@kodak.com...
Hi,
When a class Apple is written and the assignment operator is not
explicitly declared, the operator
Apple& operator=(const Apple&)
is created by the compiler. Is there any difference between this and
const Apple& operator=(const Apple&)
other than the second form means that you can't do this:
Apple a, b, c;
//Assume there is a function 'Apple operator+(const Apple&, const
Apple&)'
(a + b) = c; //not allowed with second assignment operator, I think.
No this would be allowed by either form of the assignment operator, assuming
a valid declaration of operator+.
The difference is this
(a = b) = c
With the second form (a = b) returns a const reference which cannot then go
on the left hand side of another operator= (because operator= is not a const
method).
(a = b) = c is pretty useless for built in types like int, but it is legal,
so why not make the same thing legal for user defined classes as well?
john
Given:
int a, b = 2, c = 3;
....then:
(a = b) = c;
....is syntactically legal in C++ (not in C), but perhaps it should not
be. Since the statement modifies the value of a twice without an
intervening sequence point, it produces undefined behavior.
I understand the purpose of changing the return type of the assignment
operators from rvalue (as they are in C) to lvalue, for use with user
defined types. There the assignment operator has the semantics of a
function, and there are sequence points.
There is no way to use the fact that assignment to a built-int
evaluates to an lvalue result other than using the & operator on it
without invoking undefined behavior. You can do this in C++, but not
in C:
#include <iostream>
void func(int *q)
{
++*q;
}
int main()
{
int x;
func(x = 3);
std::cout << "x = " x "\n";
return 0;
}
....and the output will be 4.
In fact this leads to the mess in C++ with volatile values. Given:
volatile int x;
int y; /* not volatile */
y = x = 3; /* equivalent to y = (x = 3) */
The first assignment, 'x = 3' produces not the integer value 3, but
the address of x. The C++ standard requires the compiler perform
lvalue to rvalue conversion, and it most certainly cannot optimize it
away with x being volatile.
In fact, it is at least arguable that:
x = 3;
....requires lvalue to rvalue conversion (reading x after writing),
because even though the rvalue is not used, the semantics of the
volatile type qualifier require it.
And think of memory-mapped hardware devices (the sort of thing one
uses volatile for) like UARTs where the transmit register is
write-only, the receive register is read-only, and they both occupy
the same address...
--
Jack Klein
Home:
http://JK-Technology.Com
FAQs for
comp.lang.c
http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++
http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html