What is the copy-and-swap idiom?

Question

What is the copy-and-swap idiom and when should it be used? What problems does it solve? Does it change for C++11?

Related:

• What are your favorite C++ Coding Style idioms: Copy-swap
• Copy constructor and = operator overload in C++: is a common function possible?
• What is copy elision and how it optimizes copy-and-swap idiom
• C++: dynamically allocating an array of objects?

Phonology

gotw.ca/gotw/059.htm from Herb Sutter – Guru

Awesome, I linked this question from my answer to move semantics. – Albanian

Warning: The copy/swap idiom is used far more frequently than it is useful. It is often harmful to performance when a strong exception safety guarantee is not needed from copy assignment. And when strong exception safety is needed for copy assignment, it is easily provided by a short generic function, in addition to a much faster copy assignment operator. See slideshare.net/ripplelabs/howard-hinnant-accu2014 slides 43 - 53. Summary: copy/swap is a useful tool in the toolbox. But it has been over-marketed and subsequently has often been abused. – Stamm

Answer 1

Overview

Why do we need the copy-and-swap idiom?

Any class that manages a resource (a wrapper, like a smart pointer) needs to implement The Big Three. While the goals and implementation of the copy-constructor and destructor are straightforward, the copy-assignment operator is arguably the most nuanced and difficult. How should it be done? What pitfalls need to be avoided?

The copy-and-swap idiom is the solution, and elegantly assists the assignment operator in achieving two things: avoiding code duplication, and providing a strong exception guarantee.

How does it work?

Conceptually, it works by using the copy-constructor's functionality to create a local copy of the data, then takes the copied data with a swap function, swapping the old data with the new data. The temporary copy then destructs, taking the old data with it. We are left with a copy of the new data.

In order to use the copy-and-swap idiom, we need three things: a working copy-constructor, a working destructor (both are the basis of any wrapper, so should be complete anyway), and a swap function.

A swap function is a non-throwing function that swaps two objects of a class, member for member. We might be tempted to use std::swap instead of providing our own, but this would be impossible; std::swap uses the copy-constructor and copy-assignment operator within its implementation, and we'd ultimately be trying to define the assignment operator in terms of itself!

(Not only that, but unqualified calls to swap will use our custom swap operator, skipping over the unnecessary construction and destruction of our class that std::swap would entail.)

---

An in-depth explanation

The goal

Let's consider a concrete case. We want to manage, in an otherwise useless class, a dynamic array. We start with a working constructor, copy-constructor, and destructor:

#include <algorithm> // std::copy
#include <cstddef> // std::size_t

class dumb_array
{
public:
    // (default) constructor
    dumb_array(std::size_t size = 0)
        : mSize(size),
          mArray(mSize ? new int[mSize]() : nullptr)
    {
    }

    // copy-constructor
    dumb_array(const dumb_array& other)
        : mSize(other.mSize),
          mArray(mSize ? new int[mSize] : nullptr)
    {
        // note that this is non-throwing, because of the data
        // types being used; more attention to detail with regards
        // to exceptions must be given in a more general case, however
        std::copy(other.mArray, other.mArray + mSize, mArray);
    }

    // destructor
    ~dumb_array()
    {
        delete [] mArray;
    }

private:
    std::size_t mSize;
    int* mArray;
};

This class almost manages the array successfully, but it needs operator= to work correctly.

A failed solution

Here's how a naive implementation might look:

// the hard part
dumb_array& operator=(const dumb_array& other)
{
    if (this != &other) // (1)
    {
        // get rid of the old data...
        delete [] mArray; // (2)
        mArray = nullptr; // (2) *(see footnote for rationale)

        // ...and put in the new
        mSize = other.mSize; // (3)
        mArray = mSize ? new int[mSize] : nullptr; // (3)
        std::copy(other.mArray, other.mArray + mSize, mArray); // (3)
    }

    return *this;
}

And we say we're finished; this now manages an array, without leaks. However, it suffers from three problems, marked sequentially in the code as (n).

1. The first is the self-assignment test.
   This check serves two purposes: it's an easy way to prevent us from running needless code on self-assignment, and it protects us from subtle bugs (such as deleting the array only to try and copy it). But in all other cases it merely serves to slow the program down, and act as noise in the code; self-assignment rarely occurs, so most of the time this check is a waste.
   It would be better if the operator could work properly without it.

2. The second is that it only provides a basic exception guarantee. If new int[mSize] fails, *this will have been modified. (Namely, the size is wrong and the data is gone!)
   For a strong exception guarantee, it would need to be something akin to:

    dumb_array& operator=(const dumb_array& other)
    {
        if (this != &other) // (1)
        {
            // get the new data ready before we replace the old
            std::size_t newSize = other.mSize;
            int* newArray = newSize ? new int[newSize]() : nullptr; // (3)
            std::copy(other.mArray, other.mArray + newSize, newArray); // (3)
   
            // replace the old data (all are non-throwing)
            delete [] mArray;
            mSize = newSize;
            mArray = newArray;
        }
   
        return *this;
    }
   

3. The code has expanded! Which leads us to the third problem: code duplication.

Our assignment operator effectively duplicates all the code we've already written elsewhere, and that's a terrible thing.

In our case, the core of it is only two lines (the allocation and the copy), but with more complex resources this code bloat can be quite a hassle. We should strive to never repeat ourselves.

(One might wonder: if this much code is needed to manage one resource correctly, what if my class manages more than one?
While this may seem to be a valid concern, and indeed it requires non-trivial try/catch clauses, this is a non-issue.
That's because a class should manage one resource only!)

A successful solution

As mentioned, the copy-and-swap idiom will fix all these issues. But right now, we have all the requirements except one: a swap function. While The Rule of Three successfully entails the existence of our copy-constructor, assignment operator, and destructor, it should really be called "The Big Three and A Half": any time your class manages a resource it also makes sense to provide a swap function.

We need to add swap functionality to our class, and we do that as follows†:

class dumb_array
{
public:
    // ...

    friend void swap(dumb_array& first, dumb_array& second) // nothrow
    {
        // enable ADL (not necessary in our case, but good practice)
        using std::swap;

        // by swapping the members of two objects,
        // the two objects are effectively swapped
        swap(first.mSize, second.mSize);
        swap(first.mArray, second.mArray);
    }

    // ...
};

(Here is the explanation why public friend swap.) Now not only can we swap our dumb_array's, but swaps in general can be more efficient; it merely swaps pointers and sizes, rather than allocating and copying entire arrays. Aside from this bonus in functionality and efficiency, we are now ready to implement the copy-and-swap idiom.

Without further ado, our assignment operator is:

dumb_array& operator=(dumb_array other) // (1)
{
    swap(*this, other); // (2)

    return *this;
}

And that's it! With one fell swoop, all three problems are elegantly tackled at once.

Why does it work?

We first notice an important choice: the parameter argument is taken by-value. While one could just as easily do the following (and indeed, many naive implementations of the idiom do):

dumb_array& operator=(const dumb_array& other)
{
    dumb_array temp(other);
    swap(*this, temp);

    return *this;
}

We lose an important optimization opportunity. Not only that, but this choice is critical in C++11, which is discussed later. (On a general note, a remarkably useful guideline is as follows: if you're going to make a copy of something in a function, let the compiler do it in the parameter list.‡)

Either way, this method of obtaining our resource is the key to eliminating code duplication: we get to use the code from the copy-constructor to make the copy, and never need to repeat any bit of it. Now that the copy is made, we are ready to swap.

Observe that upon entering the function that all the new data is already allocated, copied, and ready to be used. This is what gives us a strong exception guarantee for free: we won't even enter the function if construction of the copy fails, and it's therefore not possible to alter the state of *this. (What we did manually before for a strong exception guarantee, the compiler is doing for us now; how kind.)

At this point we are home-free, because swap is non-throwing. We swap our current data with the copied data, safely altering our state, and the old data gets put into the temporary. The old data is then released when the function returns. (Where upon the parameter's scope ends and its destructor is called.)

Because the idiom repeats no code, we cannot introduce bugs within the operator. Note that this means we are rid of the need for a self-assignment check, allowing a single uniform implementation of operator=. (Additionally, we no longer have a performance penalty on non-self-assignments.)

And that is the copy-and-swap idiom.

What about C++11?

The next version of C++, C++11, makes one very important change to how we manage resources: the Rule of Three is now The Rule of Four (and a half). Why? Because not only do we need to be able to copy-construct our resource, we need to move-construct it as well.

Luckily for us, this is easy:

class dumb_array
{
public:
    // ...

    // move constructor
    dumb_array(dumb_array&& other) noexcept ††
        : dumb_array() // initialize via default constructor, C++11 only
    {
        swap(*this, other);
    }

    // ...
};

What's going on here? Recall the goal of move-construction: to take the resources from another instance of the class, leaving it in a state guaranteed to be assignable and destructible.

So what we've done is simple: initialize via the default constructor (a C++11 feature), then swap with other; we know a default constructed instance of our class can safely be assigned and destructed, so we know other will be able to do the same, after swapping.

(Note that some compilers do not support constructor delegation; in this case, we have to manually default construct the class. This is an unfortunate but luckily trivial task.)

Why does that work?

That is the only change we need to make to our class, so why does it work? Remember the ever-important decision we made to make the parameter a value and not a reference:

dumb_array& operator=(dumb_array other); // (1)

Now, if other is being initialized with an rvalue, it will be move-constructed. Perfect. In the same way C++03 let us re-use our copy-constructor functionality by taking the argument by-value, C++11 will automatically pick the move-constructor when appropriate as well. (And, of course, as mentioned in previously linked article, the copying/moving of the value may simply be elided altogether.)

And so concludes the copy-and-swap idiom.

---

Footnotes

*Why do we set mArray to null? Because if any further code in the operator throws, the destructor of dumb_array might be called; and if that happens without setting it to null, we attempt to delete memory that's already been deleted! We avoid this by setting it to null, as deleting null is a no-operation.

†There are other claims that we should specialize std::swap for our type, provide an in-class swap along-side a free-function swap, etc. But this is all unnecessary: any proper use of swap will be through an unqualified call, and our function will be found through ADL. One function will do.

‡The reason is simple: once you have the resource to yourself, you may swap and/or move it (C++11) anywhere it needs to be. And by making the copy in the parameter list, you maximize optimization.

††The move constructor should generally be noexcept, otherwise some code (e.g. std::vector resizing logic) will use the copy constructor even when a move would make sense. Of course, only mark it noexcept if the code inside doesn't throw exceptions.

Phonology

@GMan: A custom overload of swap is still potentially faster, because move semantics has to set source pointers to zero after copying them. – Albanian

@Fred: An optimizing compiler can easily see that such an assignment is wasteful, though. I demonstrate that in my answer I linked to in the post. You may have a point, though, that without such things a swap might still be faster. I wouldn't consider it worth it anymore, though. – Phonology

@GMan: If we rely on move semantics, the class definitely needs a move cctor and a move assignment operator. So this actually has more requirements than doing your own swap(). (I'm not arguing against doing so, just that this should be mentioned.) – Staal

@sbi: It is, "As long as one implements move-semantics.". :) Unless I'm misunderstanding. (EDIT: Guess not. :P) I'll make the C++0x section more concrete, though. By the way, I think the dtor requirement is made explicit when I say "this is for classes that implement The Big Three." I'll see if I can sneak it it. – Phonology

@GMan: I would argue that a class managing several resources at once is doomed to fail (exception safety becomes nightmarish) and I would strongly recommend that either a class manages ONE resource OR it has business functionality and use managers. – Pedology

@GMan nice one :) I wonder why you do that test against a zero size, though? Dynamic Zero size arrays are OK. – Salep

@Johannes: I know zero-size dynamic arrays are okay, but I did the check to 1) avoid having to get any dynamic memory and 2) make it look more complex. :P And good to know it is sufficient, I'll admit I was a bit confused what he was talking about. – Phonology

@Matthieu: I agree, I've added that point. @Johannes: I've touched it up a bit in regards to self-assignment. – Phonology

Very nice summary! I'd personally comment out throw(). Leave the text there to indicate you don't think the function will throw, but leave off the potential penalties: boost.org/development/requirements.html#Exception-specification – Hillhouse

@GMan: or you use the C++0x nothrow qualifier :-) – Pedology

@Chubsdad: Thanks. Good timing, I was planning to (and just did) improve and expand on C++0x changes. – Phonology

Big four? (1) dtor, (2) copy ctor, (3) copy op=, (4) move ctor, and (5) move op=. Which of those doesn't get counted? – Halbert

@GMan: You can declare both a copy op= and a move op=, can't you? (The implicit move op= is suppressed if a copy op= is implemented, though). Or, that's my understanding. Why am I wrong? – Halbert

@James: No, you're right, you can. You just take it by value in both C++03 and C++0x. (In C++03, lvalues get copied, rvalues hopefully get their copy elided, in C++0x lvalues get copied, ravlues get moved, and sometimes hopefully elided). – Phonology

@GMan: just reread this article (C++0x part), and I was wondering about the Big Four. I would have said Big Five to include the Move Assignment Operator :P Is a Move Assignment Operator defined automatically if you don't declare one ? – Pedology

@GMan: C++0x will support implicit move, though with some restrictions. (We'll have to wait until the next mailing at the end of the month to learn what restrictions were agreed upon...) – Halbert

@GMan, thanks for the very good tutorial! do you mind in giving an example how does a non-overloaded copy method would work using the copy-and-swap idiom, for instance, a method like void copy(const dumb_array& other) ? – Kimes

@Javier: I'm not sure I understand what you mean. Maybe you can ask a full question if needed, be sure to include code examples. – Phonology

@GMan, would the method below be conceptually correct following the copy-and-swap idiom? void dumb_array::copy(dumb_array other) { swap(*this, other); } – Kimes

@Javier: The idiom is useful for implementing the necessarily functions for copy-semantics (the big three). I guess my answer is "yes", but I can't see a use for such a function. – Phonology

@Javier: I can't think of a case where I only need to copy certain members. Perhaps those members should be their own class with their own functionality. – Phonology

The subject that one would have to spend hours reading all over the web is now put into a Single Compact Complete and Perfect (c) explanation. How kind @GMan! +1 – Avignon

What if dumb_array's constructor is explicit ? Calling operator=(dumb_array other) won't work, will it? – Botts

@Gabriel: Calling it with what? If it were, say, dumb_array x(1); x = 5;, then no, it wouldn't work. But that's really nothing to do with anything except the explicit constructor. – Phonology

@GMan Ok, then it means that if a class needs its constructor to be explicit for any reason, it can't use this implementation of the copy and swap idiom. A slight change in operator= would fix this: passing the object to be copied by reference and declaring a local object at the beginning of the function, copy-constructing it. – Botts

@Gabriel: I'm not sure I understand. explicit constructors and copy-and-swap are two totally unrelated things. Changing the parameter to a reference still wouldn't allow the code in my previous example to work. – Phonology

@GMan Sorry I was talking about explicit copy-constructor. The way you put it, if you need to set dumb_array's copy-constructor as explicit, you won't be able to write: dumb_array a, b; a = b;. Change the copy-constructor to dumb_array& operator=(dumb_array & other) { swap(*this, dumb_array(other)); return *this; } and now you can. – Botts

@Gabriel: Ah, indeed. That said, I've never found a solid justification for making a copy-constructor explicit. – Phonology

I don't get why swap method is declared as friend here? – Foy

And I don't get why the default constructor does "new int[mSize]()" while the copy constructor does "new int[mSize]". What's the difference? – Choosey

@neuviemeporte: With the parenthesis, the arrays elements are default initialized. Without, they are uninitialized. Since in the copy constructor we'll be overwriting the values anyway, we can skip initialization. – Phonology

@GMan: Thanks. Also, I was wondering if it would be possible for swap() to be a member function of dumb_array. Global friend functions seem messy to me. – Choosey

@neuviemeporte: If you want it to be found during ADL (using std::swap; swap(x, y);), it needs to be a global friend. – Phonology

@GMan: I'm not sure I understand; wouldn't making swap() a member make it simpler so you don't have to care about ADL at all? – Choosey

@neuviemeporte: You need your swap to be found during ADL if you want it to work in most generic code that you'll come across, like boost::swap and other various swap instances. Swap is a tricky issue in C++, and generally we've all come to agree that a single point of access is best (for consistency), and the only way to do that in general is a free function (int cannot have a swap member, for example). See my question for some background. – Phonology

How do you do swap for a derived class? – Painful

@KerrekSB: Sounds like a reasonable question on it's own. I'll admit I'm not sure I fully understand the use-case you're after though. – Phonology

@GManNickG: The immediate motivation is this problem, but I've recently been wondering in general if one can write a swap for a derived class by slicing, provided the base provides a swap. – Painful

@KerrekSB: I'd just take the approach you're taking, swapping the base classes before swapping the most derived class. – Phonology

@GManNickG: I've come to the conclusion that slicing exists precisely for the purpose of implementing copy constructor, copy assignment and swap functions for derived classes. Swap was added just today as this dawned on me. Does that sound reasonable? – Painful

@KerrekSB: Well, I don't actually see any slicing. It's my understanding that A::swap(rhs) is the same as this->A::swap(rhs); if A::swap called any virtual functions, for example (it shouldn't), they could be dispatched to the most derived class. – Phonology

@GManNickG: Hm, good point; calling the base swap doesn't actually slice. But assuming that each class implements its own "standard" swap semantics, it "slice-swaps" only the base part of the object. – Painful

@Phonology Your move constructor depends on the default ctor. Does that mean that (since move semantics) it's obligatory for every resource wrapper to have 1) a valid "empty" state and 2) a default ctor that initializes to this state? – Maurer

@Kos: Technically no. You can do whatever you want in your move constructor and have whatever moved-from state. But it's more than good practice to reset to a simple reusable state. The standard library classes (like std::vector<>) do such a thing. – Phonology

@Phonology In a previous comment you say that swap should be a global friend to in order for it to be found through ADL. In your example, swap looks like a public member of dumb_array. What am I missing? – Indigestible

@zmb: The "global" part (that is, being declared completely outside the class) is optional. What's important is that it's a non-member friend function, so that it will be found during ADL, such as when the standard library calls swap(x, y);. See this for more complete information. – Phonology

Would the recommendation about dumb_array(dumb_array&& other) (i.e. default construct then swap) be different if dumb_array::dumb_array() was expensive (say, it always reserved some space)? Would it be better in that case to initialise members by moving from the other object, then null out the moved-from object's state? – Denyse

@BenHymers: Yes. The copy-and-swap idiom is only intended to simplify the creation of new resource managing classes in a general way. For every particular class, there is almost certainly a more efficient route. This idiom is just something that works and is hard to do wrong. – Phonology

@Phonology your answer is helpful, but some credit to [icce.rug.nl/documents/cplusplus/cplusplus11.html#l194] [icce.rug.nl/documents/cplusplus/cplusplus09.html#l159], Scott Meyers wouldn't harm – Kameko

@GManNickG: FWIW, statements like dumb_array temp(other); are untenable in generic code (e.g. an STL vector implementation). The reason is that the size of dumb_array is arbitrary and may be too large for the stack and crash the application due to stack space exhaustion. I've run into this situation a number of times in practice, especially on platforms with small default stacks like Mac OS X. – Prescribe

@ThreeBit: The array is not stored in stack space, as is also the case in std::vector with the default allocator. You have run into a different problem in practice. – Phonology

@Phonology You're right about vector as pretty much all vector implementations allocate their memory on the heap. I shouldn't have used that as a supposed example. I meant that in general you can't write generic code that creates instances of arbitrary objects on the stack. There are alternatives, of course. – Prescribe

Mine is an unusual case, but I encountered a subtle problem using std::swap on a class that has a pointer into a string that's part of the object. Discussed here: https://mcmap.net/q/15707/-implementing-swap-for-objects-with-internal-pointers – Treblinka

Why is this the swap function declared with as a friend at this line friend void swap(dumb_array& first, dumb_array& second) // nothrow? if its declared within a class isnt it just a member function? – Tiller

@VisViva a friend in a class is a non member function in the surrounding scope, but as a friend it gets the usual access to non-public members. It's a stylistic choice, but can be nicely concise to define small functions there, rather than declare them and have to repeat the signature (possibly with more explicit template parameters) in the surrounding scope before launching into the function body. – Forland

@TonyD but why is it defined in the class itself? shouldnt it be written somewhere else and instead just be declared inside a class with a friend keyword? – Tiller

@VisViva that's only a style issue - concision and clear participation in the class's overall interface vs separation of interface from implementation (and potentially avoiding being implicitly inline) - pick as you like. – Forland

Implementing the assignment via the copy constructor may cause an unneeded allocation, potentially even causing an uncalled for out-of-memory error. Consider the case of assigning a 700MB dumb_array to a 1GB dumb_aaray on a machine with a <2GB heap limit. An optimal assignment will realize it already has enough memory allocated and only copy the data into it's already allocated buffer. Your implementation will cause an allocation of another 700MB buffer before the 1GB one is released, causing all 3 to try co-exist in memory at once, which will throw an out-of-memory error needlessly. – Mcglothlin

As is called out multiple times, the point is to have something that works, not something that is optimal. There is a trade-off between engineering time and application time. – Phonology

@GManNickG: Since it sacrifices efficiency for maintainability, you should probably explicitly point out somewhere in either the question or the answer that copy-and-swap is a solution, not the solution, and that it may make sense to re-use the object rather than construct a new one. Otherwise people will have no idea. (It seems obvious but it's not; it took me a long time to realize this.) – Flense

For anyone wondering why to use unqualified swaps: std::swap will generally call a copy constructor (move constructor in C++11+) and two assignment operators, and for classes using the copy-and-swap idiom, each assignment operator will call the class-specific swap function anyway. Therefore, using std::swap would cost twice as much, PLUS the cost of a move or copy constructor. That's not to say copy-and-swap makes std::swap super-slow; std::swap is just suboptimal. – Reneta

On tradeoffs: I benchmarked a class like the one above using three versions: An old-style operator with a self-assignment test, a copy-and-swap, and a slightly more manual "copy-and-move" which only swaps resources and move-assigns everything else. For an empty array, copy-and-swap is about 25% faster than the old-style assignment with Clang, but for non-empty arrays or for GCC, the old-style assignment is ~0-12.5% faster. "Copy-and-move" generally shaves a tiny fraction off copy-and-swap times, but it doesn't doesn't benefit from whatever optimization Clang used above. (cont.) – Reneta

I had hoped avoiding the self-assignment test would pay for copy-and-swap's extra operations, but it seems that's not always true (probably due to fast branch prediction). Still, it's close and sometimes wins depending on circumstances, so you don't have to pay much for formulaic correctness and exception safety, at least for this particular class. However, according to Howard Hinnant, the idiom can be up to 8x slower for std::vector, so YMMV. – Reneta

Answer 2

Assignment, at its heart, is two steps: tearing down the object's old state and building its new state as a copy of some other object's state.

Basically, that's what the destructor and the copy constructor do, so the first idea would be to delegate the work to them. However, since destruction mustn't fail, while construction might, we actually want to do it the other way around: first perform the constructive part and, if that succeeded, then do the destructive part. The copy-and-swap idiom is a way to do just that: It first calls a class' copy constructor to create a temporary object, then swaps its data with the temporary's, and then lets the temporary's destructor destroy the old state.
Since swap() is supposed to never fail, the only part which might fail is the copy-construction. That is performed first, and if it fails, nothing will be changed in the targeted object.

In its refined form, copy-and-swap is implemented by having the copy performed by initializing the (non-reference) parameter of the assignment operator:

T& operator=(T tmp)
{
    this->swap(tmp);
    return *this;
}

Staal

I think that mentioning the pimpl is as important as mentioning the copy, the swap and the destruction. The swap isn't magically exception-safe. It's exception-safe because swapping pointers is exception-safe. You don't have to use a pimpl, but if you don't then you must make sure that each swap of a member is exception-safe. That can be a nightmare when these members can change and it is trivial when they're hidden behind a pimpl. And then, then comes the cost of the pimpl. Which leads us to the conclusion that often exception-safety bears a cost in performance. – Nodular

... you can write allocators for the class which will maintain the pimpl's cost amortized. That adds complexity, which hits on the simplicity of the plain-vanilla copy-and-swap idiom. It's a choice. – Nodular

std::swap(this_string, that) doesn't provide a no-throw guarantee. It provides strong exception safety, but not a no-throw guarantee. – Nodular

This means that if you have two members of class-type then in the assignment-operator if the first swap worked and the second failed then you'll have to make sure you undo the first swap to maintain the strong-exception safety. And this is with just two members of class-type. – Nodular

@wilhelmtell: I doubt that std::swap() violates the no-throw guarantee when instantiated with std::string. (That +1 on your comment was me failing on a mouse click.) There is a specialization for std::string calling std::string::swap(). [C++03, 21.3.7.8: "Effect: lhs.swap(rhs);"] – Staal

@wilhelmtell: In C++03, there is no mention of exceptions potentially thrown by std::string::swap (which is called by std::swap). In C++0x, std::string::swap is noexcept and must not throw exceptions. – Halbert

@Staal @JamesMcNellis ok, but the point still stands: if you have members of class-type you must make sure swapping them is a no-throw. If you have a single member that is a pointer then that's trivial. Otherwise it isn't. – Nodular

@wilhelmtell: Yes. I'm surprised that the new C++0x Swappable concept does not mandate user-defined swap functions be noexcept. – Halbert

@wilhelmtell: I thought that was the point of swapping: it never throws and it is always O(1) (yeah, I know, std::array...) – Staal

@sbi, what if we would like to use copy method that is similar in functionality to the operator =. For instance, a method like void copy(const T & other). How does the copy-and-swap idiom could be used in this case? – Kimes

@Javier: What would that method do? – Staal

@sbi, in the case of overloading the operator= we copy the whole class members. In my case, I need to copy only certain class members & I wanted to use the copy-swap protocol to do that, e.g. void myClass<T>::copy(myclass<T> tmp){using std::swap; swap(member1,tmp.member1); swap(member3,tmp.member3); };. Does this make sense? What about the tmp parameter, should it be passed as value? – Kimes

@Javier: Yes, then copying (by taking the argument by value) and swapping (by swapping individual members) makes sense. Well, insofar as having a method named copy() that only copies part of an object makes sense at all. (I'd at least name it copy_from() or something similar, so that it is clearer what the direction is.) – Staal

@sbi, great! Thanks for the explanations! But, I'm not really sure that I understood why does the argument should be by value? – Kimes

@Javier: Because you need to make a copy anyway. (You don't want to swap with the original one, but with a copy of it.) You could just as well pass by const reference and then make a copy of the argument within the function. However, the idiomatic way to do this is to take the argument by copy instead. – Staal

Is it safe to mark T& operator=(T tmp) as noexcept? – Royden

@becko: Not in general, no. It invokes a copy ctor, and generally these can allocate resources, which might fail, and result in exceptions thrown. – Staal

@Staal I think I agree with Daniel Frey's answer here: https://mcmap.net/q/15708/-how-to-use-noexcept-in-assignment-operator-with-copy-and-swap-idiom (which I found later). If you have a counter argument please share it with me. – Royden

@becko: He does make a very good point, so I retract my statement and insist that the opposite is true. :) – Staal

This answer needs "what are the problems with it" section. – Karinakarine

Answer 3

There are some good answers already. I'll focus mainly on what I think they lack - an explanation of the "cons" with the copy-and-swap idiom....

What is the copy-and-swap idiom?

A way of implementing the assignment operator in terms of a swap function:

X& operator=(X rhs)
{
    swap(rhs);
    return *this;
}

The fundamental idea is that:

• the most error-prone part of assigning to an object is ensuring any resources the new state needs are acquired (e.g. memory, descriptors)

• that acquisition can be attempted before modifying the current state of the object (i.e. *this) if a copy of the new value is made, which is why rhs is accepted by value (i.e. copied) rather than by reference

• swapping the state of the local copy rhs and *this is usually relatively easy to do without potential failure/exceptions, given the local copy doesn't need any particular state afterwards (just needs state fit for the destructor to run, much as for an object being moved from in >= C++11)

When should it be used? (Which problems does it solve [/create]?)

• When you want the assigned-to objected unaffected by an assignment that throws an exception, assuming you have or can write a swap with strong exception guarantee, and ideally one that can't fail/throw..†

• When you want a clean, easy to understand, robust way to define the assignment operator in terms of (simpler) copy constructor, swap and destructor functions.

  • Self-assignment done as a copy-and-swap avoids oft-overlooked edge cases.‡

• When any performance penalty or momentarily higher resource usage created by having an extra temporary object during the assignment is not important to your application. ⁂

---

† swap throwing: it's generally possible to reliably swap data members that the objects track by pointer, but non-pointer data members that don't have a throw-free swap, or for which swapping has to be implemented as X tmp = lhs; lhs = rhs; rhs = tmp; and copy-construction or assignment may throw, still have the potential to fail leaving some data members swapped and others not. This potential applies even to C++03 std::string's as James comments on another answer:

@wilhelmtell: In C++03, there is no mention of exceptions potentially thrown by std::string::swap (which is called by std::swap). In C++0x, std::string::swap is noexcept and must not throw exceptions. – James McNellis Dec 22 '10 at 15:24

---

‡ assignment operator implementation that seems sane when assigning from a distinct object can easily fail for self-assignment. While it might seem unimaginable that client code would even attempt self-assignment, it can happen relatively easily during algo operations on containers, with x = f(x); code where f is (perhaps only for some #ifdef branches) a macro ala #define f(x) x or a function returning a reference to x, or even (likely inefficient but concise) code like x = c1 ? x * 2 : c2 ? x / 2 : x;). For example:

struct X
{
    T* p_;
    size_t size_;
    X& operator=(const X& rhs)
    {
        delete[] p_;  // OUCH!
        p_ = new T[size_ = rhs.size_];
        std::copy(p_, rhs.p_, rhs.p_ + rhs.size_);
    }
    ...
};

On self-assignment, the above code delete's x.p_;, points p_ at a newly allocated heap region, then attempts to read the uninitialised data therein (Undefined Behaviour), if that doesn't do anything too weird, copy attempts a self-assignment to every just-destructed 'T'!

---

⁂ The copy-and-swap idiom can introduce inefficiencies or limitations due to the use of an extra temporary (when the operator's parameter is copy-constructed):

struct Client
{
    IP_Address ip_address_;
    int socket_;
    X(const X& rhs)
      : ip_address_(rhs.ip_address_), socket_(connect(rhs.ip_address_))
    { }
};

Here, a hand-written Client::operator= might check if *this is already connected to the same server as rhs (perhaps sending a "reset" code if useful), whereas the copy-and-swap approach would invoke the copy-constructor which would likely be written to open a distinct socket connection then close the original one. Not only could that mean a remote network interaction instead of a simple in-process variable copy, it could run afoul of client or server limits on socket resources or connections. (Of course this class has a pretty horrid interface, but that's another matter ;-P).

Forland

That said, a socket connection was just an example - the same principle applies to any potentially expensive initialisation, such as hardware probing/initialisation/calibration, generating a pool of threads or random numbers, certain cryptography tasks, caches, file system scans, database connections etc.. – Forland

There is one more (massive) con. As of current specs technically the object will not have an move-assignment operator! If later used as member of a class, the new class will not have move-ctor auto-generated! Source: youtu.be/mYrbivnruYw?t=43m14s – Tartaric

The main problem with the copy assignment operator of Client is that assignment is not forbidden. – Staal

In the client example, the class should be made noncopyable. – Ulund

Answer 4

This answer is more like an addition and a slight modification to the answers above.

In some versions of Visual Studio (and possibly other compilers) there is a bug that is really annoying and doesn't make sense. So if you declare/define your swap function like this:

friend void swap(A& first, A& second) {

    std::swap(first.size, second.size);
    std::swap(first.arr, second.arr);

}

... the compiler will yell at you when you call the swap function:

This has something to do with a friend function being called and this object being passed as a parameter.

---

A way around this is to not use friend keyword and redefine the swap function:

void swap(A& other) {

    std::swap(size, other.size);
    std::swap(arr, other.arr);

}

This time, you can just call swap and pass in other, thus making the compiler happy:

---

After all, you don't need to use a friend function to swap 2 objects. It makes just as much sense to make swap a member function that has one other object as a parameter.

You already have access to this object, so passing it in as a parameter is technically redundant.

Windflower

@Phonology dropbox.com/s/o1mitwcpxmawcot/example.cpp dropbox.com/s/jrjrn5dh1zez5vy/Untitled.jpg. This is a simplified version. A error seems to occur every time a friend function is called with *this parameter – Windflower

@Phonology as I said, it's a bug and might work fine for other people. I just wanted to help some people who might have the same problem as me. I tried this with both Visual Studio 2012 Express and 2013 Preview and the only thing that made it go away, was my modification – Windflower

Yeah, definitely a bug. This should probably be a comment on an existing answer, though, and not an answer, since it doesn't answer the actual question. People may -1 it. – Phonology

@Phonology it wouldn't fit in a comment with all the images and code examples. And it's ok if people downvote, I'm sure there's someone out there who's getting the same bug; the information in this post might be just what they need. – Windflower

note that this is only a bug in the IDE code highlighting (IntelliSense)... It will compile just fine with no warnings/errors. – Elation

Please report the VS bug here if you have not done so already (and if it has not been fixed) connect.microsoft.com/VisualStudio – Giovanna

A year after this post this error still hasn't been fixed?! – Inimitable

I understand that the motivation for this approach might be just to workaround the IDE, but you gave a reasonable argument about redundancy in defining a friend function. Why isn't this the default implementation approach? Is that just a matter of C++ philosophy or just by chance the friend one became the most common? Is it a common scenario that someone else except the class itself is going to call swap? – Myrmeco

@VillasV see stackoverflow.com/questions/5695548/… – Endoplasm

Answer 5

I would like to add a word of warning when you are dealing with C++11-style allocator-aware containers. Swapping and assignment have subtly different semantics.

For concreteness, let us consider a container std::vector<T, A>, where A is some stateful allocator type, and we'll compare the following functions:

void fs(std::vector<T, A> & a, std::vector<T, A> & b)
{ 
    a.swap(b);
    b.clear(); // not important what you do with b
}

void fm(std::vector<T, A> & a, std::vector<T, A> & b)
{
    a = std::move(b);
}

The purpose of both functions fs and fm is to give a the state that b had initially. However, there is a hidden question: What happens if a.get_allocator() != b.get_allocator()? The answer is: It depends. Let's write AT = std::allocator_traits<A>.

• If AT::propagate_on_container_move_assignment is std::true_type, then fm reassigns the allocator of a with the value of b.get_allocator(), otherwise it does not, and a continues to use its original allocator. In that case, the data elements need to be swapped individually, since the storage of a and b is not compatible.

• If AT::propagate_on_container_swap is std::true_type, then fs swaps both data and allocators in the expected fashion.

• If AT::propagate_on_container_swap is std::false_type, then we need a dynamic check.

  • If a.get_allocator() == b.get_allocator(), then the two containers use compatible storage, and swapping proceeds in the usual fashion.
  • However, if a.get_allocator() != b.get_allocator(), the program has undefined behaviour (cf. [container.requirements.general/8].

The upshot is that swapping has become a non-trivial operation in C++11 as soon as your container starts supporting stateful allocators. That's a somewhat "advanced use case", but it's not entirely unlikely, since move optimizations usually only become interesting once your class manages a resource, and memory is one of the most popular resources.

Painful