void f() {
  try {
    dangerous();
  } catch(Exception &e) {
    // (seemingly) copy it then (seemingly) modify 
    // only the copy
    Exception copy(e);
    copy.enjoy();
    throw; 
  }
}

We would accidentally modify the exception object. I think the restriction of the reference binding will generally make it so we can’t refer to the temporary object a second time.

void f() {
  try {
    prolly_failing();
  } catch(Exception &e) {
    Exception e1(e);
    e1.modify();
      // oops, e is modified potentially
  }
}

Since exception objects are temporaries too, the restriction about reference binding makes the irritating case of above not possible.

Maybe, but it’s probably not as scary as you think. Outside namespace std, an unqualified call to swap won’t find std::swap unless you’ve explicitly brought it into scope with a using-declaration.

…which would penalize the usual case and complicate the code in order to optimize a rare case, which is almost always a bad idea.

Niels Dekker: I find it slightly counter-intuitive, having a self-assignment that might fail!

These self-assignments never have the form x = x anyway (nobody knowingly does a self-assignment except in test suites). They’re almost always x = y cases, where x and y may or may not refer to the same object. That means we’re in code that has to cope with an exception anyhow. There’s really zero advantage in making self-assignment a no-throw operation.

vector<string> const  names = get_names(); // #1
vector<string> const& names = get_names(); // #2

Assuming get_names returns by value (and not a reference) and you’re dealing with a “good” compiler there should not be a difference between the two. In the first case (#1) the compiler can make the function construct its return value directly in that space that will be referred to by the name “names”. In #2 the return value that lives on the stack gets an extension of its life-time and a reference to it is created. A good compiler doesn’t even need to allocate space for the reference but I’m not sure if most compilers are that smart (even though they could be).

If get_names returns a reference it makes a big difference, of course. Is the following code safe?

string const& blah = string("123") + "456";

Currently, it is safe. It’s not safe C++0x (according to the current draft) because operator+(string&&,char const*) returns an rvalue reference –> You get a dangling reference.

In my opinion, people should not write #2 instead of #1 just because they think they can safe a copy. Many current compilers successfully elide the copy in #1. Also, they should not declare functions that return rvalue references (I really hope operator+(string&&,char const*) and others will be fixed) for “temporary recycling” because it opens up the possibility of dangling references.

Cheers! SG

Indeed, for something like vector::push_back, passing by value is useless, even though you want to explicitly copy the argument.

void vector::push_back(const T& t)
{
    ...
    new(buffer) T(t);
    ...
}

It would be silly to pass t by value.

So I believe it should be something like:

Pass by value any arguments that you would otherwise copy explicitly, and for which you do not need to control the storage of the copy.