C++: What does the class destructor do?

Question

Suppose we have an object "myObject", and has several members as follows:

int a;
float b;
yourClass yourObject;
void hisMethod();

From what I read, the memory allocated to "myObject" is like this order.

Once the destructor is called, what happened?

After the destructor is called, before the object is destroyed, from what I read, I can still access (a) the object "myObject". (b) the member yourObject (c) the member hisMethod()

Can I still access its members? It is undefined behavior?

Many C++ books do not talk more details on it. Where can I find more details on it? Because details can help me understand many C++ rules like "not manually call destructor unless after placement new".

[Update 1] I raise my question because I saw the post: What does empty destructor do? The poster gives an example as below:

#include <iostream>
#include <set>


class a
{
public:
std::set <int> myset;
};

int main()
{
a object;
object.myset.insert(55);
object.~a();
object.myset.insert(20);
std::cout << object.myset.size();
}

The poster get: "* glibc detected * /.app: double free or corruption (fasttop):" and then "ABORT".

This means:

object.myset.insert(20);

doesn't raise error, which means the object still exists after destructor manually called. Its class member can still be called!

Double calling of deconstructor gives error.

[Update 1] I run the code in QT Creator, and when run to object.myset.insert(20);

it raise error:

read access violation at: 0x0, flags=0x0.

Calling the dtor ends the objects lifetime. Don't do anything with it. — Deduplicator, Dec 06 '14 at 00:38
*“After the destructor is called, before the object is destroyed”* – What do you mean by that? By definition, the destructor destroys the object. — 5gon12eder, Dec 06 '14 at 00:39
@Deduplicator. I knew the rule. I just wanted to understand the underlying mechanism. — user1914692, Dec 06 '14 at 00:44
@5gon12eder, r you sure the object is destroyed? From what I read, it isn't the case. — user1914692, Dec 06 '14 at 00:45
We'll have to clarify what it means to *destroy an object*. After the destructor was called, the objet's lifetime has ended and any operation on it will invoke undefined behavior. The compiler cannot (and is not supposed to) catch all such abuses (like in the example in your updated post) so it might happily compile the code but arbitrary bad things can happen when it is executed. Just because something compiles (or even runs) this doesn't mean that it is valid C++. — 5gon12eder, Dec 06 '14 at 00:49
@5gon12eder, I want to know the underlying mechanism. So even if it is illegal, I only want to know what happens to those members, those members' memories, and whether we can still refer to the object, refer to the member. This will reveal the underlying mechanism. — user1914692, Dec 06 '14 at 01:01
@user1914692: The underlying mechanism is undefined. The implementation may do anything at all, including ignoring the situation and just letting the dice stop where they want. — Deduplicator, Dec 06 '14 at 01:07
@Deduplicator, if I access those members, can compiler go through? I just want to know whether destructor delete those names too. — user1914692, Dec 06 '14 at 01:11
I think you are confusing the identifier string that refers to an object (something only meaningful to the compiler) and the object itself (only meaningful at run-time). What you are asking is somewhat like “After killing my dog Fido, can I still call Fido by its name?” Maybe you can, but Fido won't care… — 5gon12eder, Dec 06 '14 at 01:18

score 0 · Answer 1 · answered Dec 06 '14 at 00:38

In case of yourClass yourObject;, you can´t access yourObject after destruction,
because the compiler will complain before you get to execution.
In this case (automatic storage duration), the scope is the lifetime of the object, so after destruction, you´re in a code part where the name yourObject isn´t known anymore.

(The destructor and the actual memory freeing are separate, but both occur consecutively without any possibilty to put some own code between them).

If you have some pointer, allocated something with new, and the delete it:
Yes, it´s undefined behaviour to access it after delete.

score 0 · Answer 2 · answered Dec 06 '14 at 00:42

0

the class destructor, ie the method called ~class, does whatever you ask it to do. It does not release the memory.

The destructor is called as part of the process of destroying the object, this process also typically releases the memory associated with the object after its destructor has run. Depending on where and how the object was created different 'releasing' of memory will take place:

on the stack the memory is implicitly freed by the stackframe pointer updates
on the heap it will be freed by releasing the memory back to the heap
for static the memory isnt really released

answered Dec 06 '14 at 00:42

pm100

48,078
23
82
145

does this mean after destructor is manually called, we cannot refer to the object anymore, since there is no such variable in the memory? Or maybe we can still refer to object, just undefined behavior happens? – user1914692 Dec 06 '14 at 01:08
@user1914692 Yes, if you still have the "name" available, ie. the current scope includes it, you could access it. But "just" indefined behaviour is "just" a problematic error which can break your program, so don´t. – deviantfan Dec 06 '14 at 09:40

C++: What does the class destructor do?

2 Answers2