3

My question is pretty much an extension of this one: Is std::vector memory freed upon a clear?

Here people explained that the memory allocated for the elements of a std::vector is not released after calling clear(). But will this memory be free for the OS to allow other programs to use it or will it be available for my program to use it anywhere else?

If not (if the memory continues to be allocated only for this vector and I can't access it anymore) isn't it a memory leak like the ones we have with pointers? Then clear() when used alone like this would be totally unsafe right?

I would be happy if someone could clarify me in this one. Thanks.

braX
  • 11,506
  • 5
  • 20
  • 33

3 Answers3

7

Here people explained that the memory allocated for the elements of a std::vector is not released after calling clear(). But will this memory be free for the OS to allow other programs to use it or will it be available for my program to use it anywhere else?

No, the memory will still be held by the std::vector instance, and will not be available for use by the rest of the program until the vector itself is destroyed, or shrink_to_fit is called1.

If not (if the memory continues to be allocated only for this vector and I can't access it anymore) isn't it a memory leak like the ones we have with pointers?

Not really. The memory is still released when the vector is destroyed.

Then clear() when used alone like this would be totally unsafe right?

As @user2079303 eloquently put it; clear isn't inherently unsafe, but the assumption that it will free memory may be.

1. Potentially. The call to shrink_to_fit is not guaranteed to free any memory.

You
  • 22,800
  • 3
  • 51
  • 64
  • 1
    `shrink_to_fit` isn't **guaranteed** to free any memory, either though. – eerorika Jan 11 '17 at 15:59
  • Even `delete` isn't guaranteed to actually free any memory. – PaulMcKenzie Jan 11 '17 at 16:10
  • @PaulMcKenzie An implementation of `malloc` that behaves like a stack that never shrinks, with no-op `free` would indeed be quite fast. – eerorika Jan 11 '17 at 16:15
  • Although technically correct, a better formulation might be *"`shrink_to_fit` is not guaranteed to free **all** memory"*. For example, a `vector(1)` might not be able to shrink to 1 byte, so is allowed to keep 8 or 16 bytes if needed. – Bo Persson Jan 11 '17 at 16:59
7

Does clear() in std::vector generates a memory leak?

No.

But will this memory be free for the OS to allow other programs to use it or will it be available for my program to use it anywhere else?

OS can swap the memory to disk, to allow other programs to use the physical memory.

if the memory continues to be allocated only for this vector and I can't access it anymore

You can reuse the memory by adding new objects into the vector. Or release it by destroying the vector. The destructor absolutely guarantees to free the memory.

isn't it a memory leak like the ones we have with pointers?

No. A memory leak happens when the pointer to the memory is lost. But in this case the vector safely keeps track of the pointer, and frees it when it is destroyed.

Then clear() when used alone like this would be totally unsafe right?

clear isn't inherently unsafe, but the assumption that it will free the memory may be.

eerorika
  • 232,697
  • 12
  • 197
  • 326
  • 1
    I would say that the memory is guaranteed *not* to be released on a call to `clear`, since it [isn't allowed to change the capacity of the vector](http://stackoverflow.com/questions/18467624/what-does-the-standard-say-about-how-calling-clear-on-a-vector-changes-the-capac/18467916#18467916). – You Jan 11 '17 at 16:07
  • "If the memory continues to be allocated for the vector, then you can reuse the memory by adding new objects into the vector." Ok got it now. Of course, I didn't assume that the memory would be reused for other values for the same vector. Thanks. Thinking about it now it seems like a silly question... hahaha Should I delete it or leave it for other people see? –  Jan 11 '17 at 16:23
  • 2
    @MagnoSilva if it confused you, then it will surely confuse some one else as well. Best leave it here so others won't need to repeat the question. – eerorika Jan 11 '17 at 16:27
1

It is not a leak. Generally speaking, a leak is when resources are allocated by your program and you lose all handles to them. An even stricter definition of a leak is when this resource allocation happens repeatedly over time.

A simple call to clear does not fulfill that definition, because you still have access to the std::vector object after the function call; the object does not simply disappear. You can still call shrink_to_fit on it, or swap it with an empty vector. And even that should not be necessary, because eventually, the std::vector will be destructed, and the destructor deallocates the occupied memory, or more correctly speaking, it deallocates the storage, because what happens on the OS or even hardware level is not in the scope of C++ language rules.

If the destructor is not run because the std::vector is never destroyed due to some buggy dynamic memory handling on your part, then the existence of the std::vector object itself already causes a potential leak. The problem is then not with the storage handled by the std::vector.

Note that clear still causes the std::vector's elements to be destroyed immediately. This has the important effect that their destructors are run. So when you have, for example, a std::vector<std::string>, and you call clear on it, then all the individual std::string destructors are run, and of course that causes storage to be deallocated immediately, provided that there was actually some dynamic content handled by the strings (i.e. Small-String Optimisation was not used). But it's not the storage handled by std::vector, but the storage handled by the std::strings'.

Christian Hackl
  • 27,051
  • 3
  • 32
  • 62