I have such code
#include <cstdlib>
class Foo
{
int m_data;
public :
Foo() : m_data(0) { }
/*~Foo()
{
}*/
static void* operator new[](const size_t size)
{
return malloc(size);
}
static void operator delete[](void* data)
{
free(data);
}
};
int main()
{
Foo* objects = new Foo[5];
delete [] objects;
}
In this case I receive value of size in operator new overloading as 20 bytes as I wanted (sizeof(int) * 5). But if I uncomment the destructor I get size as 24 bytes. Yeah, I now that these extra bytes is used to store the size of allocated memory and equals to sizeof(size_t). I can’t understand why I get them only if I implement destructor explicitly. If I don’t do it, the compiler should do the exact same thing or I missing something?
I’ve tried that on MSVS 2010 and 2012. Compiled for Win32.
“Extra bytes” requested by
new[]fromoperator new[]are not used to “store the size of allocated memory”, as you seem to believe. They are used to store the number of elements in the array, so that thedelete[]will know how many destructors to call. In your example destructors are trivial. There’s no need to call them. So, there’s no need to allocate these extra bytes and store the element count.The “size of allocated memory” (i.e. the size of the block in bytes) is a completely different story. It is stored and retrieved independently by a lower-level allocator – the
malloc/freein your example.In other words, in general case a memory block allocated by
new[]has two sets of extra bytes in front of the actual data: the block size in bytes (introduced bymalloc) and the element count (introduced bynew[]). The second one is optional, as your example demonstrates. The first one is typically always present, as it is unconditionally allocated bymalloc. I.e. yourmalloccall will physically allocate more than20bytes even if you request only20. These extra bytes will be used bymallocto store the block size in bytes.The latter happens in your example as well. You simply don’t see it since it happens inside
malloc.