why is this still working??

[Hans Van den Eynden]

This is my code:

int& dangling_reference();

int main(int argc, char *argv[])
{
Integer *a = new Integer(4);
Integer *b;
b=a;
delete a;

//dangling reference 1
cout<<"a: "<<a->integer<<"b: "<<b->integer<<endl;

// dangling reference 2
int x=dangling_reference();
cout<<"int x: "<<x;

cin.get();
}

int& dangling_reference() {
int x=3;
return x;
}

Why don't I get an error and why are the values of a->integer en x correct??
It's this a dangling reference fault??

bizar i think

[Nils O. Selåsdal]

On Wed, 20 Oct 2004 10:47:21 -0700, Hans Van den Eynden wrote:

This is my code:

int& dangling_reference(); Why don't I get an error and why are the values of a->integer en x correct??
It's this a dangling reference fault??

Most likely cause nothing messes with the location on the stack where
x is stored.

[Victor Bazarov]

Hans Van den Eynden wrote:

This is my code:

int& dangling_reference();

int main(int argc, char *argv[])
{
Integer *a = new Integer(4);
WTF is 'Integer'?
Integer *b;
b=a;
delete a;

//dangling reference 1
cout<<"a: "<<a->integer<<"b: "<<b->integer<<endl;
That's not a dangling reference. That's accessing members of
an object whose lifetime has ended. Undefined behaviour occurs.

// dangling reference 2
int x=dangling_reference();
cout<<"int x: "<<x;

cin.get();
}

int& dangling_reference() {
int x=3;
return x;
}

Why don't I get an error and why are the values of a->integer en x correct??
What error would you like to get? The behaviour is undefined. Your
implementation may (has all rights to) create the code that will give
you some kind of error. Or it may (has all rights to) create the code
that will format the hard drive of your computer. The Standard makes
no requirement here.
It's this a dangling reference fault??

No, it's your fault. You wrote the code that has undefined behaviour.

V

[Ron Natalie]

Hans Van den Eynden wrote:

Why don't I get an error and why are the values of a->integer en x correct??
It's this a dangling reference fault??

There's no such thing as a "dangling reference fault." Both cases are
undefined behavior. There is no requirement that the compiler detect
or otherwise have any specific behavior when you break the rules like
that.

[Andre Kostur]

on******@hotmail.com (Hans Van den Eynden) wrote in
news:1c**************************@posting.google.c om:

This is my code:
[snip standard example of returning a reference to a local variable]
Why don't I get an error and why are the values of a->integer en x
correct?? It's this a dangling reference fault??

This invokes what's called "Undefined Behaviour". The compiler/computer is
free to do whatever it wishes, including continuing to run as if there is
no problem (or alternately, make the appropriate calls to your video card
to attempt to drive your monitor at 2.4 GHz horizontal refresh rate,
causing your monitor to explode).

[Heinz Ozwirk]

"Hans Van den Eynden" <on******@hotmail.com> schrieb im Newsbeitrag news:1c**************************@posting.google.c om...

This is my code:

int& dangling_reference();

int main(int argc, char *argv[])
{
Integer *a = new Integer(4);
Integer *b;
b=a;
delete a;

//dangling reference 1
cout<<"a: "<<a->integer<<"b: "<<b->integer<<endl;

// dangling reference 2
int x=dangling_reference();
cout<<"int x: "<<x;

cin.get();
}

int& dangling_reference() {
int x=3;
return x;
}

Why don't I get an error and why are the values of a->integer en x correct??
It's this a dangling reference fault??

bizar i think

Not bizar - just undefined.

Heinz

[JKop]

int& dangling_reference();

int main(int argc, char *argv[])
{
Integer *a = new Integer(4);
Integer *b;
b=a;
delete a;

//dangling reference 1
cout<<"a: "<<a->integer<<"b: "<<b->integer<<endl;

Just for clarity: Both the pointers "a" and "b" point to an object which no
longer exists.

Undefined Behaviour.


// dangling reference 2
int x=dangling_reference();
cout<<"int x: "<<x;

Here your copy constructing an object of type "int" from an object which no
longer exists.

Undefined Behaviour.


cin.get();
}

int& dangling_reference() {
int x=3;
return x;
}

Why don't I get an error and why are the values of a->integer en x
correct?? It's this a dangling reference fault??

Your program is not ill-formed, though it does produce undefined behaviour.

If you were to run it on WinXP, you'd probably get a runtime error for
accessing memory that isn't yours.
-JKop

[Catalin Pitis]

"JKop" <NU**@NULL.NULL> wrote in message
news:tH*******************@news.indigo.ie...

int& dangling_reference();

int main(int argc, char *argv[])
{
Integer *a = new Integer(4);
Integer *b;
b=a;
delete a;

//dangling reference 1
cout<<"a: "<<a->integer<<"b: "<<b->integer<<endl;

Just for clarity: Both the pointers "a" and "b" point to an object which
no
longer exists.

Undefined Behaviour.

// dangling reference 2
int x=dangling_reference();
cout<<"int x: "<<x;

Here your copy constructing an object of type "int" from an object which
no
longer exists.

Undefined Behaviour.

cin.get();
}

int& dangling_reference() {
int x=3;
return x;
}

Why don't I get an error and why are the values of a->integer en x
correct?? It's this a dangling reference fault??

Your program is not ill-formed, though it does produce undefined
behaviour.

If you were to run it on WinXP, you'd probably get a runtime error for
accessing memory that isn't yours.

Actually, in WinXP you will get undefined behavior, too. If you're (still)
lucky, it might work. The deallocated memory is still reserved by the
process (and might still contain the object state before delete, if it
wasn't overwritten by other allocations).

Br/
Catalin

[Karl Heinz Buchegger]

Catalin Pitis wrote:

Actually, in WinXP you will get undefined behavior, too. If you're (still)
lucky, it might work.

Other way round:
If you are lucky, it crashes immediatly.
If it appears wo work, you were unlucky. Unlucky in the sense
that it seems to work in your test environment, while it immediatly
crashes when your customer tries the program the first time leading
him to believe you made a bad job (which you did) and thus he refuses
to pay your bill.

--
Karl Heinz Buchegger
kb******@gascad.at

[Catalin Pitis]

"Karl Heinz Buchegger" <kb******@gascad.at> wrote in message
news:41***************@gascad.at...

Catalin Pitis wrote:

Actually, in WinXP you will get undefined behavior, too. If you're
(still)
lucky, it might work.

Other way round:
If you are lucky, it crashes immediatly.
If it appears wo work, you were unlucky. Unlucky in the sense
that it seems to work in your test environment, while it immediatly
crashes when your customer tries the program the first time leading
him to believe you made a bad job (which you did) and thus he refuses
to pay your bill.

You're right. I was too optimistic :).
Sorry for that :)

[JKop]

You're right. I was too optimistic :).
Sorry for that :)

That's the compiler's job!
-JKop