Re: Dangling Reference

From: Ron Natalie (ron_at_sensor.com)
Date: 10/27/03 

Date: Mon, 27 Oct 2003 12:45:09 -0500

"kaede" <kaedeRukawa_jp@hotmail.com> wrote in message news:60a3ffc9.0310270932.7c6cfc3b@posting.google.com...

>
> When re-running scenerio A - C, the contents of data seems to be
> dumping out
> correctly. I am not sure why?
>
Because one of the insidious features of undefined behavior is that things
might appear to work normally (only to fail later).

In Scenario A, you have it right. The temporary ceases to be as soon
as the constructor finishes.

In Scenario B, you have undefined behavior. What happens if you
change the member of data after holder is constructed but before
you print? I suspect either that you are benefiting from the eliding
of the temporary or somehow the reference ends up seated at the
variable in main. In either case it's just a conincidence.

Scenario C, you don't have undefined behavior. There is no temporary.
The reference in holder refers to the variable data in main. It lives longer
than holder does in fact.

In Scenario D, you just get more coincidental behavior, but you've changed
the data object's size so that it's really small and may end up being parked
in a register.

Relevant Pages

  • Re: Dangling Reference
    ... > Because one of the insidious features of undefined behavior is that things ... > In Scenario B, you have undefined behavior. ... > The reference in holder refers to the variable data in main. ...
    (comp.lang.cpp)
  • Re: Dangling Reference
    ... > Because one of the insidious features of undefined behavior is that things ... > In Scenario B, you have undefined behavior. ... > The reference in holder refers to the variable data in main. ... Also, I read something about when temporary binds to const&, the ...
    (comp.lang.cpp)
  • Re: Threads on class,
    ... >> or not whatever he's talking about is a likely scenario or not... ... compiler actually goes to great pains to make this undefined behavior "work" ... that never leaves VC++ it may be a safe hack since the VC++ team is very ... good about maintaining backwards compatibility at the code generation ...
    (microsoft.public.windowsce.embedded.vc)
  • Re: Threads on class,
    ... >> or not whatever he's talking about is a likely scenario or not... ... compiler actually goes to great pains to make this undefined behavior "work" ... that never leaves VC++ it may be a safe hack since the VC++ team is very ... good about maintaining backwards compatibility at the code generation ...
    (microsoft.public.vc.language)