Hi, On Thu, 2008-01-31 at 09:36 +0100, Marcus Lindblom wrote: > Dirk Reiners wrote: > > Hi All, > > > > Carsten Neumann wrote: > > >>>>> Concepts > >>>>> > >>>>> - RefPtr should never auto convert from/to normal pointers > >>>>> - this is similar to boost > >>>>> - this should remove the transit ptr. > >>>>> - basically make the transitptr the refptr > >>>> this is tightly related to the argument/return type used for functions, > >>>> see below. > >>> this is one of my problems, a lot of comments, including the boost > >>> shared_ptr FAQ, say auto conversion on this kind of pointer class is > >>> not really a brilliant idea. > >>> > >>>> >From the boost FAQ > >>> 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. kind regards, gerrit ------------------------------------------------------------------------- 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
