1.1.9.5 function interface parameter design

• The move copy ctor and move assignment operator give us a idea how to improve function interface design. By now, you imagine you have a fun, then you have three operations inside, 1) read 2) copy 3) write.
• For read, "const type&" is enough, For write, "type&" is good, because I don’t need to write sth into prvalue. so:
  writeFun(Foo &); 
   
  writeFun(foo1+foo2) // will not compile, foo1+foo2 is rvalue.
• For copy, thing become interesting. because for rvalue, we can move directly, and at the same time, we have ROV.

  	lvalue	rvalue
  copyFun(Foo foo)	copy parameter move inside	move parameter move inside
  copyFun(Foo &)	copy inside	(NOT support)
  copyFun(const Foo &)	copy inside	copy inside
  copyFun(Foo &&)	(NOT support)	move inside
  template<T&&> copyFun(T &&)	copy inside	move inside

• Our goal is that we use move for rvalue, so there are three options: 1) overlaod copyFun to support const Foo& and Foo &&. 2) Use pass-value fun(Foo ) 3) Use universal reference
  fun(Foo value){ 
  vector<Foo> vect; 
  vect.push_back(std::move(value)); //use move to implement 
  }
• Use Overload fun to deal with rvalue only. So usually function to accept rvalue reference doesn’t exit by itself, it just stay with another version to accept lvalue, fun(const Foo& foo);
  //rvalue reference 
  fun(Foo&& foo); 
  fun(foo1+foo2) // will compile, It means that inside fun 
  // you will steal resource. It’s not common usage.
• You can use universal reference too, but inside, you have to use forward function, and implementation is a little difficult. Detail can be seen "effective modern c++ item 41".
• As a template, implementation must typically be in a header file. It may yield several functions in object code, because it not only instantiates differently for lvalues and rvalues, it also instantiates differently for std::string and types that are convertible to std::string (see Item 25). At the same time, there are argument types that can’t be passed by universal reference (see Item 30), and if clients pass improper argument types, compiler error messages can be intimidating (see Item 27).
  template<typename T> // reference 
  fun(T&& value){ 
  vector<Foo> vect; 
  vect.push_back(std::forward<T>(value)); // use move here to implement 
  }
• Below, there are three reasons that I have to use universal reference:
  1. If you have a template class or template fun, universal reference is your only choice. An example can be seen in the last chapter, "decltype deduction" section.
  2. First, it’s more source code to write and maintain (two functions instead of a single template). Second, it can be less efficient. For example, consider this use of setName: w.setName("Adela Novak"); 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.
  3. overload has the poor scalability of the design. Widget::setName takes only one parameter, so only two overloads are necessary, but for functions taking more parameters, each of which could be an lvalue or an rvalue, the number of overloads grows geometrically: n parameters necessitates 2n overloads. Such as make_shared function, It’s also support variadic parameter
     template<class T, class... Args> // from C++11 
     shared_ptr<T> make_shared(Args&&... args); // Standard 
      
     template<class T, class... Args> // from C++14 
     unique_ptr<T> make_unique(Args&&... args); // Standard
• Overloading on universal references almost always leads to the universal reference overload being called more frequently than expected. Perfect-forwarding constructors are especially problematic, because they’re typically better matches than copy constructors for non-const lvalues, and they can hijack derived class calls to base class copy and move constructors. detail can be seen in "effective modern c++ item 26"
• When you function return a value.
  1. Apply std::move to rvalue references and std::forward to universal references the last time each is used.
  2. Do the same thing for rvalue references and universal references being returned from functions that return by value.
     Matrix // by-value return 
     operator+(Matrix&& lhs, const Matrix& rhs){ 
     lhs += rhs; 
     return std::move(lhs); // move lhs into 
     return lhs // it will copy, because lhs is lvalue 
     } 
      
     template<typename T> 
     Fraction // by-value return 
     reduceAndCopy(T&& frac) { 
     frac.reduce(); 
     return std::forward<T>(frac); 
     // move rvalue or copy lvalue into return 
     }
  3. Never apply std::move or std::forward to local objects if they would otherwise be eligible for the return value optimization.