Re: [boost] new version of smart pointer class templates

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2002-01-28 11:52:43

From: "Brey, Edward D" <EdwardDBrey_at_[hidden]>
> From: Peter Dimov [mailto:pdimov_at_[hidden]] 
> 
> Defining a shared_cfile is not that useful, though. The "deallocator" fclose
> is encoded in the type, but the "allocator" fopen is not. It would be easy
> to construct a shared_cfile that breaks when destroyed.
> 
> 
> [Ed Brey] 
> Avoiding that problem would rule out any shared_ptr with a constructor that
> accepts a raw pointer.  For example, in the MS COM world:
> 
> void fn(int* ptr) { // Takes ownership of ptr.
> shared_ptr<int> pi(ptr);
> }
> 
> Looks fine.  Compiles fine.  But your program crashes.  ptr was allocated
> with CoTaskMemAlloc, and deallocating it with operator delete is no good.
> Unless we go the route of bundling the allocator into the smart pointer, and
> accordingly using constructors that cover all parameter combinations, there
> is no way to guarantee matching allocator and deallocater.  The type of
> resource doesn't matter.

I see the raw pointer constructors as unfortunate from a safety point
of view, but necessary.  I hope that in most designs the construction
of shared_object is hidden in a factory function that returns a
shared_ptr, and that most code using shared_ptr does not need to use
raw pointers directly.

The above case is trickier, since CoTaskMemAlloced pointers are passed
around by so many COM interfaces.