It wouldn't be too difficult to write a custom deallocator for shared_ptr that supported release of ownership. Given the dangers I'd rather see it done that way than by adding a release() function to shared_ptr.
And I don't see a problem with adding constructors to scoped_ptr that support custom deallocation, especially since C++ has no 'finally' construct. At 04:36 AM 2/14/2003, Alisdair Meredith wrote: >Peter Dimov wrote: > >> > And what if you use the deallocator as a template parameter? > >> > Anyway: Do you know any smart-pointer class, which supports custom >> > deallocator and can transfer ownership? (auto_ptr does not support >> > custom deallocator and either smart_ptr or shared_ptr does not support >> > release() method). > >> Both good questions. Do we have an answer? > >These both sound like questions to be solved by the policy-pointer David >Held is formalising as we speak [based strongly on Andrei Alexandrescu's >smart_pointer class in the Loki library/Modern C++ Design book] > >I would be worried to see extra template parameters appearing in >shared_pointer, as the big advantage it overs over the full-blown policy >implemetation is its simplicity to the user. > >If that simplicity is no longer enough, then maybe you do need the full >policy implementation. I too worry a little about increasing the size >of my pointers with an unused deallocator, but nothing in my profiling >has suggested this is a real problem in practice, simply an >implementation detail I am concerned about because I know it is there. >This is one of the trade-offs of trying to use a general-purpose >library. > >Well, that's my take on it anyway <g> > >-- >AlisdairM > >_______________________________________________ >Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
