In article <3d0p8m$eha@mozo.cc.purdue.edu> davisonj@en.ecn.purdue.edu (John M Davison) writes:
>
>        In short, side effects occur in even the simplest of useful copy
>constructors, ard this leads to gross inefficiency at return time.  Any
>higher-level attempt to try and determine whether the side effects (and, lest
>there be no doubt, memory management _is_ a side effect) are optimizable or not
>constitute unwarranted chumminess with the programmer, and I want no part of
>it.

 I'm not sure I understand. The compiler can elide
public copy constructors whenever a temporary was created.
If you design your copy constructors to have side effects which
render such elision a problem, your design is flawed _by definition_.
--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

        I wrote:

>A simple String or Vector object, for example, is typically going to have some
>memory management code in its constructor and destructor.  The existence of
>this code produces side effects which will prevent, for example, the copy
>constructor invocation in a "return" statement from being optimized out.
>Thus, unless the programmer throws in some hacks to detect simple copies in
>run time and make both of the objects point to the same data, thus avoiding
>the bulk of the copy operation, lots of unnecessary copies must take place.

        In article <JASON.94Dec13120108@phydeaux.cygnus.com> jason@cygnus.com
(Jason Merrill) writes:

>I think that a compiler could probably get away with not considering memory
>management to be a side effect.

        It's more than memory management, though: it's all the processing that
is associated with a non-default copy constructor.  Aside from the most trivial
of copy constructors, no compiler is, or can be, smart enough to know whether
the operations performed in a copy constructor with side effects (including the
memory management that one would perform with, say, a Vector or String class)
are innocuous enough to _not_ be considered "side effects" (and thus be
optimized out).

        In short, side effects occur in even the simplest of useful copy
constructors, ard this leads to gross inefficiency at return time.  Any
higher-level attempt to try and determine whether the side effects (and, lest
there be no doubt, memory management _is_ a side effect) are optimizable or not
constitute unwarranted chumminess with the programmer, and I want no part of
it.
--
John Davison
Electronic Mail: davisonj@ecn.purdue.edu
WWW Home Page: <http://en.ecn.purdue.edu:20002/~davisonj/HomePage.html>