This article briefly describes a simple little extension of the pimpl idiom that I’ve called “pimplcow”. It’s not a unique idiom, I know at least one other developer/group that has done the same thing. I invented it independently though and at least for a while thought it uniquely mine. Perhaps I can lay claim to the name :p

The basic gist of the idiom can be shown with shared_ptr:

struct object { int get() const; void set(int); object(); object(object const&); object& operator = (object); private: struct impl; std::shared_ptr<impl> pimpl_; impl * pimpl(); impl const* pimpl() const; };

The declaration of the class isn’t really anything new or interesting except perhaps for the pimpl function and the shared_ptr. The pimpl() function is actually useful outside of this idiom as it allows you to easily copy the constness of your object into the constness of your impl, which generally should match but pointers in C++ change things a bit. The implementation though is where things get a touch interesting:

struct object::impl { int i; }; object::object() : pimpl_(new impl()) {} // or make_shared object::object(object const& other) : pimpl_(other.pimpl_) {} // shallow copy! object & object::operator = (object other) { pimpl_.swap(other.pimpl_); } int object::get() const { return pimpl()->i; } void object::set(int i) { pimpl()->i = i; } // Now for the tricky parts... // For const operations we just return the pimpl we have. object::impl const* object::pimpl() const { return pimpl_.get(); } // For non-const operation we assume the object is about to be modified and we now copy the pimpl...maybe. object::impl * object::pimpl() { if (!pimpl_.unique()) pimpl_.reset(new impl(*pimpl_)); return pimpl_.get(); }

This now implements the copy-on-write optimization in a VERY easy way. In fact, if you write your pimpl based classes in a sort of simple to follow standard way you end up having to change only two functions to switch between pimplcow and simple pimpl:

object::object(object const& other) : pimpl_(new impl(*other.pimpl_)) {} object::impl * object::pimpl() { return pimpl_.get(); }

A further optimization recognizes that `shared_ptr` is actually a rather heavy-weight object when you know for certain you’re using shared pointer semantics, such as in the case of pimplcow. So instead you use an invasive reference count pointer such as `boost::intrusive_ptr`.

This construct is really simple and can save a lot of memory in some situations. It can also greatly reduce CPU use if your objects would otherwise be copied a lot but not changed. Yet further you can use value semantics instead of shared pointers to optimize against copying. It’s much, MUCH simpler to think about and use value types than shared pointers when the only thing you’re trying to do is avoid copies. Finally, in these conditions you must already be paying the cost of atomic increment/decrement in the reference count, which is the one thing you need to worry about here.

To close a bit about the reference count. You need to be weary of and measure the effect of atomic operations needed to increment and decrement the reference count for the shared pointer. If you’re making huge numbers of copies and/or destroying many values when you’ve not called a non-const member and thus doing the real copy, you can end up with a LOT of contention between CPUs. The pimplcow idiom is thread safe if you use a thread-safe reference counter, but in some cases it may actually be cheaper to make a real copy than to defer that copying and use a reference count. You’ll also want to avoid taking your parameters by value when you don’t need to because this will inject this atomic (or mutex lock) protected reference count manipulation, and that can indeed be a heavy cost in some cases.

Final close note: You can use this same sort of pattern to implement a flyweight quite easily. Use the usual pimplcow versions of copy and pimpl(), but additionally do a search into a flyweight manager to find an existing identity for the pimpl after you modify it. I have implemented both of these idioms in a sort of pimpl framework library in my github experiments repository: https://github.com/crazy-eddie/experiments/tree/master/performance – I make no claim that this experiments repository will be in a useable state when/if you chose to clone it. In fact I know right now that the pimplvector stuff is completely broken.

Final, final note: This idiom/pattern is indeed thread safe, but only if values are not shared among threads. So long as each thread has its own “copy” of the value you need not worry about any race conditions. This makes the idiom easy to implement and use. If you on the other hand need to share single copies of a value in multiple threads then you need to add further syncronozitation. This is not really unusual and so I don’t consider it a flaw, but you do need to be aware of it because of course bad things will happen if you use it incorrectly and cause a race condition.

Like this: Like Loading... Related