The C++ standard very clearly and explicitly states that using
delete on a
void-pointer is undefined behavior, as quoted in this answer:
This implies that an object cannot be deleted using a pointer of type
void*because there are no objects of type
However, as I understand it,
delete do just two things:
- Call the appropriate destructor(s)
- Invoke the appropriate
operator deletefunction, typically the global one
There is a single-argument
operator delete (as well as
operator delete), and that single argument is
So, when the compiler encounters a delete-expression with a
void* operand, it of course could maliciously do some completely unrelated operation, or simply output no code for that expression. Better yet, it could emit a diagnostic message and refuse to compile, though the versions of MSVS, Clang, and GCC I've tested don't do this. (The latter two emit a warning with
-Wall; MSVS with
/W3 does not.)
But there's really only one sensible way to deal with each of the above steps in the delete operation:
void*specifies no destructor, so no destructors are invoked.
voidis not a type and therefore cannot have a specific corresponding
operator delete, so the global
operator delete(or the
version) must be invoked. Since the argument to the function is
void*, no type conversion is necessary, and the operator function must behavior correctly.
So, can common compiler implementations (which, presumably, are not malicious, or else we could not even trust them to adhere to the standard anyway) be relied on to follow the above steps (freeing memory without invoking destructors) when encountering such delete expressions? If not, why not? If so, is it safe to use
delete this way when the actual type of the data has no destructors (e.g. it's an array of primitives, like
Can the global delete operator,
void operator delete(void* ptr) (and the corresponding array version), be safely invoked directly for
void* data (assuming, again, that no destructors ought to be called)?
void* is a pointer to an object of unknown type. If you do not know the type of something, you cannot possibly know how that something is to be destroyed. So I would argue that, no, there is not "really only one sensible way to deal with such a delete operation". The only sensible way to deal with such a delete operation, is to not deal with it. Because there is simply no way you could possibly deal with it correctly.
Therefore, as the original answer you linked to said: deleting a
void* is undefined behavior ([expr.delete] §2). The footnote mentioned in that answer remains essentially unchanged to this day. I'm honestly a bit astonished that this is simply specified as undefined behavior rather than making it ill-formed, since I cannot think of any situation in which this could not be detected at compile time.
Note that, starting with C++14, a
new expression does not necessarily imply a call to an allocation function. And neither does a
delete expression necessarily imply a call to a deallocation function. The compiler may call an allocation function to obtain storage for an object created with a
new expression. In some cases, the compiler is allowed to omit such a call and use storage allocated in other ways. This, e.g., enables the compiler to sometimes pack multiple objects created with
new into one allocation.
Is it safe to call the global deallocation function on a
void* instead of using a
delete expression? Only if the storage was allocated with the corresponding global allocation function. In general, you can't know that for sure unless you called the allocation function yourself. If you got your pointer from a
new expression, you generally don't know if that pointer would even be a valid argument to a deallocation function, since it may not even point to storage obtained from calling an allocation function. Note that knowing which allocation function must've been used by a
new expression is basically equivalent to knowing the dynamic type of whatever your
void* points to. And if you knew that, you could also just
static_cast<> to the actual type and
Is it safe to deallocate the storage of an object with trivial destructor without explicitly calling the destructor first? Based on, [basic.life] §1.4, I would say yes. Note that, if that object is an array, you might still have to call the destructors of any array elements first. Unless they are also trivial.
Can you rely on common compiler implementations to produce the behavior you deem reasonable? No. Having a formal definition of what exactly you can rely on is literally the whole point of having a standard in the first place. Assuming you have a standard-conforming implementation, you can rely on the guarantees the standard gives you. You can also rely on any additional guarantees the documentation of a particular compiler may give you, so long as you use that particular version of that particular compiler to compile your code. Beyond that, all bets are off…