Boost logo

Boost :

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
> > 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
> > constructors/destructors.
> Yes.. it's ctors and dtors that have really brought the RAII idiom into
> language - and of course is very important in the resource_manager
> Now, to your example:
> > Looking at my own code, to find such use, I've found a few places, such
> > 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
> > 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 -
> I wonder if a resource_manager framework would still make getting them
> easier... (I'd need to give that more thought). One advantage would be
> 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
> 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
  test(int &) {}

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

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

  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
> > meet the road. :)
> Yes.. some examples have already been given, including managing file
> (although in practice we already have an RAII file object in the form of
> fstream), mutex locks (which saw the resurrection of this thread
> 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

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



Boost list run by bdawes at, gregod at, cpdaniel at, john at