Is it an undefined behavior in C++ Standard?

[aka]

// classA.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"

#include <iostream>

using namespace std;

static unsigned int count = 0;

class A
{
public:
A() {
p = this;
}

~A() {
if (p) {
cout << count++ << endl;
delete p;
p = 0;
}
}

private:
A *p;
};

int _tmain(int argc, _TCHAR* argv[])
{
A a;

return 0;
}

/* compiler: MSC++ compiler in visual c++ 2005 express edition beta
command: cl /nologo /EHsc classA.cpp
*/

/* result:
0
1
2
...
23485
press any key to continue
*/

/*
question: Is it an undefined behavior in C++ Standard?

details: p is a point of class A, when destructor call 'delete p',it will
cause destructor again.
Is there any limit calling destructor recursively?
*/ÿÿÿ

 

[Peter Koch Larsen]

// classA.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"

#include <iostream>

using namespace std;

static unsigned int count = 0;

class A
{
public:
A() {
p = this;
}

~A() {
if (p) {
cout << count++ << endl;
delete p;
p = 0;
}
}

private:
A *p;
};

int _tmain(int argc, _TCHAR* argv[])
{
A a;

return 0;
}

/* compiler: MSC++ compiler in visual c++ 2005 express edition beta
command: cl /nologo /EHsc classA.cpp
*/

/* result:
0
1
2
...
23485
press any key to continue
*/

/*
question: Is it an undefined behavior in C++ Standard?

What is? What you do is calling the destructor of an object more than once
and that causes undefined behaviour.

details: p is a point of class A, when destructor call 'delete p',it will
cause destructor again.
Is there any limit calling destructor recursively?

No. You can do as long as you please. Almost! Your program
Not in your program - it has endless recursion.

Also I fail to sees what youre attempting to do.


/Peter

 

[Ioannis Vranos]

// classA.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"

#include <iostream>

using namespace std;

static unsigned int count = 0;

class A
{
public:
A() {
p = this;
Why?



}

~A() {
if (p) {
cout << count++ << endl;
delete p;
p = 0;
}
}

private:
A *p;
};

int _tmain(int argc, _TCHAR* argv[])
{
A a;

return 0;
}

/* compiler: MSC++ compiler in visual c++ 2005 express edition beta
command: cl /nologo /EHsc classA.cpp
*/

/* result:
0
1
2
...
23485
press any key to continue
*/

/*
question: Is it an undefined behavior in C++ Standard?

Yes.



details: p is a point of class A, when destructor call 'delete p',it will
cause destructor again.
Is there any limit calling destructor recursively?

As long as it can.

 

[Rolf Magnus]

// classA.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"

#include <iostream>

using namespace std;

static unsigned int count = 0;

class A
{
public:
A() {
p = this;

You store a pointer to the object itself as member? What would that be good
for?

}

~A() {
if (p) {

p is never 0 unless there is an error in your program.

cout << count++ << endl;
delete p;

This would recursively call the destructor. This is not allowed. For each
object, a constructor as well as the destructor gets called exactly once.
Another problem is that you must never use delete on an object that you
didn't get from new. So this isn't valid for any non-dynamically allocated
objects.

p = 0;
}
}

private:
A *p;
};

int _tmain(int argc, _TCHAR* argv[])
{
A a;

return 0;
}

/* compiler: MSC++ compiler in visual c++ 2005 express edition beta
command: cl /nologo /EHsc classA.cpp
*/

/* result:
0
1
2
...
23485
press any key to continue
*/

/*
question: Is it an undefined behavior in C++ Standard?
Yes.

details: p is a point of class A, when destructor call 'delete p',it will
cause destructor again.

For what reason? What are you trying to accomplish?

Is there any limit calling destructor recursively?

Yes. It must _never_ be called recursively. Also, your 'delete p' doesn't
just call the destructor, it also tries to free the memory that the object
occupied, which only works if the object is allocated dynamically.
Actually, I'm surprised that your program doesn't crash.

 

[BigBrian]

Is this an undefined behavior in C++ Standard?

Yes, it's undefined behavior to delete a pointer that wasn't created
with new.

You shouldn't "call" a destructor, and you shouldn't delete a pointer
that wasn't newed in order for the destructor to be called. The
destructor for an object should only be called one, if it's called
twice it's undefined behavior.

 

[aka]

I'm learning Visual C++ 2005. I want to know how it implement ISO C++
standard, such as undefined behavior.

// classA.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"

#include <iostream>

using namespace std;

static unsigned int count = 0;

class A
{
public:
A() {
p = this;
}

~A() {
if (p) {
cout << count++ << endl;
delete p;
p = 0;
}
}

private:
A *p;
};

int _tmain(int argc, _TCHAR* argv[])
{
A a;

return 0;
}

/* compiler: MSC++ compiler in visual c++ 2005 express edition beta
command: cl /nologo /EHsc classA.cpp
*/

/* result:
0
1
2
...
23485
press any key to continue
*/

/*
question: Is it an undefined behavior in C++ Standard?

What is? What you do is calling the destructor of an object more than once
and that causes undefined behaviour.

details: p is a point of class A, when destructor call 'delete p',it will
cause destructor again.
Is there any limit calling destructor recursively?

No. You can do as long as you please. Almost! Your program
Not in your program - it has endless recursion.

Also I fail to sees what youre attempting to do.


/Peter

*/ÿÿÿ

 

[Victor Bazarov]

I'm learning Visual C++ 2005. I want to know how it implement ISO C++
standard, such as undefined behavior. [...]

Implement it as you see fit or as you grandma explained to your grandpa.
It does not matter. It is explicitly undefined and that means nothing
is prescribed and nothing _specific_ is expected.

 

[aka]

sorry for my poor english, but i wonder what do you mean '...or as you
grandma explained to your grandpa'.

I think a compiler must deal with these undefined behaviors, i just want to
know.

I'm learning Visual C++ 2005. I want to know how it implement ISO C++
standard, such as undefined behavior. [...]

Implement it as you see fit or as you grandma explained to your grandpa.
It does not matter. It is explicitly undefined and that means nothing
is prescribed and nothing _specific_ is expected.

 

[Victor Bazarov]

sorry for my poor english, but i wonder what do you mean '...or as you
grandma explained to your grandpa'.

I think a compiler must deal with these undefined behaviors, i just want to
know.

How would I put this... No, it does not have to deal with them. There
are no requirements imposed on the compiler or the program it produces.
Whatever they do is OK (from the C++ point of view).

To further complicate the issue: yes, the compiler can throw a shoe (die
or dump core or cause hardware malfunction) or create the code that sends
obscene e-mails to your colleagues. Of course, you are unlikely to see
any of this. While it's allowed, nobody in their right mind would put
such behaviour into their product. Well, they might, only once. After
that it wouldn't be much of a product any more, in a market sense.

If you really want to know the details of Visual C++ implementation, you
have to ask in a newsgroup dedicated to it. But it is still pointless.
Nobody will explain exactly how they implement something that has not been
defined in any way. Perhaps you just have to look the word "undefined" in
the dictionary to understand...

And don't top-post, please. Thank you.

I'm learning Visual C++ 2005. I want to know how it implement ISO C++
standard, such as undefined behavior. [...]

Implement it as you see fit or as you grandma explained to your grandpa.
It does not matter. It is explicitly undefined and that means nothing
is prescribed and nothing _specific_ is expected.

V

 

[Rolf Magnus]

sorry for my poor english, but i wonder what do you mean '...or as you
grandma explained to your grandpa'.

I think a compiler must deal with these undefined behaviors, i just want
to know.

No. That's the whole point. The compiler doesn't have to deal with it.
Anything that the compiler might do or not do is ok. It doesn't need to do
anything specific, it can just let things happen.

 

[aka]

Thank you!