Operator new[] does not receive extra bytes

Question

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.

Why do you think the compiler "should do the exact same thing"? — AnT stands with Russia, Dec 06 '12 at 15:29
I thought that if I do not implement destructor at all the compiler will make it for me and it will look like the one I've commented in the example above - empty. — Pavel Dubsky, Dec 06 '12 at 17:33
Conceptually, this is the case. However, when a compiler implicitly implements a destructor that does absolutely nothing, such destructor is called *trivial*. Such destructor does not really play any role and the compiler does not have to call it. Actually, even if you explicitly implement an empty destructor, the compiler doesn't have to call it, but your compiler apparently wanted to keep the call. — AnT stands with Russia, Dec 06 '12 at 19:03

AnT stands with Russia · Accepted Answer · 2012-12-06T16:30:23.637

"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.

score 6 · Answer 2 · answered Dec 06 '12 at 15:11

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.

Operator new[] does not receive extra bytes

2 Answers2

Linked