0

context: (from this question reduce the capacity of an stl vector)

Is there a way to reduce the capacity of a vector ?

My code inserts values into a vector (not knowing their number beforehand), and when this finishes, the vectors are used only for read operations. ...

this answer: https://stackoverflow.com/a/1111311/11608725, with the (c++) shrink_to_fit() https://en.cppreference.com/w/cpp/container/vector/shrink_to_fit seems to provide what the OP asks for.

QUESTION: besides from "manually" [e.g. via shrink_to_fit()] reclaiming excess allocated memory; will the running process be able to reclaim this memory automatically if needed? or will the memory forever be lost as long as the objects that caused the allocation persist?

does the c++ (11/17) standard impose/guarantee the behaviour or is it entirely up to the compiler and implementation on a specific OS?

mrchance
  • 1,133
  • 8
  • 24
  • If you've allocated memory, that's you telling the os that you're using that memory. There's good reasons to allocate lots of memory and not want to it to shrink, mainly that allocation is expensive - reallocation with copying even more so. "will the running process be able to reclaim this memory automatically if needed?" Not in any environment I know of. – George Oct 03 '20 at 10:07
  • @George, yes i realise that, but the memory is dynamically and automatically allocated to a growing object... my own problem led me to ask (dupe of the above mentioned question) https://stackoverflow.com/q/64178849/11608725. i would like to know if i should manually go about "shrinking to fit" my objects once i know they will no longer grow / remain constant, or if i can rely on automatical reclaiming (not knowing if this would amount to automatic garbage collection or not...) – mrchance Oct 03 '20 at 10:11
  • 1
    Allocated memory won't be automatically reclaimed. It is possible though to implement garbage collection and have containers shrink based on that (But nothing standard). – George Oct 03 '20 at 10:15
  • @George, thanks, sounds reasonable and what i suspected. – mrchance Oct 03 '20 at 10:17
  • 1
    Also bear in kind that `shrink_to_fit()` does not *guarantee* that the capacity of the container will be reduced to be equal to its size. – Peter Oct 03 '20 at 12:46
  • @Peter, yes, thx. actually i since experimented heavily with this (mac os, xcode, clang) and never saw ANY shrinkage take place. – mrchance Oct 03 '20 at 13:27

1 Answers1

1

Lets consider what would be needed to implement something like that.

  • Some way to tell the process to release memory (rule them all)
    • Some signal and handler or event.
  • Some way to know which objects are to release memory (find them all, bring them all)
    • each register somewhere so they can be called by the signal or event
  • Some way to do it thread safe (and in darkness bind them)
    • an event will be nicely handled by all cooperating objects.
    • signal is a kind of interrupt, you would not want to go that way.

So you need a cooperating system, which is a problem if they don't really cooperate to release memory when the system wants it, either because they are busy, or have not implemented the needed code.

If you go to the other path, with signals/interrupts you are not sure if an object is currently updating its allocated memory and so would need to have some mutex, lock free operation of the like.

Surt
  • 15,501
  • 3
  • 23
  • 39