Re: [boost] Re: smart_ptr vs smart_resource

From: Phil Nash (phil.nash.lists_at_[hidden])
Date: 2003-02-26 07:57:32

[Terje Slettebø]
> I also think this makes sense. However, I'm wondering how much commonality
> there is in such a broader concept. This is kind of making a library
> implementation of the RAII idiom, and we have that already, in the form of
> constructors/destructors.

Yes.. it's ctors and dtors that have really brought the RAII idiom into the
language - and of course is very important in the resource_manager concept.
Now, to your example:

> Looking at my own code, to find such use, I've found a few places, such as
> the following:
>
> // Direct3D
>
> class vertex_buffer_lock
> {
> public:
>   vertex_buffer_lock(vertex_buffer_base &vb,vertex *&vertices,const uint
> num_vertices,const uint flags =0) :
>     vertex_buffer(vb)
>   {
>     vertex_buffer.lock(vertices,num_vertices,flags);
>   }
>
>  ~vertex_buffer_lock()
>   {
>     vertex_buffer.unlock();
>   }
>
> private:
>   vertex_buffer_base &vertex_buffer;
> };
>
> Would a resource_manager provide anything additional, here? I'd still need
> to write a policy which would be really the same as the above. Also, how
> would a resource_manager handle all the different constructors?

Well, as you so rightly point out, full RAII wrappers for such resources
would require you to write most, if not all, of the code yourself - although
I wonder if a resource_manager framework would still make getting them right
easier... (I'd need to give that more thought). One advantage would be that
the release mechanism would be independant of any other aspects of the
wrapper - and so could be ensured to be more robust in the face of
exceptions without you having to worry about it directly. On a related note
the various copying policies would be taken care of for you. If you want to
make your resource copyable, or shareable or COWable or whatever - it just
takes a change of policy to give you the feature (if appropriate). The more
I think about it the more I think it makes sense even in a full wrapped
solution!

However I think the general expectation is that resource_manager would model
RAII very similarly to smart_ptr. IE the resource would, in truth, be
acquired *outside* of the resource_manager (in the same way that you
normally construct an object outside a smart pointer). This waters down the
pure concept of RAII a little, but I'm not sure how meaningful it is to
quibble over the distinction here. Anyway you can imagine supplying a
construction policy that will do this internally, but I don't see that it
really gains you anything, but does make it more complex.

For releasing the resource a "releaser" functor would be supplied with the
constructor, to be called by the destructor.
If this all sounds familiar, that's because, yes, presently smart_ptr
supports these very features! So why the need for a separate concept? Simply
because using smart_ptr to manage non-pointer resources is counter-intuitive
and confusing (unless you have grown up with this idiom).

> Also, if you use "T &" for the
> constructor arguments, you risk getting reference to reference problems.

I believe this can be fixed with type_traits.

> In short, I think it could be good to find a few use-cases, such as the
> above, and try to implement it using a generic resource_manager. That
would
> show if the concept adds anything, or not. In other words, let the rubber
> meet the road. :)

Yes.. some examples have already been given, including managing file handles
(although in practice we already have an RAII file object in the form of
fstream), mutex locks (which saw the resurrection of this thread recently),
and all sorts of OS handles and other resources that are usually presented
as a C interface. Of course there are usually RAII wrappers already written
for these things, but often they are part of a framework that you don't
necessarily want to use - or the framework may not cover the particular
resource you need - or the classes available do more than just RAII
management and you just want to deal with the raw resource the rest of the
time....

Several times now I have had to write my own wrappers for the MS Inet HTTP
interface, purely to provide the RAII management of them. Each time I have
thought, "I really should write that general resource manager code". And
really I should - even though it probably wouldn't be the implementation
that was accepted into boost (if ever).

Thanks for your comments Terje,

[)o
IhIL..