I think the solution is building applications in layers of abstraction. This can permit all/most of the issues related to low level optimization to be addressed in lower layers while upper layers and ignore most of this. This is why I’m a fan of C++. Unfortunately, I think a lot of programing shops miss and just start coding rather than building applications layer by layer. Using C++ in this way causes lots of frustration and confusion.

C++ is a toolbox for making other toolboxes.

Robert Ramey

1. It leaves the impression that one should always write your assignment operator like so:

   T& operator=(T x)    // x is a copy of the source; hard work already done
   {
       swap(*this, x);  // trade our resources for x's
       return *this;    // our (old) resources get destroyed with x
   }
   

   But in some important cases, this is a large performance penalty. Vector-like classes where heap memory can be reused during the copy assignment is a classic example. I’ve just written a short example showing as high as a 7X performance penalty.

2. In C++11 the correct way to write sorted is:

   std::vector<std::string>
   sorted(std::vector<std::string> names)
   {
       std::sort(names.begin(), names.end());
       return names;
   }
   

   Implicit return-by-move from by-value parameters is now required.

The basic point of the article is sound: Passing by value is an important tool in the tool box. But I’ve seen too many references to this article that mistakenly throw design and testing out the window on this issue, and translate this article into “always pass by value”.

I wish this were crisper, but I would say:

• operator= is unconditionally noexcept
• assignment from an lvalue is noexcept if T’s copy constructor is noexcept
• assignment from an rvalue is noexcept if move-constructing a T is noexcept

T& T::operator=( T const& x )
{ 
  T tmp(x);          // can throw
  swap(*this, tmp);  // no-throw (let's assume)
  return *this; 
}

This really says what I need to do to assign the value from one object represented by reference ‘x’. I need to make a copy first, and swap it with my value. Can this operation throw? Surely: a copy constructor is a typical place where one would expect a throw.

Now, is the answer the same for the “pass-by-value” idiom?

T& operator=(T x)    // this copying is not inside the assignment
{
    swap(*this, x);  // no-throw
    return *this;  
}

Technically we are doing the same thing, but copying is somehow ejected outside of the function. The function only does a no-fail (let’s assume that) swap. So in fact, I can write:

T& operator=(T x) noexcept
{
    swap(*this, x);  // no-throw
    return *this;  
}

I am telling the truth: there is nothing in the copy assignment that could cause a throw. But anyone who tries to use the assignment may throw, beacuse our function even thouh it does not copy itself, forces you to copy T, even though you are not (or may be not) aware of it. That is, by declaring the function like this (with noexcept), while technically being correct, I confuse everyone by implying that using this assignment operator does not raise exceptions. I would be more honest if I wrote:

T& operator=(T x) noexcept( std::is_nothrow_copy_constructible<T>::value )
{
    swap(*this, x);  // no-throw
    return *this;  
}

But this also looks strange: why would I base the condition on the properties of the constructor that I never call?