Can std::string be replaced by a template parameter T in this C++ code, and if so, does Meyer's argument about its performance cost still apply?

Question

In Item 25 of More Effective C++, Meyer compares this code:

class Widget {
public:
 template<typename T>
 void setName(T&& newName) // newName is
 { name = std::forward<T>(newName); } // universal reference
 …
};

To this code:

class Widget {
public:
 void setName(const std::string& newName) // set from
 { name = newName; }                      // const lvalue
 void setName(std::string&& newName)      // set from
 { name = std::move(newName); }           // rvalue
 …
};

One drawback he outlines with the second snippet vs the first is performance:

With the version of setName taking a universal reference, the string literal "Adela Novak" would be passed to setName, where it would be conveyed to the assignment operator for the std::string inside w. w’s name data member would thus be assigned directly from the string literal; no temporary std::string objects would arise. With the overloaded versions of setName, however, a temporary std::string object would be created for setName’s parameter to bind to, and this temporary std::string would then be moved into w’s data member. A call to setName would thus entail execution of one std::string constructor (to create the temporary), one std::string move assignment operator (to move newName into w.name), and one std::string destructor (to destroy the temporary). That’s almost certainly a more expensive execution sequence than invoking only the std::string assignment operator taking a const char* pointer.

But why can't you just make templates out of them, so the cast to std::string is unnecessary? As in this code, which seems to compile and run just fine with suitable adjustments:

class Widget {
public:
 template<typename T>
 void setName(const T& newName) // set from
 { name = newName; }                      // const lvalue
 template<typename T>
 void setName(T&& newName)      // set from
 { name = std::move(newName); }           // rvalue
 …
};

NB: It's not that I'm arguing for this overloading strategy. Meyer's other arguments are compelling. I would just like some help understanding this particular argument about performance.

Answer 1

(my entire previous answer was terribly wrong and I misinterpreted the code sample I made)

http://melpon.org/wandbox/permlink/d8SAf3FSoo0vw1Di

Because a string literal is actually considered to be an l-value (Why are string literals l-value while all other literals are r-value?), your suggestion ends up calling the lvalue reference version with newName being const char[5] &. However, the name is still directly constructed from the raw string literal data, not resulting in a double constructor call.

Tangentially, if you want to turn the T from a char[5] into a char*, that is what (among other things) std::decay does.

Answer 2

This is dangerous and bad code:

class Widget {
public:
  template<typename T>
  void setName(const T& newName) // set from
  { name = newName; }                      // const lvalue
  template<typename T>
  void setName(T&& newName)      // set from
  { name = std::move(newName); }           // rvalue
};

The above has a bug.

Given a variable std::string s, calling setName(s) will move from it.

This is rude and unexpected.

live example.

T&& will bind to both rvalues and lvalues. When you use T&& in a deduced context for T, you should not ever move from it (well almost not ever): you should std::forward<T> from it.

std::forward<T> becomes move iff T&& is an rvalue (a value you should move from).

It is a nearly noop if T&& is an lvalue.

You attempted to split move and copy: you failed. Even if it worked, it would just have been a more verbose version of the perfect forwarding one.

Regardless, all of that template stuff in this case is a bad idea. Just void setName(std::string newName){name = std::move(newName);} for 95% of the performance, half the code, and 1/4 of the complexity.

int main