{"id":1072,"date":"2013-06-22T01:00:00","date_gmt":"2013-06-21T23:00:00","guid":{"rendered":"https:\/\/www.fussylogic.co.uk\/blog\/?p=1072"},"modified":"2013-06-26T11:34:18","modified_gmt":"2013-06-26T10:34:18","slug":"copy-and-swap-idiom","status":"publish","type":"post","link":"https:\/\/www.fussylogic.co.uk\/blog\/?p=1072","title":{"rendered":"Copy and Swap Idiom"},"content":{"rendered":"

I learned a new trick today, while reading about C++11 (of which more to come). It\u00e2\u20ac\u2122s a technique I wish I\u00e2\u20ac\u2122d known about a long time ago, as it addresses an issue I\u00e2\u20ac\u2122ve always thought C++ had \u00e2\u20ac\u201c forcing you to duplicate code. That issue is addressed even more thoroughly with C++11, which has introduced the ability for one constructor to call another (about time on that one).<\/p>\n

The trick I learned is called the copy and swap idiom<\/em>; and I thought I\u00e2\u20ac\u2122d go through it bit by bit in case it\u00e2\u20ac\u2122s news to anyone else.<\/p>\n

So\u00e2\u20ac\u00a6 you\u00e2\u20ac\u2122re writing a C++ object to manage a resource. This is a fairly typical thing to do in C++, whether it be a file descriptor, a lock, a thread, a GUI object handle, or a chunk of memory. The resource has its own lifetime and is allocated, used and deallocated.<\/p>\n

To begin then we would always deal with allocation and deallocation. That means constructor(s) and destructor:<\/p>\n

    class T {\n      public:\n        T( size_t s ) :\n            mResource( s ? new uint8_t<\/span>[s] : nullptr )\n            mSize(s) {}\n        ~T() {\n            delete[] mResource;\n        }\n\n      private:\n        uint8_t<\/span> *mResource;\n        int<\/span> mSize;\n    };<\/code><\/pre>\n
Once we start using this resource though, we want to be able to copy it.<\/p>\n
    T obj1(100<\/span>);\n    T obj2(obj1);<\/code><\/pre>\n
Let\u00e2\u20ac\u2122s write a reasonable one:<\/p>\n
    class T {\n        \/\/ ...<\/span>\n        \/\/ Use C++11 facility for calling constructors<\/span>\n        T( const<\/span> T &O ) :\n            T(O.s)\n        {\n            \/\/ Use STL algorithm, copy(), to do the hard work<\/span>\n            copy(O.mResource, O.mResource + O.mSize, mResource);\n        }\n        \/\/ ...<\/span>\n    };<\/code><\/pre>\n
Once we have a copy constructor we\u00e2\u20ac\u2122ll also want an assignment operator. Before I learned the magic trick under discussion, here\u00e2\u20ac\u2122s the sort of code I might have written:<\/p>\n
    class T {\n        \/\/ ...<\/span>\n        T& operator=T( const<\/span> T &O )\n        {\n            if<\/span>( &O == this )\n                return<\/span> *this;\n            delete[] mResource;\n            mResource = new uint8_t<\/span>[O.mSize];\n            mSize = O.mSize;\n            return<\/span> *this;\n        }\n        \/\/ ...<\/span>\n    };<\/code><\/pre>\n
Hopefully you can see how unsatisfactory that is. We\u00e2\u20ac\u2122ve had to duplicate the destructor and constructor code inside the assignment operator. As the object becomes more complicated we\u00e2\u20ac\u2122ll have to maintain that connection \u00e2\u20ac\u201c every change to constructor or destructor has to be repeated. Yuck. I had thought that was just a C++ annoyance. Not so. Here\u00e2\u20ac\u2122s the copy-and-swap idiom:<\/p>\n
    class T {\n        \/\/ ...<\/span>\n        T& operator=T( T O )\n        {\n            swap(O);\n            return<\/span> *this;\n        }\n\n        void<\/span> swap( T &O )\n        {\n            \/\/ STL swap from the utility\/algorithm include<\/span>\n            using std::swap;\n            swap(mResource, O.mResource);\n            swap(mSize, O.mSize);\n        }\n        \/\/ ...<\/span>\n    };<\/code><\/pre>\n
The most important change is that the parameter to operator=()<\/code> is no longer a const<\/code> reference, it\u00e2\u20ac\u2122s a value. This would normally be have your C++ spidey-sense worrying about unnecessary copies. Remember though, in this case we are performing a necessary and requested copy<\/em>.<\/p>\n
    T a(100<\/span>);\n    T b(0<\/span>);\n\n    b = a;<\/code><\/pre>\n
What happens in the b = a<\/code> line now? The compiler sees that there is an operator=()<\/code> available, but it uses pass-by-value. It therefore effectively does this:<\/p>\n
    T a(100<\/span>);\n    T b(0<\/span>);\n\n    b.operator=(T(a));<\/code><\/pre>\n
In other words, it calls the copy constructor with a<\/code> to make a new temporary T<\/code>. This does a deep-copy before operator=()<\/code> even begins. Then operator=()<\/code> does one thing: swap()<\/code> to switch the resources owned by the temporary and the destination. That leaves us with a temporary, about to be deleted, pointing at b<\/code>\u00e2\u20ac\u2122s old resources and b<\/code> pointing at the copy-constructed from a<\/code> resources. Then operator=()<\/code> ends and the temporary goes out of scope, causing its destructor to free up b<\/code>\u00e2\u20ac\u2122s original resources.<\/p>\n
I think that\u00e2\u20ac\u2122s magical \u00e2\u20ac\u201c remember that the code duplication was of the destructor code to free up the original resources (now handled when the temporary goes out of scope using the destructor itself); and of the copy-constructor code to perform the deep-copy (now done automatically by the creation of the temporary using the copy-constructor itself). There is no need to check for self-assignment, since the temporary cannot be an alias for anything \u00e2\u20ac\u201c it\u00e2\u20ac\u2122s newly created. What\u00e2\u20ac\u2122s more there is not a pointer in sight.<\/p>\n
Things get even better when we introduce C++11\u00e2\u20ac\u2122s new move-semantics. Move semantics in C++11 are used to bypass unnecessary copy operations when the thing being copied from is a temporary. Consider this:<\/p>\n
    T b(T(50<\/span>));<\/code><\/pre>\n
b<\/code> is being assigned to as a copy of a temporary object. Before C++11, the compiler would call the constructor to make a temporary, then call b<\/code>\u00e2\u20ac\u2122s copy constructor to deep-copy that temporary to b<\/code>, then destruct the temporary. That\u00e2\u20ac\u2122s pretty wasteful; we had to pay for a copy we didn\u00e2\u20ac\u2122t want, and an allocation and destruction we didn\u00e2\u20ac\u2122t want. Plus we needed twice the memory we eventually used. (This isn\u00e2\u20ac\u2122t actually what happens, the compiler is allowed to use something called copy elision<\/em> in this case to avoid the copy, but there are other more complex cases where copy elision<\/em> isn\u00e2\u20ac\u2122t possible).<\/p>\n
C++11 lets us catch this case separately from normal copy construction. When the thing being copied from a temporary (C++11 calls them rvalues<\/em>), a different constructor will be looked for in preference to the copy-constructor \u00e2\u20ac\u201c the move-constructor:<\/p>\n
    class T {\n        \/\/ ...<\/span>\n        T( T &&O ) :\n            T(0<\/span>)\n        {\n            swap(O);\n        }\n        \/\/ ...<\/span>\n    };<\/code><\/pre>\n
The identifying feature is the double-ampersand and lack of const<\/code> on the argument, which means an rvalue reference<\/em>, and will match a temporary. The particular feature of the move constructor is that we are allowed to do whatever we like to the source object because we know it\u00e2\u20ac\u2122s not going to exist once the current C++ statement is complete (i.e.\u00c2\u00a0until the next semi-colon).<\/p>\n
We first construct the smallest possible valid object T(0)<\/code>, and then use the same copy-and-swap trick we did earlier to swap the resources of the rvalue<\/em> into the newly constructed object. That leaves the temporary resource pointing at the \u00e2\u20ac\u0153not-used\u00e2\u20ac\u009d state. When it destructs, it takes no resources with it, but we are left with the resources it did have.<\/p>\n
    T b(T(50<\/span>));<\/code><\/pre>\n
Now this line goes much faster. A temporary, T(50)<\/code> is constructed, b<\/code>\u00e2\u20ac\u2122s move<\/em> constructor is called with that temporary, which constructs a T(0)<\/code> and then swaps it for the temporary T(50)<\/code>. That leaves b<\/code> set up as a T(50)<\/code> and the temporary as a T(0)<\/code>, which is then destructed at negligible cost. b<\/code> is exactly what we want, and it cost us one full construction and one negligible construction; no deep-copy was needed and no extra memory was used.<\/p>\n
Key elements that make move-construction practical:<\/p>\n