7

This is something I've been wondering for a while and never found an answer for:

Why is it that when you allocate something on the heap you cannot determine the size of it from just the pointer, yet you can delete it using just the pointer and somehow C++ knows how many bytes to free?

Does this have something to do with the way it is stored on the heap? Is this information there but not exposed by C++?

And perhaps this should be a separate question but I think it's pretty related so I'll ask it here:

Why is it a dynamic array of elements must be deleted using delete [] as opposed to just the simple delete command; why does C++ need this additional information to correctly free all the memory?

trincot
  • 317,000
  • 35
  • 244
  • 286
Matt
  • 113
  • 4
  • 2
    http://stackoverflow.com/questions/197675/how-does-delete-know-the-size-of-the-operand-array – taocp Oct 16 '14 at 18:48
  • That's the OS memory manager taking care of things. – dtech Oct 16 '14 at 19:40
  • 1
    As for arrays, the C++ compiler and runtime have "private" access to how long the array is in order to call the appropriate number of destructors if necessary. Also http://stackoverflow.com/questions/11049144/is-the-size-of-a-dynamically-allocated-array-stored-somewhere/11049350#11049350 – dtech Oct 16 '14 at 19:57
  • It's not standardized to allow each implementer flexibility in choosing how they want to handle such things. The more things are specified, the more restrained the implementation, which may adversely impact performance. Performance is #1. – Mordachai Oct 16 '14 at 20:34

1 Answers1

7

When an allocation is made, a small section of memory immediately before [or, technically, somewhere completely different, but just before is the most common scenario] will store the size of the allocation, and in the case of new [] also store the number of allocated objects.

Note that the C++ standard doesn't give any way to retrieve this information for a reason: It may not accurately describe what is allocated, for example the size of an array may very well be rounded up to some "nice" boundary [almost all modern allocators round to 16 bytes at the very least, so that the memory is usable for SSE and other similar SIMD implementations on other processor architectures]. So if you allocated 40 bytes, it would report back 48, which isn't what you asked for, so it would be rather confusing. And of course, there is no guarantee that the information is stored at ALL - it may be implied by some other information that is stored in the "admin" block of the allocation.

And of course, you can use placement new, in which case there is no admin block, and the allocation is not deleted in the normal fashion - some arbitrary code wouldn't be able to tell the difference.

delete differs from delete [] in that delete [] will know how many objects have been allocated, and call the destructor for all of those objects. It is also possible [or even likely] that new [] stores the number of elements in a way that means that calling delete [] on something that wasn't created with new [] will go horribly wrong.

And as Zan Lynx commented, that if there is no destructor for the objects (e.g. when you are allocating data for int or struct { int x; double y; }, etc - including classes that don't have a constructor [note however that if you have another class inside the class, the compiler will build a destructor for you]), then there is no need to store the count, or do anything else, so the compiler CAN, if it wishes, optimise this sort of allocation into regular new and delete.

Mats Petersson
  • 126,704
  • 14
  • 140
  • 227
  • `new[]` and `delete[]` are also optimized to never store the length when the type is POD (plain old data) since it never has to call destructors then. – Zan Lynx Oct 16 '14 at 20:27
  • Exactly what I wanted to know. Thank you. :) – Matt Oct 16 '14 at 20:27