>From: "Phil Nash" <[EMAIL PROTECTED]> > [Rob Stewart] > > There can still be a smart_ptr class, even if there's a > > smart_resource class. Both may be separate manifestations, > > possibly sharing some implementation details, of a SmartResource > > concept. Equally plausible, smart_ptr could be implemented in > > terms of smart_resource somehow (derivation, aggregation, > > whatever). > > In the Policy Based case smart_ptr would just be smart_resource (or > resource_manager) with certain policies (or policy sets). Template typedefs > would help a lot here.
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. 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? Perhaps using overloaded, templated constructors. That wouldn't cater for default arguments, like the above, though. Also, if you use "T &" for the constructor arguments, you risk getting reference to reference 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. :) Regards, Terje _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost