Question

I’ll open by saying I’ve been looking into this for a few days, trying to grok what is the “right way” of doing it. After plenty of googling on RAII/pool design/smart pointers, and having come to no definite conclusion (except that maybe there is no absolute “right way”), I thought maybe it’s time for someone more knowledgeable to point me in the right direction.

I’m building an object pool, and I’m trying to make sure the client code can use RAII, if desired.

There are 3 entities involved:

• Resource. Expensive to build, semi-cheap to reuse (checking its state on release is not trivial). Difficult to copy, as it wraps some C constructs, with their own allocated memory/resources.
• Wrapper/Handle. Wrapper for the Resource. Is given a Resource on ctor, releases it on dtor.
• Controller/Pool. Maintains a pool of Resources and manages their use by clients, via Wrapper or, at the client’s discretion, directly.

I present below a simplified example of what I’ve come up with. In the function DoSomethingElse(), you can see what I’m after – I get a reference to a Wrapper and, at the end of the scope, its dtor is invoked, and the Resource is released back to the pool.

My question has to do with the definition of Factory::GetResource(). The simplified version presented here just allocates a new one every time; my actual implementation checks the pool for an available Resource (creates one if there’s none available), marks it as in use, and returns a reference to it.

I’d rather avoid having to define a proper copy ctor for the Resource, hence the return by reference, instead of by value. The Resource is guaranteed to outlive the caller, and the Controller maintains ownership throughout the app’s life – they’re not handed to the client code for life-cycle management. Of course, if the client asks for a direct reference, i.e., without the Wrapper, all bets are off.

Is this design sound? Would I be better off using shared_ptr? Or some other mechanism/design?

Thanks for your time.

#include <iostream>
#include <vector>

using namespace std;

static int seq = 0; // POOR MAN'S SEQUENCE FOR INSTANCE IDs

class Resource
{
public:
    Resource() : id(seq++) { cout << "Resource ctor: " << id << endl; }
    ~Resource() { cout << "Resource dtor: " << id << endl; }
private:
    int id;
};

class Wrapper
{
public:
    // ON ACTUAL IMPLEMENTATION, NOTIFY THE CONTROLLER OF THE RELEASE
    ~Wrapper()
        { cout << "Wrapper dtor: " << id << "Welease Bwian! Ee, I mean, the wesouwce" << endl; }

    explicit Wrapper(Resource& r) : id(seq++), res(r)
      { cout << "Wrapper ctor: " << id << endl; }

    int getID() const { return id; }
private:
    int id;
    Resource& res;
};

class Controller
{
public:
    ~Controller() { for (auto r : allres) delete r; }
    Resource& GetResource();
private:
    // SIMPLIFIED. I'M USING Boost PTR CONTAINER
    vector<Resource *> allres;
};

// SIMPLIFIED. IT WOULD ACTUALLY GET A RESOURCE FROM THE POOL
Resource& Controller::GetResource()
{
    Resource* newres = new Resource();
    allres.push_back(newres);

    return *(newres);
}

// SIMULATE GLOBAL CONTEXT
Controller& GetController()
{
    static Controller f;
    return f;
}

void DoSomething(Wrapper& wr)
{
    cout << "DoSth INI" << endl;
    cout << wr.getID() << endl;
    cout << "DoSth END" << endl;
}

void DoSomethingElse()
{
    cout << "DoSthElse INI" << endl;
    Wrapper w(GetController().GetResource());
    DoSomething(w);
    cout << "DoSthElse END" << endl;
}

int main(int argc, char *argv[])
{
    cout << "main INI" << endl;
    cout << "Calling DoSthElse" << endl;
    DoSomethingElse();
    cout << "Called DoSthElse" << endl;
    cout << "main END" << endl;
}

Answer 1

RAII is really about ownership. Who owns the object, and what do they need to do once they relinquish ownership of it?

The situation you’re describing is that the resources are really owned by the Controller. The lifetimes of the resource objects are managed by the Controller.

Users of the resources effectively just “lock” the resource, marking it as “in use”, but they don’t take ownership of it. They don’t affect its lifetime. (You could say that they own a lock, and then that is the resource that they need to manage)

So I’d suggest exposing something like a std::unique_ptr<Resource>, which is created with a custom deleter. (and which can be returned by value from the controller.getResource() call

Users can do with this unique_ptr what they like: it’s not copyable, but it can be moved, and once it goes out of scope, it calls its custom deleter, which marks it as “unused” in the Controller, effectively returning it to the pool

That way you get to return an object by value, which is nice and simple to work with for the client, and you avoid exposing the “unwrapped” Resource objects at all: clients always get them wrapped in a unique_ptr, which eliminates a lot of potential errors.