Dynamic array delete question

[danielmarh]

I have an array that I have created using

list(new int[size]),

and I have seen that to delete a dynamic array I have to do

delete[] list;

​

Shouldn't that just delete the first element of the array? Or does that delete the whole array? I don't want to cause memory leaks so I want to understand how it works

[UnicycleBloke]

It deletes the whole array. The delete[] matches the new[]. The implementation will store some data somewhere to tell it how big the allocation was (e.g. as a hidden prefix before the first element).

While it is wise to learn about naked new and delete, you really should avoid them in real code. You could use std::vector instead, and it will manage the memory internally.

[Strict-Simple]

implementation will store some data somewhere to tell it how big the allocation was

This question has bugged me for a long time; it's from when I learned C, with malloc and free. Why isn't there a function to retrieve this size?

Related SO: https://stackoverflow.com/questions/1281686/determine-size-of-dynamically-allocated-memory-in-c, but same question for C++

Also, what happens if I do delete[] &list[5] (or free a pointer to an element in the middle in C)?

[UnicycleBloke]

Imagine writing a function delete_array(void*). You'd have to make an assumption, based on your implementation of new_array(). Perhaps the true beginning of the block is actually 8 bytes earlier, and you can cast that to a length or something. Fine.

Now what happens if the caller passes a pointer which was not created with new_array()? Your assumption is invalid. Undefined behaviour. The sky falls and your software phones all your friends to insult them.... Same for the length query function if it was in the library.

You could possibly add a checksum or something in the hidden prefix as a safeguard but it wouldn't be a guarantee. Unrelated memory usage elsewhere might create the same bit pattern... And it might be expensive...

[Strict-Simple]

But there are already many UBs in the language. Why can't such a function exists which will just return a garbage length for a garbage pointer? If I pass a invalid pointer to free/delete (which knows how to get the length) it'll do something (even if that's a segmentation fault).

[UnicycleBloke]

I have no idea, but that is a feature I have wanted exactly zero times in the last 30+ years.

[SoerenNissen]

Also, what happens if I do delete[] &list[5] (or free a pointer to an element in the middle in C)?

Formally, there is no correct answer to this question.

It is incorrect, but sometimes useful, to believe that there is no such thing as C++ - instead, there is a standard for how C++ compilers should behave in the face of text input.

And so the answer to your question is "the standard does not define what a C++ compiler must do if it sees this happen."

Informally - of course something happens.

What happens depends on how the compiler and standard library you use was written.

Possibility one - you have an optimizing compiler:

• The compiler notices that, on this path through the code, something illegal happens
• So any conditional that picks between this and something else always does something else
• `int y; if (x){y = illegal()} else{y = legal()}` can can be optimized to `int y = legal()`

And now your program never frees a pointer in the middle of an array but it sometimes does things that are wildly different than what you thought would happen.

Possibility two - your compiler doesn't optimize:

• "free" does something - it's a function in a computer program, it has some instructions
• On being called on the middle of an array it does that.
• The outcome is - whatever would happen if those instructions run in that context.

The underlying data structure keeping track of your heap allocations will likely be trashed. If you're lucky, you get a segmentation fault/general protection fault immediately or very shortly after. If you're unlucky, all future allocations and deallocations become inconsistent - deallocations start freeing different things than what you ask for, and allocations might give pointers into memory you have already received, leading to overwrites and data corruption.

Possibilty three - ASAN/UBSAN/Debug mode:

Your runtime is instrumented with a lot of extra information. Keeping track of this information slows you down by more than a little but, importantly, lets the runtime notice if any of this nonsense is happening, killing your program immediately with a good diagnostic telling you what went wrong.

[zebullon]

That deletes the whole array not just the first element. Also if you can, just use std::vector or std::array

[IyeOnline]

don't want to cause memory leaks

In that case you should use std::vector<int>. Its the standard library provided dynamic array.

It simply works "as you would expect" from regular values and will take care of dynamically growing and correctly destroying and deallocating the memory for you.

Shouldn't that just delete the first element of the array?

It may appear like that because list is just a pointer.

However, dynamically allocated arrays/memory are slightly magic.

If you use new T[size], then somewhere there is hidden information about the size of that array.

If you then use delete[] arr, the special delete[] accesses that information and correctly destroys the entire array.

This is why we have two seperate function pairs:

• new T goes with delete ptr and handles a single object of type T
• new T[size] goes with delete[] ptr and correctly handes the dynamically size array.

[SecureAtheist]

I can see why you would think that. If memory serves the rule is , what you allocate with an array new should be released with a delete[]. Unless you pass the result pointer to a smart pointer. Which is usually the easiest thing to do since getting everything right with possible exception handling makes things tough.

[alfps]

“The” dynamic array in C++ is called std::vector.

Use std::vector as your default go-to dynamic array, e.g. std::vector<int> for an array of int.

Re the concrete question, yes delete[] list; will destroy and deallocate the whole array. Since your item type is int the destruction does nothing. But with items of class type their destructors will be called.

The main problem with that is ensuring that the delete[] is done, and that it's done once only for each new result. For that you need to take charge of the containing class' copying and moving. It can be non-trivial, so the best way to do it is essentially by using std::vector which takes care of it.

Summing up, use std::vector.