Boost logo

Boost :

From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2003-02-26 05:49:18

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

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

Looking at my own code, to find such use, I've found a few places, such as
the following:

// Direct3D

class vertex_buffer_lock
  vertex_buffer_lock(vertex_buffer_base &vb,vertex *&vertices,const uint
num_vertices,const uint flags =0) :


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



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