CODEWITHSUNDEEP
c++destructordelete-operator
Dpp
Dpp

Reputation: 1974

Is the whole object freed with a non-virtual destructor and a Base class pointer?

If a Base class does not have a virtual destructor (in order to avoid the vtable entry for instance) and the Derived class has only basic attributes, does it free all the memory allocated by new, when the pointer of the Base class is deleted? I know the destructor of the Derived class will not be called but I am wondering if the memory allocated by the whole object will be freed? I assume also that calling delete on a Derived pointer will free the whole memory space.

Also, if it does not free the Derived class part of the memory, how does it work in the same case but with of a virtual destructor in the Base class, to know how much memory to free?

Example:

class Base {
  public:
    int a;
    int b;
   Base() {}
  ~Base() {}
};

class Derived : public Base {
  public:
    int c;
    int d;
    Derived() {}
    ~Derived() {}
};

int main() {
  Base *p = new Derived();
  delete p; // is memory allocated for Derived freed?
}

Upvotes: 5

Views: 462

Answers (6)

Yakov Galka
Yakov Galka

Reputation: 72449

It's undefined behavior, so anything can happen. Quote from the standard [expr.delete]:

In the first alternative (delete object), if the static type of the object to be deleted is different from its dynamic type, the static type shall be a base class of the dynamic type of the object to be deleted and the static type shall have a virtual destructor or the behavior is undefined.

Just don't do that.

I think it's a good idea to understand what actually happens though to understand why the standard has that requirement.

In your simple case, on a typical implementation, the memory will be freed regardless. That is because operator delete will call free(p). Since Base is the first non-virtual base class of Derived, it happens to be located at the beginning of the allocated memory block. And since free must know the size of the allocated block by its own bookkeeping (being a C function it doesn't know anything about sizes of types), it will deallocate the entire block.

However, since Base doesn't have a virtual destructor, delete p is resolved based on the static-type of *p (which is Base). Consequently, as you're seemingly aware, it will not call the destructor of Derived. If Derived had any non-trivial members or base-classes, those would not be destructed either, so any resources that they manage would be leaked.

When the class has a virtual destructor, the work of freeing the memory is delegated to the destructor. The reason is that, although free knows to determine the size of the block, it would still need to have the pointer to the beginning of it. Base can be at an arbitrary offset within Derived in the general case, therefore Derived destructor will be responsible for adjusting the pointer prior to freeing it. This also adds the need for a separate destructor that would destructor the object without actually freeing the memory; e.g. as a subobject of another derived type, or as explicit destructor call. And let's keep delete[] out of the discussion. When you mark your destructor as virtual, the compiler takes care of all this for you.

The bottom line is that the standard doesn't describe all these implementation details, leaving them instead to—um—the implementation. They could formulate some sensible criteria when deleting a non-virtual base would still be ok; but instead they went with the simple clear-cut "you have a virtual destructor then it's ok, otherwise it's not ok" rule.

Upvotes: 5

Yttrill
Yttrill

Reputation: 4921

There is a good chance the memory will be correctly freed. Just because the Standard doesn't assure this doesn't mean it won't work. It's hard to see how it could fail.

Upvotes: 0

Stuart Golodetz
Stuart Golodetz

Reputation: 20616

Formally speaking, this is undefined behaviour, so you have no guarantees that the memory is freed, or indeed that your program does anything in particular. It may format your hard disk. It may not. In practice, the memory might well be freed in this case -- but you're daft if you rely on it, and you shouldn't do it. It's as simple as that.

Upvotes: 3

SingleNegationElimination
SingleNegationElimination

Reputation: 156128

Edit: I Was mistaken: Key prose from draft standard, emphasis mine: Section 5.3.5

3 In the first alternative (delete object), if the static type of the object to be deleted is different from its dynamic type, the static type shall be a base class of the dynamic type of the object to be deleted and the static type shall have a virtual destructor or the behavior is undefined. In the second alternative (delete array) if the dynamic type of the object to be deleted differs from its static type, the behavior is undefined.

Upvotes: 0

mjfgates
mjfgates

Reputation: 3431

In the very particular case that you describe, all of the memory used by the derived class object will be freed when you don't have a virtual destructor. (If using non-virtual destructors always caused derived classes to leak memory, I don't think the language would allow inheriting from classes that used them!)

Remember, the DESTRUCTOR is not what frees the memory; "delete" frees the memory. The destructor is just a function that gets CALLED by delete.

Blah blah blah extensibility blah blah cause yourself trouble in the future blah blah careful with that etc. etc. etc. You know what I mean, obviously.

Upvotes: -4

Edward Strange
Edward Strange

Reputation: 40849

Technically, the answer is 'unknown'. Deleting a pointer to derived from a pointer to base that has no virtual destructor is undefined behavior.

Practically speaking though, most implementations just fail to properly delete the stuff in the derived object.

Upvotes: 3

Related Questions