Re: reference lifetimes...
On Nov 11, 1:58 pm, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
James wrote:
"Victor Bazarov" <v.Abaza...@comAcast.net> wrote in message
news:hdee11$3ui$1@news.datemas.de...
James wrote:
[...]
Why does the const reference not properly maintain its lifetime over
the call to 'cout' when the reference is contained within a POD
'foo_holder'? I get the following output:
0x22ff50->foo::foo()
0x22ff50->foo::~foo()
okay
0x22ff50->foo::foo()
okay
0x22ff50->foo::~foo()
Something seems terribly wrong here... Is there anyway to
overcome this?
The form
T t = { blah };
is copy-initialisation. The compiler is free to create
another temporary (of your class 'foo_holder') before
initializing 'fh' with it, which makes the temporary's
'm_ref' member bound to the temporary 'foo'. The
'foo_holder' temporary is destroyed after initialising of
the 'fh' variable, causing the destruction of your foo'
temporary.
The references when initialised with the above form are
treated differently. A possible copy of the object is
created and the reference is then bound to it. That
temporary (either another one or the original one) survives
as long as the reference.
Also, I don't think this has anything to do with PODs.
I am a bit confused. So, are you saying that the output:
0x22ff50->foo::foo()
0x22ff50->foo::~foo()
okay
0x22ff50->foo::foo()
okay
0x22ff50->foo::~foo()
OR
0x22ff50->foo::foo()
okay
0x22ff50->foo::~foo()
0x22ff50->foo::foo()
okay
0x22ff50->foo::~foo()
is perfectly fine because of undefined behavior? James Kanze
threw me off when he said it could be compiler bug.
I think it is a compiler bug. At least, I can't see any way of
reading the standard otherwise. (Victor is, I think, confusing
two separate issues.)
Yep. Essentially it's the same as
class foo { ... }; // just like yours
class HasARef {
const foo& m_ref;
public:
HasARef(const foo& r) : m_ref(r) {}
};
#include <iostream>
int main() {
HasARef h(( foo() )); // need double parens
std::cout << "okay\n";
}
Not at all. There's no aggregate initialization involved there.
Note that as he'd written it,
foo_holder h( (foo()) );
will not compile. You cannot construct a foo_holder from a foo
(temporary or not). You can't default construct it, because it
contains a reference. All you can do is copy construct it
(which wouldn't prolongue the lifetime of the temporary), and
aggregate initialize it, in which case, you actually initialize
each of its members---and initializing a reference directly with
a temporary extends the lifetime of that temporary.
What happens here is the reference 'm_ref' is *not* bound
directly to the temporary, but instead goes through a
"copying" process - the argument to the constructor.
Here, yes. But not in his example. Aggregate initialization is
not the same as a constructor.
*The argument* is bound to the temporary. The 'm_ref' member
isn't because there is no direct initialisation of it with the
expression that yields the temporary.
It's not a compiler bug, AFAICT.
You'll have to cite something from the standard to back that up.
In =A78.5.1, the sandard says that the brace-enclosed
comma-separated list is a list of initializer-clauses for the
members of the aggregate; that certainly sounds like each member
is initialized with the expression. (This may have changed in
C++0x, since there's been a significant effort in unifying the
initializer syntax and semantics.)
--
James Kanze