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[] from operator 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 the delete[] 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/free in 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 by malloc) and the element count (introduced by new[]). The second one is optional, as your example demonstrates. The first one is typically always present, as it is unconditionally allocated by malloc. I.e. your malloc call will physically allocate more than 20 bytes even if you request only 20. These extra bytes will be used by malloc to 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.
If the compiler doesn't need to call the destructor, it doesn't need to remember how many destructors to call. You would not observe this behaviour if you had a data member that needed destructing, like std::string, as the compiler would always need to destruct it.
