Will destructor delete built-in types and pointer objects?

I'm a c++ beginner and now reading the C++ Primer. I have some problem about the destrucor:

1. in chapter 13.1.3: "In a destructor, there is nothing akin to the constructor initializer list to control how members are destroyed; the destruction part is implicit. What happens when a member is destroyed depends on the type of the member. Members of class type are destroyed by running the member’s own destructor. The built-in types do not have destructors, so nothing is done to destroy members of built-in type."

   So if I have such a class:

class Foo { ~Foo() { delete pi; } int *pi; int i; }; 

When an instance of Foo is going to be destroyed, according to the above text, the built in type variable int i will not be destroyed? Then how it will exist since the object to which it belongs has been destroyed.

2. In chapter 13.1.4: "The HasPtr class that we have used in the exercises is a good example (§ 13.1.1,p.499). That class allocates dynamic memory in its constructor. The synthesized destructor will not delete a data member that is a pointer. Therefore, this class needs to define a destructor to free the memory allocated by its constructor."

   I understand that the synthesized destructor does not de-allocate the memory that has been allocated by new and is pointed to by plain pointers, but here in the text, it indicates that the pointer object itself is also not deleted by the synthesized pointer. Still the example of class Foo, does that mean that after an object of Foo class is destroyed, the pointer pi will not be destroyed ( so becomes an invalid pointer )?

4 Answers

What the spec means is that no code is run to clean up int i. It simply ceases to exist. Its memory is part of Foo and whenever a Foo instance is released, then i goes with it.

For pointers the same is true, the pointer itself will simply disappear (it's really just another number), but the pointer might point at something that needs to also be released. The compiler doesn't know if that is the case, so you have to write a destructor.

This is why things like std::shared_ptr exist; they are clever pointers (aka 'smart') and the compiler does know if it points at something that needs to be released and will generate the correct code to do so. This is why you should always use smart pointers instead of 'naked' ones (like int *p).

A destructor always destroys all members, just like a constructor always creates all members. You can't stop it from doing that.

according to the above text, the built in type variable int i will not be destroyed?

It will be destroyed. What the book says is that destroying an int doesn't perform any actions (it's said to be a "no-op"), in the sense that it translates to 0 machine instructions.

Same for pointers (not the data they point to), so the wording in (2) is sloppy, and your initial understanding was correct.

according to the above text, the built in type variable int i will not be destroyed?

It will be destroyed, but nothing is done to destroy it. The destruction is trivial.

int *pi member variable also has a fundamental type, and same applies to it.

Then how it will exist

It won't exist.

does that mean that after an object of Foo class is destroyed, the pointer pi will not be destroyed ( so becomes an invalid pointer )?

It does not mean that. All sub objects are always destroyed both by all synthesised destructors, as well as all user defined destructors.

Deleting a pointer, and destroying a pointer are two separate things. Deletion destroys the pointed object and deallocates the dynamic memory. Destruction ends the lifetime of the pointer itself, and is trivial because pointers are fundamental types.

Destruction is what the synthesised - as well as all other - constructors do to the member. A synthesised destructor never deletes any pointer, but the user defined ~Foo in the example does delete the member.

Although it's important to learn these things, don't use owning bare pointers in practice. Use RAII classes such as smart pointers or containers instead.

pi stores in stack memory, and it points to an address in heap memory! you need to call

delete pi; 

to deallocate that part of memory in heap pi itself doesn't need to be deallocated it will be deallocated after it's scope.