Re: The C++ standard's rule for selecting a constructor
Vladimir Grigoriev wrote:
"Igor Tandetnik" <itandetnik@mvps.org> wrote in message
news:Of7T9z7nIHA.3804@TK2MSFTNGP02.phx.gbl...
The compiler may choose to elide the copy constructor no matter what it's
doing (in fact, without even knowing what it's doing, since its
implementation may be in a different source file).
It is awful is not it?
I think not...
So the statements is not equivalent
B b1( a );
B b2 = b1;
and
B b2 = B( a );
I think it is a big gap in the standard which in essence is a source of
hard found errors.
This isn't as bad as it sounds. Consider this code:
Object function() {
Object local;
..
return local;
}
Object other = function();
The point is that in this code already it is not specified how often you
actually copy an object. It is create once inside 'function()', then, while
returning it from the function, it might be copied and then during
initialisation of 'other' it might be copied again. OTOH, a smart compiler
can figure out that there is no need for more than one object at a time and
condense all the three objects into the same one, eliding two calls to the
copy constructor.
Now, if your copy constructor actually does anything but copying, I would
personally say that your code is obfuscated and that you should rather fix
your code.
According to the logic we have that
T x = value;
T y = x;
and
T z = value;
will give the result of z != y.
Hmmm, what do you need 'z' for? Shouldn't already be 'x!=y'? In any case, it
is the logic of the class 'T' that is flawed IMHO. A value should not care
what it is initialised from, it should only care for its value.
Just wondering, but what is the actual case that prompted you to start this
thread? Is this merely interest or do you have an actual case that breaks
due to the compiler eliding calls to the copy constructor?
Uli
--
C++ FAQ: http://parashift.com/c++-faq-lite
Sator Laser GmbH
Gesch??ftsf??hrer: Michael W??hrmann, Amtsgericht Hamburg HR B62 932