Re: [boost] beating the shared_ptr<FILE> straw man

From: Darin Adler (darin_at_[hidden])
Date: 2002-01-26 14:15:34

>>> What would a program do when fclose fails?
>> 
>> This question can hardly be answered generally.
> 
> Indeed. I guess as a user I'd like to see the app dsplaying an appropriate
> message at least to warn me that something bad might have happen.

Anyone designing a C++ object that represents file I/O needs to deal with
this issue. The destructor must not trigger a final flush of a buffer with
potentially-failing I/O, because there's no way to report this to the
caller. I believe that basic_fstream discards errors that happen at this
late date and shifts the burden onto the client to both flush and check for
errors explicitly. This is exactly how a shared_ptr<FILE> would behave if it
ignored the fclose return value, hence it would be no worse than fstream!

On the other hand, the example of shared_ptr<FILE> was not the best one,
because this issue of final bits of I/O at FILE close time is peripheral to
the shared_ptr feature. So we should probably stop beating that particular
straw man.

On the other hand, there are many other cases where this feature of
shared_ptr may come in handy, with various kinds of pointers not created
with new. These mostly come up when working with existing C APIs.

To give just a few Mac OS examples, there are pointers to objects that need
to be destroyed with calls to DisposeHandle, ReleaseResource,
AEDisposeToken, ATSUDisposeStyle, ATSUDisposeMemorySetting,
ATSUDisposeTextLayout, CWDisposeColorWorld, CMDisposeProfileSearch,
DCMDisposeRecordIterator, DCMDisposeObjectIterator, PMDisposePageFormat,
PMDisposePrintSettings, DisposePictInfo, DisposeGWorld, DisposeScreenBuffer,
DisposeRgn, DisposeSpeechChannel, and hundreds of "UPPs" which each must be
released with a specific dispose call.

For some uses of these, the shared_ptr/weak_ptr framework may be just what
the doctor ordered, although there might need to be some liberal use of
.get() when calling the underlying Mac OS routines that manipulate these
types.

    -- Darin