[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.. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost