On 5/3/22 07:57, Alain De Vos wrote:
> But at the same time be able to be sure memory is given free when a
> variable is going out of scope.
Let's expand on that please. What exactly is the worry there? Are you
concerned that the program will have memory leaks, and eventually got
killed by the OS?
Do you want memory to be freed all the way to the OS? Would it be
possible that a call to some_library_free() puts that memory in a free
list to be used for later allocations? Or do you insist that memory
really goes back to the OS?
Why are you worried about how memory is managed?
The way I think is this: When I use some feature and that feature
allocates memory, it is not up to me to free memory at all. I don't want
to get involved in how that memory is managed.
On the other hand, if I were the party that did allocate memory, fine,
then I might be involved in freeing.
Note that 'new' is not raw memory allocation. So it should not involve
raw memory freeing.
Sorry for all the questions but I am really curious why. At the same
time, I have a suspicion: You come from a language like C++ that thinks
deterministic memory freeing is the only way to go. It took me many
years to learn that C++'s insintence on that topic is wrong.
Memory can be freed altogether at some later time. Further, not every
object needs to be destroyed. These are based on one of John Lakos's
C++Now presentations where he shows comparisons of different destruction
and freeing schemes where (paraphrasing) "no destruction whatsoever;
poof the array disappears." Not surprisingly, that happens to be the
fastest destruction plus free.
Ali
