Why GCC prefers global size-unaware deallocation function?

I have the following operator delete replacements:

void operator delete[](void* p)
{
 /* Implementation does not matter. */
}

void operator delete[](void* p, std::size_t size)
{
 /* Implementation does not matter. */
}

My question is why, in the following code, GCC 6.2 calls void operator delete[](void*) and not the second replacement:

char* str = new char[14];
delete[] str;

According to 5.3.5 Delete [expr.delete]:
(10.3) If the type is complete and if, for the second alternative (delete array) only, the operand is a pointer to a class type with a non-trivial destructor or a (possibly multi-dimensional) array thereof, the function with a parameter of type std::size_t is selected.

Therefore, I believe operator delete[](void*, std::size_t) must be called, doesn't it?

1 Answer

char is not a class type with a non-trivial destructor, so the second condition does not hold.

Under the hood, if C++ allocates an array with non-trivial destructors, it must also store the size of the array so it knows how many destructors to call, and can then use the stored size of the array to call the sized deallocator function. In this case, there's no need to call the destructors, so C++ only allocates 14 chars, and does not store the size.

answer Dec 4, 2016 by Sheetal Chauhan

Similar Questions

+1 vote

gcc compiler didn't error on function with no return statement

I need some help in understanding why my GCC didn't consider this an issue. I have a function that was constructing a path to a daemon program based on the location of the shared object file where this code is. Something similar to this:

namespace {
 std::string ConstructPath()
 {
 int lastSlash(0);
 std::string pathVar;
 Dl_info dl_info;
 memset(

 if((dladdr((void*)ConstructPath, 
 }

 pathVar = dl_info.dli_fname;
 lastSlash = pathVar.find_last_of('/');
 if(std::string::npos == lastSlash)
 {
 // no slashes given ... must be that *.so
 // is in the current directory
 pathVar = "mydaemond";
 }
 else
 {
 pathVar.erase(pathVar.begin() + (lastSlash + 1), pathVar.end());
 pathVar.append("mydaemond");
 }

 // first check if we can find the daemon
 {
 // introducing sub-scope to ensure the file object is closed
 std::ifstream test(pathVar.c_str());
 if(!test.good())
 {
 throw std::runtime_error("cannot find mydaemond");
 }
 }

 // *** the below statement wasn't there originally, the
 // *** function simply exited after the forced-scope block above,
 // *** however, the function *did* have the return type
 return pathVar;
 }
}

My comments above the final return statement illustrate what my question is about. Why wasn't this a problem? There was no return statement and yet, the code compiled fine. I'm using GCC 4.4.4 on CentOS 6.2. Is this just a problem with the 4.4.4 compiler that was fixed? I'm betting there's some subtlety in C++ here that I'm not yet aware of and I'd like to be schooled.

0 votes

Extending the core language via a gcc plugin possible?

is it possible to add a private extension to the core language (C/C++) by writing a gcc plugin?

The extension in mind is something like this

[variable_definitions;]

Later I want this be possible also inside statement headers, for example

for ([double d = 1.0; bool f = false;] size_t i = 0; i < vec.size(); ++i)
 ...

The scope of the so-defined variables shall be the same scope they are in, ie. in the for-loop case just the scope of the for-loop itself, much like the case with i.