Le 2011-12-11 à 14:27:00, Ivica Ico Bukvic a écrit :
The OS releases all the memory allocated by the process when it terminates, so no.
OK, however, in pd-l2ork I am currently building infinite undo which will be a doubly-linked list linked to a canvas. So, if I am going to instantiate it dynamically, once the program exits are all these dynamic things taken care of? I think not. Otherwise, why would we need destructors in the first place if the os takes care of it all (other than eventually running out of memory)? Even vanilla canvas has dynamically allocated list that is destructed upon closing the patch but this is not the case with the two invisible canvases...
Memory allocation using getbytes(), malloc(), operator new or [NSObject alloc], are all the same : they work within the framework of sbrk(), mmap() and such things. For small amounts, malloc organises the memory given by sbrk() as a big data structure, in which pointers say where are the parts in use, the parts not in use, how big they are, and how new space can be found efficiently. For big amounts malloc just delegates to mmap(). In either case, those sbrk() and mmap() allocations are registered in a table in the kernel, and when the kernel deletes the sbrk and mmap regions, you don't need to do free() anymore.
The problem with destructors, is that they may do things other than freeing memory directly or indirectly... for example, if an object creates an empty file named «my_database.busy» to mean that the database should not be opened by anyone else, then this file has to be deleted when the object is deleted.
It's possible to reserve RAM that the OS won't free automatically, but the means to do so are a bit unusual and limited. For example, shmget() offers certain ways of creating leak bugs that have to be fixed by rebooting, but there's a shmctl() option for auto-release which is usually used just after.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC