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.