Re: assignment and coyp constructor
On Dec 14, 8:28 pm, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
samhas wrote:
I have the following class definition:
class test2{
public:
int y;
test2(int ui) : y(ui){}
test2(const test2& t) : y(5){}
test2& operator= (const test2& t){ y = 6; return *this; }
};
In an expression like
test2 t2(test2(20)); or
test2(t2) = test2(20);
neither the copy-constructor nor the assgnment operator get executed.
t2 end up with y=20.
But in the following case the copy constructor gets called:
test2 t = test2(20);
test2 t2(t); // or test2 t2 = t;
Can someone explain to me what's going on there?
Most likely optimisation of some kind. The compiler is allowed to
create code that would omit the use of the copy-constructor (and to
construct the object directly) in certain cases, even if the copy c-tor
has side effects. The fact that the copy c-tor actually is supposed to
produce a different object than what you end up having, looks like a bug
to me. However, whose bug it is is rather debatable. When you write=
a
copy constructor and instead creating a unique element that has really
nothing in common with the object of which it's supposed to be a copy,
then it could be construed as *your* bug, and you're just reaping what
you've sown.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
My example code above was not supposed to be "useful". I had some
problems with statements of that kind in some more complex
environment. So I constructed these examples to see what method was
called... In my opinion statements should have a well defined behavior
regardless of whether the code is useful or not. And I would like to
understand why that code behaves in this way.