Boost logo

Boost :

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at