Skip to main content
gamedev.net
🔒 Locked

Class Deconstructor

Started by Mat1515 Mar 7, 2004 at 11:59 AM 17 replies 1.9k views
Original Post
Mat1515
Mat1515
When a prpgram is terminated and or closed are the classes deconstructors automaticly called?
Ut o not me again:) lol
Oxyd
Oxyd
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
antareus
antareus
...only if they''ve gone out of scope. If you allocated them with the new operator, then you must delete them somewhere before the end of the program.
--God has paid us the intolerable compliment of loving us, in the deepest, most tragic, most inexorable sense.- C.S. Lewis
Henners
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.

Btw, it''s really annoying and I want a better compiler
---------------------------------Use Firefox, you'll never ever look back.
Ratterbox
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.



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

amag
amag
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]
paulecoyote
paulecoyote
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.
Anything posted is personal opinion which does not in anyway reflect or represent my employer. Any code and opinion is expressed “as is” and used at your own risk – it does not constitute a legal relationship of any kind.
Enokh
Enokh
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.
Fruny
Fruny
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]
"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
Fruny
Fruny
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)
"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
Henners
Henners
Hey, I know this is a little late, but this is the code I was using when the deconstructor didn't appear to work:


#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]
---------------------------------Use Firefox, you'll never ever look back.
aldisd
aldisd
I have 1 global object, the main game app itself. Its destructor gets called just fine when I quit. And no I''m not using new/delete, it''s static.
Agony
Agony
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); }
"We should have a great fewer disputes in the world if words were taken for what they are, the signs of our ideas nly, and not for things themselves." - John Locke o
Henners
Henners
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?
---------------------------------Use Firefox, you'll never ever look back.
amag
amag
Actually, what happens is that the std::cout-object is destroyed *before* your object. If you use printf() you''ll see it works.
Newfound Ajarn
Newfound Ajarn
quote:
Original post by downgraded
Don''t use global objects!


Don''t use VC++ 6!

VLAjarn: Cause it (linux) NEVER crashesMrPr0Grmer: lol ur wrongMrPr0Grmer: RedHat crashesVLAjarn: I'm saying good builds of linux
Agony
Agony
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); }
"We should have a great fewer disputes in the world if words were taken for what they are, the signs of our ideas nly, and not for things themselves." - John Locke o
Agony
Agony
quote:
Original post by amag
Actually, what happens is that the std::cout-object is destroyed *before* your object.

Doh! I should have known that. Silly me.




int main() { return *((int*)0); }
"We should have a great fewer disputes in the world if words were taken for what they are, the signs of our ideas nly, and not for things themselves." - John Locke o

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.