Re: [boost] Re: smart_ptr vs smart_resource

From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2003-02-26 15:58:09

>From: "Phil Nash" <phil.nash.lists_at_[hidden]>

> [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.

I'm not sure what you mean, here. In the above example, the destructor takes
care of the release. Also, as it only manages _one_ resource (the lock), it
is exception safe (vertex_buffer (which inherits from vertex_buffer_base) is
just a wrapper class for D3D's VertexBuffer interface). Speaking of that, I
also have a COM smart pointer class there. That could definitely make use of
a smart pointer/resource manager, as it could then make use of the pointer
semantics, etc.

Even as a policy, you'd still have to make sure that your acquire/release
functions are exception safe, just like the constructor/destructor above. So
I don't see how a resource_manager class would add anything in this respect.

> 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).

Which reminds me, the class above actually was defined as:

class vertex_buffer_lock : private boost::noncopyable

Yes, if you could make the copying/ownership policy independent of what is
owned, for example by making it call acquire/release functions on another
policy, which implements the code in the constructor/destructor above.

> > 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.

Come to think of it, it may not be a problem, after all. Consider this
simple test program:

class test
{
public:
  test(int &) {}
};

template<class T>
class resource_manager
{
public:
  resource_manager() : resource() {}

  template<class T1>
  resource_manager(T1 &t1) : resource(t1) {}

private:
  T resource;
};

int main()
{
int i=1;

resource_manager<test> testA(i);

int &ir=i;

resource_manager<test> testB(ir);
}

This compiles and runs without any problems.

> > 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.

Yes, I know there's a lot of use cases. My emphasis was on _implementing_
them. :) That way, one get to see if they may be handled uniformly by such a
framework.

> 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).

It would definitely be interesting in looking into this. I'm not saying it
won't be useful. What I'm saying is "show me". :)

> Thanks for your comments Terje,

You too. :)

Regards,

Terje