Pulled this our of the Array as FIFO stack thread as it was such an interesting tip and I only noticed it in passing.
On 12/04/2007, at 10:00 AM, Guyren Howe wrote: > Oh, and note this: you can implement the reuse thing by having the > objects put themselves into a pool array in their destructor. By > doing that, there is a reference to them again, and they won't get > reclaimed. I recently checked this with Mars, and he said that this > would work just fine. That implies some very interesting things about the destructor and memory cleanup in RB vs other languages. A destructor in C++, Python, Java et al is a method called on your object when the object is being deleted, to allow it to do an intelligent cleanup rather than relying on the compiler to cleanup member variables automatically. It is called as part of a memory management process and can't cancel the deletion. This feedback from Mars suggests that the refcount is checked again AFTER the destructor is called, before actual object memory deallocation occurs. Given this is contrary to the way most languages work I'd want to see this as a documented, guaranteed part of RB behaviour before relying on it long-term. It feels very much like a side-effect of the current implementation and so possibly something that could go away. Due to its subtlety this is the kind of thing that should have a regression test ;-) Note that in C++ the ability to have operator overloading and stack- based objects means people often have their own reference-counting pointers, like RB objects, which can implement such pools. Andy Dent BSc MACS http://www.oofile.com.au/ OOFILE - Database, Reports, Graphs, GUI for c++ on multiple platforms REALbasic, C++, Python, Mac and Windows development and porting _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html>
