Gerrit Voss wrote: > Hi, > > On Thu, 2008-01-31 at 09:36 +0100, Marcus Lindblom wrote: >> Dirk Reiners wrote: >> >>>>> Q. Why doesn't shared_ptr (or any of the other Boost smart pointers) >>>>> supply an automatic conversion to T*? >>>>> >>>>> A. Automatic conversion is believed to be too error prone. >>>> it is sad that the boost folks have settled for such a weak answer to >>>> this question, not even giving pointers to any discussions :( >>>> I would have very much like to see the arguments that have led to that >>>> decision (I just read up on this in A. Alexandrescu "Modern C++ Design", >>>> Sect. 7.7, he does not seem to be that unequivocal about the issue). >> My 0.02€: >> >> It think shared_ptr doesn't allow automatic conversion since it wraps >> something _that does not know it is refence counted_. >> >> If the reference count is internal to the object, it is easy to verify >> correct destruction within the object (assert(refs==0)) and there is >> much less dangers of converting to/from smart pointers, since the ref >> count is preserved across these conversions. >> >> I think the boost-policy is good for a non-intrusive utility, but >> something that uses a framework (ala OpenSG) can be more relaxed, since >> it has tighter control over the handled objects. > > ok, that makes sense, given that the destructors are protected nobody > except the ref counters can destroy the object. > > If we can make the refcounting itself protected it should be quite > safe.
That shouldn't be a problem? Also, using refptrs internally, making it work properly and finally assert in inc/dec count that the count is zero or higher ought to encourage & enforce proper use. That way, people can't use subref, manually, because it makes their applications crash. :) I think it also means that we have to say "don't do that" to users wanting to destroy things, and stop suggesting loops on subRef() to destroy objects. Everyone should know about garbage collection nowadays and learn to work with it rather than against it. Cheers, /Marcus ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Opensg-core mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-core
