Siemel Naran wrote:
>
>
> More importantly, as calls to the copy ctor and dtor may be
> eliminated, it is not wise to rely on side effects in the
> copy ctor or dtor, and it is wise for the copy ctor to make
> identical copies.
>

I don't have a better formulation, but note that a destructor exists
only because it has side effects. The key is to avoid having
non-dependent side effects. If the constructor allocates memory and the
destructor frees it, there's no problem with eliding both.

--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

As we know,  returning an object from a function causes the
copy -constructor  to be called.
E.g.
class Bar()
{
public:
    Bar (const Bar& other_bar) {  /* whatever */ }
    Bar(int  bar_number)   { /* whatever */
}

Bar foo()
{
    return Bar(42);
}

and calling foo() causes both constructors to be called, but conceptually,
the copy constructor is superfluous and the Bar object provided by foo() can
be immediately constructed by Bar::Bar(int)
I cannot think of a reason why the standard does not require that in cases
like this (constructor call in the return statement) the copy-constructor
should not be called. Could you enlighten me?   Thanks
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 25 Nov 98 04:43:20 GMT, levlion <levlion@email.msn.com> wrote:

>As we know,  returning an object from a function causes the
>copy -constructor  to be called.

No.  The return value optimization allows the returned object to
be constructed in place into its final location, thereby saving
some space and eliminating superflous calls to the copy ctor and
dtor.  At present, most compilers don't support this optimization.

Even if a call to the copy ctor and dtor are eliminated, it is
still required that an accessible copy ctor and dtor exist.

More importantly, as calls to the copy ctor and dtor may be
eliminated, it is not wise to rely on side effects in the
copy ctor or dtor, and it is wise for the copy ctor to make
identical copies.


>E.g.
>class Bar()
>{
>public:
>    Bar (const Bar& other_bar) {  /* whatever */ }
>    Bar(int  bar_number)   { /* whatever */
>}
>
>Bar foo()
>{
>    return Bar(42);
>}

In compilers that don't do the return value optimization, the above
should not result in a call to the copy ctor.  The return object
is constructed via Bar::Bar(int) directly in the return space.  On
most compilers, the following will result in a call to the copy
ctor:

Bar foo()
{
     Bar b(42); // construct b using Bar::Bar(int)
     return b; // copy 'b' using Bar::Bar(const Bar&)
}

The return value optimization says that 'b' can be constructed
directly into the return value space.


>and calling foo() causes both constructors to be called, but conceptually,
>the copy constructor is superfluous and the Bar object provided by foo() can
>be immediately constructed by Bar::Bar(int)

>I cannot think of a reason why the standard does not require that in cases
>like this (constructor call in the return statement) the copy-constructor
>should not be called. Could you enlighten me?   Thanks

Strangely, the standard does not require the optimization to be
performed.  But in two or three years, most probably will.  If
you use egcs, check out the named return feature.


--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]