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...
On Sun, 2011-12-11 at 14:27 -0500, Ivica Ico Bukvic wrote:
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...
By dynamic list in vanilla canvas I am referring here to the glist (a list of objects).
On 12/11/2011 08:27 PM, Ivica Ico Bukvic wrote:
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.
it does. if it does not, file a bug report at your operating system.
Otherwise, why would we need destructors in the first place if the os takes care of it all (other
because destructors are not only called at the end of the application life.
afaik, the only problem is, if your application locks some "shared" system ressource, and cannot free it again (e.g. it writes a lockfile to the filesystem, but cannot delete it if the dtor is not called on exit)
fgamsdr IOhannes
it does. if it does not, file a bug report at your operating system.
I stand corrected. So, the next question is, is it considered "good coding practice" to explicitly call destructors, or is this one of those quod libet kinds of things?
Otherwise, why would we need destructors in the first place if the os takes care of it all (other
because destructors are not only called at the end of the application life.
afaik, the only problem is, if your application locks some "shared" system ressource, and cannot free it again (e.g. it writes a lockfile to the filesystem, but cannot delete it if the dtor is not called on exit)
fgamsdr IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-12-11 21:22, Ivica Ico Bukvic wrote:
I stand corrected. So, the next question is, is it considered "good coding practice" to explicitly call destructors, or is this one of those quod libet kinds of things?
"explicitely calling destructors" is a bit vague in this context. you question should rather be termed: "is it considered 'good practice' to explicitely call destructors on exit".
anyhow, i believe "good practice" depends on a number of factors; so you cannot simply say that using CamelCase is good practice whereas using hungarian notation is bad practice.
personally, i prefer if the program does call dtors on exit, since there are a number of ressources that cannot be automatically freed by the operating system due to their very nature. if your Pd-patch controls the facilities in your flat, you might want it to shut off the light if the patch is powered down in order to save energy. the operating system most likely will not send the appropriate commands to your arduino....
fgmasdr IOhannes
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
-
IOhannes m zmoelnig -
IOhannes zmölnig
-
Ivica Ico Bukvic -
Mathieu Bouchard