Why there is no placement delete expression in C++?

Question

Why C++ hasn't placement delete that directly corresponds to the placement new, i.e. calls the destructor and calls appropriate placement delete operator?

For example:

MyType *p = new(arena) MyType;
...
//current technique
p->~MyType();
operator delete(p, arena);

//proposed technique
delete(arena) p;

Solution 1

operator delete is unique in being a non-member or static member function that is dynamically dispatched. A type with a virtual destructor performs the call to its own delete from the most derived destructor.

struct abc {
    virtual ~abc() = 0;
};

struct d : abc {
    operator delete() { std::cout << "goodbye\n"; }
};

int main() {
    abc *p = new d;
    delete p;
}

(Run this example.)

For this to work with placement delete, the destructor would have to somehow pass the additional arguments to operator delete.

• Solution 1: Pass the arguments through the virtual function. This requires a separate virtual destructor for every static member and global operator delete overload with different arguments.
• Solution 2: Let the virtual destructor return a function pointer to the caller specifying what operator delete should be called. But if the destructor does lookup, this hits the same problem of requiring multiple virtual function definitions as #1. Some kind of abstract overload set would have to be created, which the caller would resolve.

You have a perfectly good point, and it would be a nice addition to the language. Retrofitting it into the existing semantics of delete is probably even possible, in theory. But most of the time we don't use the full functionality of delete and it suffices to use a pseudo-destructor call followed by something like arena.release(p).

Solution 2

Probably because there was syntax for explicitly calling a destructor without deallocation (exactly as in your question), but no syntax for explicit construction in raw memory?

Solution 3

Actually there is a placement delete which is called by the implementation for an object that was "allocated" using placement new if the constructor threw an exception.

From Wikipedia.

The placement delete functions are called from placement new expressions. In particular, they are called if the constructor of the object throws an exception. In such a circumstance, in order to ensure that the program does not incur a memory leak, the placement delete functions are called.

Solution 4

The whole point of placement new is to separate object creation from its memory management. So it makes no sense to tie it back during object destruction.
If memory for your objects is from heap and you want same lifetime for objects and their memory just use operator new and operator delete, maybe overriding them if you want any special behavior.
Placement new is good for example in vector, which keeps a large chunk of raw memory and creates and destroys object inside of it, but without releasing memory.

View more solutions

Comments

[Tanner Sansbury]

Despite the title, I think the question is about the calling convention of the placement delete compared to the calling convention of placement new, not the existence of placement delete.

[Potatoswatter]

Explicit construction in raw memory is exactly what placement new is. (The memory may also obtained from something like an arena object.) But this answer doesn't draw any actual connection between construction and destruction; the point isn't clear.

[alecov]

Interesting analysis, but still it is unclear to me why an hypothetical e.g. delete (args...) pointer; could not be simply resolved to e.g. pointer->~T(); operator delete(pointer, args...); (that is, the deleter function would not be called from the destructor directly, as I presume you suggest, but instead a call to the deleter would be introduced by the compiler just after the destructor call).

[Potatoswatter]

@Alek For a polymorphic class, pointer is not what should be passed to operator delete. Instead it needs a derived_pointer. The problem is solvable, but only with a bit of complexity.