Re: operator = overloading...
On Dec 20, 4:31 pm, siddhu <siddharth....@gmail.com> wrote:
On Dec 20, 5:53 am, Kira Yamato <kira...@earthlink.net> wrote:
[...]
Can a temporary object be an lvalue? The following code compiles fine
under g++ 4.0.1:
int main()
{
class T {};
T() = T();
return 0;
}
For user defined types temporaries can be lvalue.
No. For class types, an rvalue is an object: it has an address,
and a cv-qualified type. (For non-class types, an rvalue does
not have an address, and the type is always non cv-qualified.
Although if it results in a temporary, trying to modify it is
undefined behavior, even if it isn't const.)
FWIW: at various times, different experts have suggested that
functions or operators returning class types should declare them
const, e.g.:
MyClass const operator+( MyClass const& lhs,
MyClass const& rhs ) ;
This would prevent calling non-const functions on them, e.g.
(a + b) = x ;
would be illegal, because operator= is a non-const function.
This recommendation doesn't seem to have caught on, however,
perhaps because there's no way to make it cover the case in your
example---there is no way to explicitly create a const
temporary.
But its useless. So whenever you return by value ,try to
return it as const value in order to make it consistent with
POD types.
It's still not really consistent, since class type rvalues do
have different behavior than non-class type rvalues. It's just
less inconsistent (and abouty the best you can do).
As I said, you're not the first to recommend this. (I think
Scott Meyers recommends it as well.) But it doesn't seem to be
happening.
I have a question.
obj = obj1 = obj2;
In the above statement what is the order of calling of
assignment operators? I think standard does not specify any
order. please clarify.
The standard specifies a binding: obj is assigned the results of
the expression (obj1 = obj2). In the case of user defined types
(where the operator= is a function, and introduces sequence
points), this imposes an actual order. In the case of the
built-in operator=, however, the order in which obj and obj1 are
modified is not specified (although the value assigned to obj
must be the value that is assigned to obj1, and not the original
value of obj2). There is, of course, no way you could tell in a
standard conforming program, but if you look at the generated
code, or place watch points in a debugger, you could. (The
order could also, in theory, be observable in a multithreaded
environment. But in all the multithreaded environments I know,
if you haven't serialized all accesses to obj and obj1 by some
external locking mechanism, then the program has undefined
behavior anyway.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34