>From: "Phil Nash" <[EMAIL PROTECTED]> > [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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost