# [C++] Deconstruction order of member variables...

This topic is 3764 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

This is a pretty quick question, which I think I already know the answer to... If a class has a number of member variables, is the order in which they are destroyed defined? [Edited by - fpsgamer on October 29, 2007 4:42:24 PM]

##### Share on other sites
In the opposite order of the completion of their constructors.

##### Share on other sites
Quote:
 Original post by jpetrieIn the opposite order of the completion of their constructors.

Can anything be said about the order of construction?

class FooBar
{
public:
Foo f;
Bar b;
...
};

So in the above example, will f get constructed then b simply because I have declared them in that oder?

##### Share on other sites
In this particular example, yes. This is only the case because they are within the same access specifier.

##### Share on other sites
"order of construction - a class object is constructed from the bottom up: first bases in declaration order, then members in declaration order, and finally the body of the constructor itself. TC++PL 10.4.6, 12.2.2, 15.2.4.1, 15.4.3. D&E 2.11.1, 13.2.4.2."

From:
http://www.research.att.com/~bs/glossary.html#Gorder-of-construction

##### Share on other sites
You can destruct/delete a class member(class)variables in it's destructor, like this:

class SomeClass{...SomeOtherClass *memberClassVar1;SomeOtherClass *memberClassVar2;...   ~SomeClass()   {      delete memberClassVar1;      delete memberClassVar2;   }};

Just an idea i got.

##### Share on other sites
Quote:
 Original post by programeringYou can destruct/delete a class member(class)variables in it's destructor, like this:*** Source Snippet Removed ***Just an idea i got.

Destruction and deletion are 2 different things.

##### Share on other sites
Quote:
 You can destruct/delete a class member(class)variables in it's destructor, like this:

Of course, that's not really what he was asking. Also, that clearly won't be useful unless you allocate every member on the heap. Which is not a good idea. At all.

##### Share on other sites
Quote:
 Original post by ToohrVykIn this particular example, yes. This is only the case because they are within the same access specifier.

Access specifiers don't affect order of initialization of members. This implies that members may be initialized in a different order than their relative order in memory.

##### Share on other sites
Quote:
 Original post by jpetrieIn the opposite order of the completion of their constructors.

Obligatory addition for the virtual inheritance and more convoluted hierarchies.

##### Share on other sites
Quote:
Original post by SiCrane
Quote:
 Original post by ToohrVykIn this particular example, yes. This is only the case because they are within the same access specifier.

Access specifiers don't affect order of initialization of members. This implies that members may be initialized in a different order than their relative order in memory.

So does that mean that the order of declaration within a class does define the order of construction?

Similarly, I assume that the left to right order of an constructor initialization list does strictly define order of construction. Is that right?

I thought I'd throw in this related question too:

At which point are (1) class static and (2) member-function static items deconstructed?

##### Share on other sites
Quote:
Original post by fpsgamer
Quote:
Original post by SiCrane
Quote:
 Original post by ToohrVykIn this particular example, yes. This is only the case because they are within the same access specifier.

Access specifiers don't affect order of initialization of members. This implies that members may be initialized in a different order than their relative order in memory.

So does that mean that the order of declaration within a class does define the order of construction?

Similarly, I assume that the left to right order of an constructor initialization list does strictly define order of construction. Is that right?

I get warnings if I place members in the initialiser list in a different order than they are declared, so I think the order of construction is defined by class declaration, not initialiser list.

##### Share on other sites
Quote:
 Original post by fpsgamerSimilarly, I assume that the left to right order of an constructor initialization list does strictly define order of construction. Is that right?

Initializer list order is not relevant to the order of construction.
Quote:
 At which point are (1) class static and (2) member-function static items deconstructed?

Objects are destroyed in the reverse order of the order in which they are constructed. The order in which namespace-level objects of static storage duration get constructed is the lexicographic order in which they occur in a translation unit. The order in which namespace level objects of static storage duration are constructed in different translation units is undefined.

Objects of static storage duration constructed in a function member body are going to be destroyed before namespace-level objects of static storage duration, but after any variables of automatic storage duration, in the reverse order in which they are constructed.

In short, don't depend on order of construction and destruction of objects of static storage duration. If you do, you're gonna get hosed sdomewhere, most likely just after you ship.

--smw

##### Share on other sites
Yes, the ordering in the initialization list has no bearing on the actual initialization order. Some compilers warn you if you write the list out-of-order, because it can be easy place the object in a bad state like that.

##### Share on other sites
Quote:
Original post by rip-off
Quote:
 Original post by programeringYou can destruct/delete a class member(class)variables in it's destructor, like this:*** Source Snippet Removed ***Just an idea i got.

Destruction and deletion are 2 different things.

I didn't know that, how?

##### Share on other sites
Destruction involves executing the destructor. This happens for pretty much anything, including automatic variables. Deleting involves invoking "delete" to invoke the destructor of the object (thus, destruction) and to ask the runtime to, in the appropriate fashion, reclaim the memory used by that object. You can only delete objects that were heap-allocated with an appropriate "new" invocation.

##### Share on other sites
Quote:
Original post by programering
Quote:
Original post by rip-off
Quote:
 Original post by programeringYou can destruct/delete a class member(class)variables in it's destructor, like this:*** Source Snippet Removed ***Just an idea i got.

Destruction and deletion are 2 different things.

I didn't know that, how?

Destruction is calling the destructor. It cleans up object's own resources.

Destruction is part of deletion, which will involve de-allocation of object's own memory as well.

It's possible to call destructor manually, to destroy an object without de-allocating its memory. It's also possible to call constructor on an already allocated object. This is what some SC++L containers do, to prevent excessive re-allocations.

Deletion however involves more, and also cleans up object's allocated memory (sizeof(myObject)).

Heap allocated objects must be explicitly deleted. But stack allocated objects only get their destructors called, since they are "deleted" by modifying the stack.

##### Share on other sites
Quote:
 Original post by fpsgamerThis is a pretty quick question, which I think I already know the answer to...If a class has a number of member variables, is the order in which they are destroyed defined?

You can put a breakpoint or outputdebugstring in your members' destructors and see by yourself.

##### Share on other sites
Quote:
Original post by deks
Quote:
 Original post by fpsgamerThis is a pretty quick question, which I think I already know the answer to...If a class has a number of member variables, is the order in which they are destroyed defined?

You can put a breakpoint or outputdebugstring in your members' destructors and see by yourself.

No; that determines what the order is (on that particular computer/OS/compiler/set of compiler settings), but not whether it will always be like that. The unfortunate reality of C++.

##### Share on other sites
Quote:
Original post by Antheus
Quote:
Original post by programering
Quote:
Original post by rip-off
Quote:
 Original post by programeringYou can destruct/delete a class member(class)variables in it's destructor, like this:*** Source Snippet Removed ***Just an idea i got.

Destruction and deletion are 2 different things.

I didn't know that, how?

Destruction is calling the destructor. It cleans up object's own resources.

Destruction is part of deletion, which will involve de-allocation of object's own memory as well.

It's possible to call destructor manually, to destroy an object without de-allocating its memory. It's also possible to call constructor on an already allocated object. This is what some SC++L containers do, to prevent excessive re-allocations.

Deletion however involves more, and also cleans up object's allocated memory (sizeof(myObject)).

Heap allocated objects must be explicitly deleted. But stack allocated objects only get their destructors called, since they are "deleted" by modifying the stack.

I though that the destructor was called by delete.

##### Share on other sites
Quote:
 Original post by programeringI though that the destructor was called by delete.

Of course you are correct, calling delete does call the destructor.

But it also deallocates heap memory. We can separate these operations by manually calling the destructor and then calling operator delete:

Foo *foo = new Foo;// use foofoo->~Foo();operator delete(foo);

This allows us to do things like preallocate memory for a number of Foo instances and create and destroy them later. This is what the Standard C++ Library containers do.