How to properly free the memory allocated by placement new?

Question

I've been reading somewere that when you use placement new then you have to call the destructor manually.

Consider the folowing code:

   // Allocate memory ourself
char* pMemory = new char[ sizeof(MyClass)];

// Construct the object ourself
MyClass* pMyClass = new( pMemory ) MyClass();

// The destruction of object is our duty.
pMyClass->~MyClass();

As far as I know operator delete normally calls the destructor and then deallocates the memory, right? So why don't we use delete instead?

delete pMyClass;  //what's wrong with that?

in the first case we are forced to set pMyClass to nullptr after we call destructor like this:

pMyClass->~MyClass();
pMyClass = nullptr;  // is that correct?

BUT the destructor did NOT deallocate memory, right? So would that be a memory leak?

I'm confused, can you explain that?

Nyctophobia

Well, technically, placement new does not allocate memory. But it's a detail in this contex. – Dealer

@Griwes: +1 Arguably it's a fundamental point :) – Byroad

Answer 1

Using the new expression does two things, it calls the function operator new which allocates memory, and then it uses placement new, to create the object in that memory. The delete expression calls the object's destructor, and then calls operator delete. Yeah, the names are confusing.

//normal version                   calls these two functions
MyClass* pMemory = new MyClass;    void* pMemory = operator new(sizeof(MyClass));
                                   MyClass* pMyClass = new( pMemory ) MyClass();
//normal version                   calls these two functions
delete pMemory;                    pMyClass->~MyClass();
                                   operator delete(pMemory);

Since in your case, you used placement new manually, you also need to call the destructor manually. Since you allocated the memory manually, you need to release it manually.

However, placement new is designed to work with internal buffers as well (and other scenarios), where the buffers were not allocated with operator new, which is why you shouldn't call operator delete on them.

#include <type_traits>

struct buffer_struct {
    std::aligned_storage_t<sizeof(MyClass), alignof(MyClass)> buffer;
};
int main() {
    buffer_struct a;
    MyClass* pMyClass = new (&a.buffer) MyClass(); //created inside buffer_struct a
    //stuff
    pMyClass->~MyClass(); //can't use delete, because there's no `new`.
    return 0;
}

The purpose of the buffer_struct class is to create and destroy the storage in whatever way, while main takes care of the construction/destruction of MyClass, note how the two are (almost*) completely separate from each other.

_{*we have to be sure the storage has to be big enough}

Humfried

This is the root of the question: "However, placement new is designed for internal buffers, which were themselves not allocated with new, which is why you shouldn't call delete on them." You don't free the memory because you'll be using that piece of your buffer for another object of the same type at some future time. You call the destructor so that the instance can clean up. – Bernabernadene

Nice example, So to delete buffer we call: delete[] a.buffer if it would be dinamicaly, and how do we call destructor of MyClass then? – Nyctophobia

@codekiddy: Since a.buffer is not dynamically allocated, it does not need to be deallocated. In my sample it is automatically allocated, so the buffer is completely automatic in every way. The only concern is placement new of the class, and then calling that class's destructor, as my sample code shows. – Humfried

The buffer might well have been allocated using new - the point of using placement new, though, is to separate memory allocation from initialization. You allocate your memory somehow (whether with new or not), and then construct objects into the allocated memory. That's why you shouldn't try and destruct the objects and deallocate at the same time - the whole point is to separate the memory allocation and object lifetime concerns (also, it doesn't work in general). – Byroad

FTR, there is max_align_t in C++11, which is a type with the largest alignment. There's also std::aligned_storage. ANd what Fred says still stands though. There are no alignment guarantees here. – Survive

@MooingDuck Fred said your buffer didn't provide any alignment guarantees. It might have been large enough for you to align your data inside it, but you weren't actually aligning it. – Survive

Answer 2

One reason this is wrong:

delete pMyClass;

is that you must delete pMemory with delete[] since it is an array:

delete[] pMemory;

You can't do both of the above.

Similarly, you might ask why you can't use malloc() to allocate memory, placement new to construct an object, and then delete to delete and free the memory. The reason is that you must match malloc() and free(), not malloc() and delete.

In the real world, placement new and explicit destructor calls are almost never used. They might be used internally by the Standard Library implementation (or for other systems-level programming as noted in the comments), but normal programmers don't use them. I have never used such tricks for production code in many years of doing C++.

Beauchamp

Just to mention it: placement new is also used frequently when doing OS development or some similar thing in C++. – Dealer

Hi, so we acctualy don't have to call destructor manualy since delete[] pMemory will call the destructor AND free the memory sin'it? – Nyctophobia

@codekiddy: delete[] pMemory does not call the destructor for your object. – Beauchamp

@codekiddy: When you say delete[] x;, it calls the destructor for each element of x. Your array is of char, so you do nothing for each char. You only happened to have previously constructed and destructed a MyClass there, but that has nothing to do with new or delete. – Fourteenth

Answer 3

You need to distinguish between the delete operator and operator delete. In particular, if you're using placement new, you explicitly invoke the destructor and then call operator delete (and not the delete operator) to release the memory, i.e.

X *x = static_cast<X*>(::operator new(sizeof(X)));
new(x) X;
x->~X();
::operator delete(x);

Note that this uses operator delete, which is lower-level than the delete operator and doesn't worry about destructors (it's essentially a bit like free). Compare this to the delete operator, which internally does the equivalent of invoking the destructor and calling operator delete.

It's worth noting that you don't have to use ::operator new and ::operator delete to allocate and deallocate your buffer - as far as placement new is concerned, it doesn't matter how the buffer comes into being / gets destroyed. The main point is to separate the concerns of memory allocation and object lifetime.

Incidentally, a possible application of this would be in something like a game, where you might want to allocate a large block of memory up-front in order to carefully manage your memory usage. You'd then construct objects in the memory you've already acquired.

Another possible use would be in an optimized small, fixed-size object allocator.

Byroad

Answer 4

It's probably easier to understand if you imagine constructing several MyClass objects within one block of memory.

In that case, it would go something like:

1. Allocate a giant block of memory using new char[10*sizeof(MyClass)] or malloc(10*sizeof(MyClass))
2. Use placement new to construct ten MyClass objects within that memory.
3. Do something.
4. Call the destructor of each of your objects
5. Deallocate the big block of memory using delete[] or free().

This is the sort of thing you might do if you're writing a compiler, or an OS, etc.

In this case, I hope it's clear why you need separate "destructor" and "delete" steps, because there's no reason you will call delete. However, you should deallocate the memory however you would normally do it (free, delete, do nothing for a giant static array, exit normally if the array is part of another object, etc, etc), and if you don't it'll be leaked.

Also note as Greg said, in this case, you can't use delete, because you allocated the array with new[] so you'd need to use delete[].

Also note that you need to assume you haven't overridden delete for MyClass, else it will do something totally different which is almost certainly incompatible with "new".

So I think you're unlikley to want to call "delete" as you describe, but could it ever work? I think this is basically the same question as "I have two unrelated types that don't have destructors. Can I new a pointer to one type, then delete that memory through a pointer to another type?" In other words, "does my compiler have one big list of all allocated stuff, or can it do different things for different types".

I'm afraid I'm not sure. Reading the spec it says:

5.3.5 ... If the static type of the operand [of the delete operator] is different from its dynamic type, the static type shall be a base class of the operand's dynamic type and the static type shall have a virtual destructor or the behaviour is undefined.

I think that means "If you use two unrelated types, it doesn't work (it's ok to delete a class object polymorphically through a virtual destructor)."

So no, don't do that. I suspect it may often work in practice, if the compiler does look solely at the address and not the type (and neither type is a multiple-inheritance class, which would mangle the address), but don't try it.

Shir