which on is correct?~about temp object~

[cfchou]

hi, all,
i'm reading ch.20 -smart pointers- of [C++ Template].
and i'm tring the trule.hpp test. but there's something different
than i expect, and i found that's about temp object. so i simplified
the question into the following code:

===code starts===
#include <iostream>
using namespace std;

class H
{
public:
H(int i){ cout << "h" << endl; }
};

class T
{
public:
T(int i){ cout << "t" << endl; }
T(H& h){ cout << "ht" << endl; }
T(T const & rhs){ cout << "tt" << endl; }
};

T foo()
{
int i = 10;
return i;
}

T bar()
{
H h(11);
return h;
}

int main()
{
T t1(foo());
T t2(bar());
return 0;
}
===code ends===

on my win2k box, i both use bcb and devc++ to test it:
===bcb output===
t
tt
h
ht
tt
===devc++ output===
t
h
ht
=============

well, i though bcb was right, cause both foo() and bar() generate
temp obj, and which should be use to copy contruct the return T.

anyway, i want to know which is correct, i mean, std compliant.
if it's not bcb, why?

thanks.

[Alf P. Steinbach]

* Rob Williscroft:

Alf P. Steinbach wrote in news:42******** ********@news.i ndividual.net in
comp.lang.c++:

* Old Wolf:

How about:

void foo(SomeClass const &);

int main()
{
SomeClass a;
SomeClass b(a);
foo(b);
}

Can that copy-constructor and side-effect be elided because
the compiler determines that 'a' is never used again, and
it decides to simply use 'b' and 'a' to both refer to the same
bit of memory?

6. The possibility of ignoring side-effects in copy constructors is
mentioned twice in e.g. §12.8/15, about eliding temporaries for
initialization and function results,

The keyword there is "temporarie s", in the above neither "a" nor "b"
is a temporary so the copy-construction of "b" can't be elided, except
under the as-if rule, which can't happen if the copy-constructor (or
destructor, as you point out in the bit I snipped) has side effects.

Well, first, contrary to what your quoting indicates, is was the as-if rule
I primarily referred to.

However, you're right, but possibly for the wrong reasons?, that I drew an
incorrect conclusion.

The question Old Wolf posed turns out to be answered directly by the
standard:

§3.7.2/3: "If a named automatic object has initialization or a destructor
with side effects, it shall not be destroyed before the end of its block,
nor shall it be eliminated as an optimization even if it appears to be
unused, except that a class object or its copy may be eliminated as
specified in 12.8".

So, there's the definitive formal answer, but I don't think it's wise to
rely on that behavior in an actual compiler (especially considering 12.8).

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Rob Williscroft]

Alf P. Steinbach wrote in news:42******** ********@news.i ndividual.net in
comp.lang.c++:

> 6. The possibility of ignoring side-effects in copy constructors is
> mentioned twice in e.g. õ12.8/15, about eliding temporaries for
> initialization and function results,
The keyword there is "temporarie s", in the above neither "a" nor "b"
is a temporary so the copy-construction of "b" can't be elided,
except under the as-if rule, which can't happen if the
copy-constructor (or destructor, as you point out in the bit I
snipped) has side effects.

Well, first, contrary to what your quoting indicates, is was the as-if
rule I primarily referred to.

However, you're right, but possibly for the wrong reasons?, that I
drew an incorrect conclusion.

I think both my highlighting of temporaries and your quote below are
needed for the picture to be complete.
The question Old Wolf posed turns out to be answered directly by the
standard:

õ3.7.2/3: "If a named automatic object has initialization or a
destructor with side effects, it shall not be destroyed before the end
of its block, nor shall it be eliminated as an optimization even if it
appears to be unused, except that a class object or its copy may be
eliminated as specified in 12.8".

So, there's the definitive formal answer, but I don't think it's wise
to rely on that behavior in an actual compiler (especially considering
12.8).

12.8/15 specifcaly mentions only 2 cases, first case creating the return
value of a function and the second case when a temporary is copied.

In the first case an rvalue (a form of temporary) is the destination
of the copy and in the second a temporary is the source of the copy.

In Old Wolf's example, both the source and destination of the copy
were named locals (in the same scope), so 12.8/15 can't apply.

Rob.
--
http://www.victim-prime.dsl.pipex.com/