RE: [boost] shared_ptr_updates.zip

From: Philip Nash (philip.nash_at_[hidden])
Date: 2001-07-25 15:18:19

I suggested in a branch from the earlier thread that maybe the "finalizer"
function, as you put it, would best be served by a separate class (or set of
classes - one for shared one for basic scoped) that are tailored for true
"initialisation is resource aquisition" needs.
This could also contain non pointer types.
My proposal is for:
        shared_resource<T> and
        scoped_resource<T>.

The constructors would take two arguments: an opaque handle of type T (not
T*) and a finalizer function, which is a function, or functor, that takes
one argument of type T and may or may not return (return value is ignored)
(functions which take more arguments could be supported by functor binders).

It would also need a policy for how to handle uninitialised resources (in
the case of the FILE example, and probably partialy specialised by default
for all pointer types, it would, by default, test against NULL and could,
for example, throw an exception).
Throwing an exception for invalid FILEs returned from fopen would solve your
problem with fclose crashing because the destructor would not be called.

I think this solution more neatly diverges true pointer-to-object semantics
from initialisation-is-resource-aquisition semantics, rather than trying to
overload the existing classes with too much orthagonal functionality.

What do you think?

I could come up with an example implementation to get the ball rolling (when
I have some more time a bit later), but I think what I have said above
captures most of it. I have not fully thought through the implications and
side-effects yet, so any comments are welcome.

[)o
IhIL..

> -----Original Message-----
> From: Peter Dimov [mailto:pdimov_at_[hidden]]
> Sent: 25 July 2001 21:55
> To: boost_at_[hidden]
> Subject: [boost] shared_ptr_updates.zip
>
>
> shared_ptr_updates.zip in the smart_ptr folder contains an updated
> shared_ptr that accepts a 'finalizer' function as a second argument.
> Unfortunately
>
> shared_ptr<FILE> file_ptr(fopen(file_name,file_mode),fclose);
>
> is not a very good example of its functionality because fclose()
> will crash
> when called with a NULL argument. :-)
>
> This version is a bit more taxing so I don't know what the regression test
> will say about it. The tests work on my compilers.
>
> --
> Peter Dimov
> Multi Media Ltd.
>
>
> Info: http://www.boost.org  Unsubscribe:
> <mailto:boost-unsubscribe_at_[hidden]>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>