🔒 Locked
Class Deconstructor
Advertisement
Original Post
Yes. The only exception is when the program is destroyed using abort () call. Then it doesn''t call anything and crashes very quickly (which is what you want).
Oxyd
---
- Unreadable code is code written on a piece of paper, but not the one, in which the programmer is using a space in the place you don''t.
- Real programmers aren''t afraid of goto
Oxyd
---
- Unreadable code is code written on a piece of paper, but not the one, in which the programmer is using a space in the place you don''t.
- Real programmers aren''t afraid of goto
Don''t use global objects!
quote:
Original post by Henners
Also, with my compiler (VC++ 6) a global object''s destructor is not called ever. Only if it is in a local scope somewhere will the destructor be called.
That is strange, I am using Microsoft Visual C++ 6.0, and all of my global objects get their destructors called. I wonder what could be wrong????
Is there anyone who can shed more light on this?
- Ratterbox
quote:
Original post by Henners
Also, with my compiler (VC++ 6) a global object's destructor is not called ever. Only if it is in a local scope somewhere will the destructor be called.
I'd like to know how you check whether your dtor is run or not...
I use VC6 and I find that every implicitly allocated object (not one allocated with new) is destroyed and its dtor is called upon program exit.
[edited by - amag on March 8, 2004 5:55:53 PM]
You cannot accurately predict what order static object instances will construct and destruct.
Not sure if that has anything to do with anything, but there you go.
Not sure if that has anything to do with anything, but there you go.
Something''s wrong on your part man, I''m using the MSVS6 C++ IDE and I haven''t run into any problems. I have a global class called Game, which is declared like you declare "int x" as opposed to being declared dynamically using the new operator, and Game''s deconstructor runs just fine. I placed a breakpoint at the beginning of Game''s deconstructor, and normally exited my game and indeed the deconstructor ran.
quote:
3.7.1 Static storage duration [basic.stc.static]
1 - All objects which neither have dynamic storage duration nor are local have static storage duration . The storage for these objects shall last for the duration of the program (3.6.2, 3.6.3).
3.6.3 Termination [basic.start.term]
1 - Destructors (&2.4) for initialized objects of static storage duration (declared at block scope or at namespace scope) are called as a result of returning from main and as a result of calling exit (18.3). These objects are destroyed in the reverse order of the completion of their constructor or of the completion of their dynamic initialization. If an object is initialized statically, the object is destroyed in the same order as if the object was dynamically initialized. For an object of array or class type, all subobjects of that object are destroyed before any local object with static storage duration initialized during the construction of the subobject is destroyed.
4 - Calling the function void abort(); declared in <cstdlib> terminates the program without executing destructors for objects of automatic or static storage duration and without calling the functions passed to atexit().
“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” — Brian W. Kernighan (C programming language co-inventor)
[edited by - Fruny on March 8, 2004 6:41:16 PM]
quote:
Original post by paulsdsrubbish
You cannot accurately predict what order static object instances will construct and destruct.
Within a single translation unit (single cpp file + everything you #include), objects are initalized in the order in which they are defined. Destructors run in reverse order (see my previous post).
Across multiple translation units, the order of initialization is undefined. That is, you cannot control whether the objects defined in foo.cpp will be constructed before or after those in bar.cpp
“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” — Brian W. Kernighan (C programming language co-inventor)
Hey, I know this is a little late, but this is the code I was using when the deconstructor didn't appear to work:
There is only one 'deleting object' line. I picked up on this from a book called C++ in Action - here is the page where he talks about the issue. (Look at the bottom of the page under 'Troubleshooting Tips' for his specific reference to VC++ 6)
Perhaps I AM doing something wrong, but please, tell me what it is!
Henry
[edited by - Henners on March 10, 2004 1:28:37 PM]
#include <iostream>
using namespace std;
class Object {
public:
Object() { cout << "creating object" << endl; }
~Object() { cout << "deleting object" << endl; }
};
Object myGlobal;
int main()
{
Object myLocal;
return 0;
}
There is only one 'deleting object' line. I picked up on this from a book called C++ in Action - here is the page where he talks about the issue. (Look at the bottom of the page under 'Troubleshooting Tips' for his specific reference to VC++ 6)
Perhaps I AM doing something wrong, but please, tell me what it is!
Henry
[edited by - Henners on March 10, 2004 1:28:37 PM]
Maybe by the time the process gets around to calling your destructor, it is no longer really attached to the console window, because of cleanup code in the executable, and thus the global object''s destructor isn''t really capable of writing to the console window. Try opening a file, writing to it, and closing it in the destructor.
int main() { return *((int*)0); }
int main() { return *((int*)0); }
Thank you Agony,
I opened a file and found the ctor and dtor to work whether global or local scope.
So when Mr. Eckel refers to MSVC++ 6 having a sub-standard library, does he mean that the cleanup code in the executable could be made so that the thread does not detach before all objects are destroyed? I assume this is the responsibility of the library, seeing as how I don''t do it
Finally, an earlier post mentioned that you shouldn''t use global objects. Why is that? If I want to have a global application object like aldisd uses, is that necessarily bad programming practice?
I opened a file and found the ctor and dtor to work whether global or local scope.
So when Mr. Eckel refers to MSVC++ 6 having a sub-standard library, does he mean that the cleanup code in the executable could be made so that the thread does not detach before all objects are destroyed? I assume this is the responsibility of the library, seeing as how I don''t do it
Finally, an earlier post mentioned that you shouldn''t use global objects. Why is that? If I want to have a global application object like aldisd uses, is that necessarily bad programming practice?
quote:
Original post by downgraded
Don''t use global objects!
Don''t use VC++ 6!
In reference to global variables, I''d say this: don''t use a lot of trivial global objects. But a few objects that are a central part of your program can be fine, such as a game object. The problem of global objects is usually that they tend to be used to pass information around all over the place in an ugly fashion that is more likely to cause bugs, but when you just have a few objects, you''re typically not using them for that purpose.
int main() { return *((int*)0); }
int main() { return *((int*)0); }
Topic Locked
This topic has been locked by a moderator. New replies are not allowed.
Sign in to reply to this topic.
Advertisement