Boost logo

Boost :

From: Brey, Edward D (EdwardDBrey_at_[hidden])
Date: 2002-01-28 09:05:04


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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk