I have been thinking about sending an e-mail about ptr/memory safety for a while, but I have just been bit by a bug that made me think that now may be the right time.
As it stands right now users have to keep track of memory management on their own. They have to understand how Ptr's sub/add ref works and understand the side-effects of various calls. In my opinion this makes the API more difficult to use then it has to be. When it comes to non-FC APIs the system currently uses standard C ptrs which the user can understand but we could make it easier on them. In a modern software development world where many APIs make use of smart pointer and garbage collection this seems like a wart on the OpenSG interface that could be corrected easily to make OpenSG a little more friendly and the code created more stable and bug free. I propose that we use boost::shared_ptrs and OSG::RefPtr's to make the user-level API's of OpenSG 2.0 safer to use. More specifically I suggest that we: - Make create for non-fc types return boost::shared_ptr<>'s and that we traffic in these ptrs in the user API. - Merge the capabilities of RefPtr into whatever FCPtr class becomes the final standard - All user-level APIs would return and take smart pointer style arguments that would automatically handle memory management This change would be extensive, but once it is done I think the system would be much better off for it. So, let's talk about reasons that it can't or shouldn't be done and how we can work around them. - Performance: We don't want to give up performance. During traversals and other highly recursive calls, fcptr's will be passed as arguments many times. We don't want each of these times to require a add/sub ref because those calls are expensive. A solution to this problem would be to allow the internal APIs to pass around cptr's to maintain high-performance. I haven't looked at the code yet so can someone else tell me if this would work? - Cycles: There may be places in the code where we need back references. Boost solves this by using a weak_ptr. Weak_ptrs are factory objects that can create shared_ptr's but will return a Null ptr if the object it points to has been destroyed (no shared_ptrs still holding it). We could probably create a similar ptr type WeakRefPtr to work for the RefPtr types. We could base the implementation off of the implementation that boost uses for shared_ptr and weak_ptr. Comments, concerns, flames? :) -Allen PS. If anyone is interested in the bug I ran into, see what happens if you have an application that does all its memory management using RefPtrs and passes some temporaries to SimpleSceneManager. Random seg faults are great fun. :) ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Opensg-core mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-core
