Re: Copy constructor doesn't get called when initialized by function
returning object of same class
On Jun 14, 8:20 pm, Daniel Pitts
<newsgroup.spamfil...@virtualinfinity.net> wrote:
James Kanze wrote:
On Jun 13, 4:11 am, Francis Litterio <em...@not.available> wrote:
Roland Pibinger wrote:
On Thu, 12 Jun 2008 11:47:10 -0700 (PDT), abhash wrote:
Thanks Ian for pointing to RVO term. Found quite a lucid explanation
for it here:
http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=199=
RVO is a bug in the C++ language. Your copy constructor
could contain thousands of lines of code (code with side
effects) which may be blissfully elided by a compiler in the
mood.
But since those "thousands of lines of code" should do nothing
but than copy the internal state of the object, the object
created by RVO should have state identical to what its state
would be if your copy constructor had been invoked.
But that's not a requirement.
Its not an enforced requirement, but neither is proper
synchronization in multi-threaded applications. You'll just be
sorry if you don't follow it, but the compiler will let you do
whatever you want. Point gun at foot and pull trigger.
There's a difference. The lack of proper synchronization in
multi-threaded applications is undefined behavior. A copy
constructor which doesn't copy, or does more than just copy, is
more a style issue; it will confuse the maintenance programmers
to no end, but hey, that's their problem, not yours:-). There's
also the fact that "proper synchronization" is rigorously
defined, where as what exactly it means to copy may depend on
the application. (I have at least one case where a copy
constructor does modify the logical internal state of the copied
object.)
There's one other major difference, too: lack of proper
synchronization is more or less existing practice (which is one
reason why so many programs crash all the time), where as a copy
constructor which doesn't copy is really rare (in my experience,
and supposing the appropiate definition of "copy").
Hence, the "O" (Optimization) in RVO.
The word "bug" isn't correct, because it is an intentional
compromise. RVO definitly violates the basic C++ object
model. On the other hand, it can make a significant
difference in performance with most compilers, AND it
shouldn't make a significant difference in the behavior of a
well designed and written program.
I'm not sure how to respond to this, I haven't been into the
depths of C++ development long enough to have an opinion on
"basic C++ object model", and "the behavior of a well designed
and written program". I think I agree with your second point,
but I'm not sure that the basic C++ object model is that well
defined.
It's very rigorously defined, the copy constructor is a
constructor, and while it can be provided by the compiler, it
has no other particular privileges nor, as far as the language
itself is concerned, responsibilities.
It does make me wonder if RVO has ever interacted poorly with
RAII though. Not sure they ever really meet, but if they did,
I could see anguish and surprise :-)
Most of the time, of course, RAII classes don't support copy.
But there are exceptions, some of which (e.g. boost::shared_ptr)
are widely used. The standards committee very definitely
considered these, and if RVO does cause problems with them, it
should be considered a bug in the standard. (I think the way
RVO was originally specified did cause problems in some cases.
And the specification was modified so that it wouldn't.)
--
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