2

I'm new to C++ and I've been playing around with memory allocation lately. I have found out that when you declare a class with a destructor, like so:

class B
{
public:
    ~B() { }
};

And then create a heap array of it like so:

B* arr = new B[8];

The allocator allocates 12 bytes but when I remove the destructor, it only allocates 8 bytes. This is how I'm measuring the allocation:

size_t allocated = 0;

void* operator new(size_t size)
{
    allocated += size;
    return malloc(size);
}
void deallocate(B* array, size_t size)
{
    delete[] array;
    allocated -= size * sizeof(B);
}

Of course I have to call deallocate manually while the new operator is called automatically.

I have found this problem while working with an std::string* and I realised that the deallocator worked fine with an int* but not with the former.

Does anyone know why that happens and more importantly: How to detect these programmatically at runtime?

Thanks in advance.

his dudeness
  • 316
  • 3
  • 14
  • "How to detect these programatically at runtime?" - why do you want to? – Dai Nov 07 '21 at 23:33
  • @Dai I'm just playing around seeing how C++ works. Why shouldn't be using `malloc` like that? – his dudeness Nov 07 '21 at 23:35
  • My comment wasn't about using `malloc` particularly - but if you're doing this as a mental exercise that's fine; I was just concerned you might be doing this in production code. I deleted it. – Dai Nov 07 '21 at 23:37
  • Also, see https://stackoverflow.com/questions/34813448/does-operator-newsize-t-use-malloc – Dai Nov 07 '21 at 23:37
  • @Dai Thanks I'll check that out. – his dudeness Nov 07 '21 at 23:38
  • 2
    "I'd like to know what's wrong with malloc" -- `malloc` is fine to use in a `new` implementation, but it needs to be consistent. You _cannot_ `delete[]` memory allocated with `malloc` -- they're different functions, and it's formally undefined behavior. See [In what cases do I use malloc and/or new?](https://stackoverflow.com/q/184537/1678770) and [Behaviour of malloc with delete in C++](https://stackoverflow.com/q/10854210/1678770) – Human-Compiler Nov 07 '21 at 23:42
  • 2
    It's a guess, so I dont want to post an answer, but - adding a non-default destructor makes the class non-trivially destructible. Releasing an array of trivially-destructible objects only requires calling `free()`, but for non-trivially destructible you also have to call destructors. The extra 8 bytes would then be bookkeeping data for compiler, it probably stores number of elements there, so that it can run correct number of destructors before releasing the memory. – Yksisarvinen Nov 07 '21 at 23:49
  • @Human-Compiler Thanks for the sources. I'll definetly check them out. But say I change the implementation of the `new` operator, it still doesn't account for the difference between the `size` in its parameter being 12 bytes when the type has a destructor and 8 bytes when it doesn't. – his dudeness Nov 07 '21 at 23:53

1 Answers1

4

You are looking at an implementation detail of how your compiler treats new[] and delete[], so there isn't a definitive answer for the extra space being allocated since the answer will be specific to an implementation -- though I can provide a likely reason below.

Since this is implementation-defined, you cannot reliably detect this at runtime. More importantly, there shouldn't be any real reason to do this. Especially if you're new to C++, this fact is more of an interesting/esoteric thing to know of, but there should be no real benefit detecting this at runtime.

It's important to also be aware that this only happens with array-allocations, and not with object allocations. For example, the following will print expected numbers:

struct A {
    ~A(){}
};
struct B {
};

auto operator new(std::size_t n) -> void* {
    std::cout << "Allocated: " << n << std::endl;
    return std::malloc(n);
}
auto operator delete(void* p, std::size_t n) -> void {
    std::free(p);
}

auto main() -> int {
    auto* a = new A{};
    delete a;

    auto* b = new B{};
    delete b;
}

Output:

Allocated: 1
Allocated: 1

Live Example

The extra storage only gets allocated for types with non-trivial destructors:

    auto* a = new A[10];
    delete[] a;

    auto* b = new B[10];
    delete[] b;

Outputs:

Allocated: 18
Allocated: 10

Live Example

The most likely reason why this happens is that extra bookkeeping of a single size_t is being kept at the beginning of allocated arrays containing non-trivial destructors. This would be done so that when delete is called, the language can know how many objects require their destructors invoked. For non-trivial destructors, its able to rely on the underlying delete mechanics of their deallocation functions.

This hypothesis is also supported by the fact that for the GNU ABI, the extra storage is sizeof(size_t) bytes. Building for x86_64 yields 18 for an allocation of A[10] (8 bytes for size_t). Building for x86 yields 14 for that same allocation (4 bytes for size_t).

Edit

I don't recommend doing this in practice, but you can actually view this extra data from arrays. The allocated pointer from new[] gets adjusted before being returned to the caller (which you can test by printing the address from the new[] operator).

If you read this data into a std::size_t, you can see that this data -- at least for the GNU ABI -- contains the exact count for the number of objects allocated.

Again, I do not recommend doing this in practice since this exploits implementation-defined behavior. But just for fun:

    auto* a = new A[10];
    const auto* bytes = reinterpret_cast<const std::byte*>(a);
    std::size_t count;
    std::memcpy(&count, bytes - sizeof(std::size_t), sizeof(std::size_t));

    std::cout << "Count " << count << std::endl;

    delete[] a;

The output:

Count 10

Live Example

Human-Compiler
  • 11,022
  • 1
  • 32
  • 59