Question

This is becoming a common pattern in my code, for when I need to manage an object that needs to be noncopyable because either A. it is “heavy” or B. it is an operating system resource, such as a critical section:

class Resource;

class Implementation : public boost::noncopyable
{
    friend class Resource;
    HANDLE someData;
    Implementation(HANDLE input) : someData(input) {};
    void SomeMethodThatActsOnHandle() {
        //Do stuff
    };
public:
    ~Implementation() { FreeHandle(someData) };
};

class Resource
{
    boost::shared_ptr<Implementation> impl;
public:
    Resource(int argA) explicit {
        HANDLE handle = 
            SomeLegacyCApiThatMakesSomething(argA);
        if (handle == INVALID_HANDLE_VALUE)
            throw SomeTypeOfException();
        impl.reset(new Implementation(handle));
    };
    void SomeMethodThatActsOnTheResource() {
        impl->SomeMethodThatActsOnTheHandle();
    };
};

This way, shared_ptr takes care of the reference counting headaches, allowing Resource to be copyable, even though the underlying handle should only be closed once all references to it are destroyed.

However, it seems like we could save the overhead of allocating shared_ptr’s reference counts and such separately if we could move that data inside Implementation somehow, like boost’s intrusive containers do.

If this is making the premature optimization hackles nag some people, I actually agree that I don’t need this for my current project. But I’m curious if it is possible.

Answer 1

A partial solution is to use make_shared to create your shared_ptrs. For example,

auto my_thing = std::make_shared<Thing>();

instead of

auto my_thing = std::shared_ptr<Thing>(new Thing);

It’s still non-intrusive, so nothing else needs to change. Good implementations of make_shared combine the memory allocation for the reference count and the object itself. That saves a memory allocation and keeps the count close to the object for better locality. It’s not quite as efficient as something like boost:intrusive_ptr, but it’s worth considering.