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

From: Thomas Maeder (maeder_at_[hidden])
Date: 2002-01-26 10:27:31

Am 2002.01.26 12:53 schrieb(en) Peter Dimov:
> > But in general, the success of fclose() should be checked. Can
> > shared_ptr be used then?
> 
> Should it?

Yes (in general). It's an operation that can fail. There are programs 
that have to behave differently if fclose() succeeds from when it fails.

> What would a program do when fclose fails?

This question can hardly be answered generally.

> shared_ptr's destructor has a nothrow guarantee.

Which makes perfect sense, of course.

> In any event, shared_ptr<FILE> is not a very good example.

It seems to me that destruction functions that can fail are all not 
very good examples.

> I'd define a separate file class (and the appropriate name for it is 
> std::file IMHO but that's another story.)

Or std::fstream.

The std::fstream destructor closes the file if it is open. Failure is 
ignored, which seems to be a meaningful compromise since the close() 
member function can (and should) be called (and checked for failure) 
during normal program execution; i.e. the destructor only closes the 
file during stack unwinding because of an exception.

This works fine if one object is the only owner of the file. I don't 
see how it can made to work with shared ownership.