<Effective C++>读书摘要--Designs and Declarations<二>

<Item 20> Prefer pass-by-reference-to-const to pass-by-value

1、By default, C++ passes objects to and from functions by value (a characteristic it inherits from C). Unless you specify otherwise, function parameters are initialized with copies of the actual arguments, and function callers get back a copy of the value returned by the function. These copies are produced by the objects' copy constructors. This can make pass-by-value an expensive operation. 使用传值调用函数的时候，还需要创建和析构参数的父类和参数类中的非静态成员变量。Still, it would be nice if there were a way to bypass all those constructions and destructions. There is: pass by reference-to-const:使用const保证不修改入参的值。

bool validateStudent(const Student& s);

2、Copy-On-Write(COW)的一个定义：在复制一个对象的时候并不是真正的把原先的对象复制到内存的另外一个位置上，而是在新对象的内存映射表中设置一个指针，指向源对象的位置，并把那块内存的Copy-On-Write位设置为1.在对这个对象执行读操作的时候，内存数据没有变动，直接执行就可以。在写的时候，才真正将原始对象复制一份到新的地址，修改新对象的内存映射表到这个新的位置，然后往这里写。如C++里面一些种类的string实现。

3、Passing parameters by reference also avoids the slicing problem. When a derived class object is passed (by value) as a base class object, the base class copy constructor is called, and the specialized features that make the object behave like a derived class object are "sliced" off. You're left with a simple base class object — little surprise, since a base class constructor created it. This is almost never what you want. 

 4、If you peek under the hood of a C++ compiler, you'll find that references are typically implemented as pointers, so passing something by reference usually means really passing a pointer.Implementers of iterators and function objects are responsible for seeing to it that they are efficient to copy and are not subject to the slicing problem. (This is an example of how the rules change, depending on the part of C++ you are using — see Item 1.)

5、Built-in types are small, so some people conclude that all small types are good candidates for pass-by-value, even if they're user-defined. This is shaky reasoning. Just because an object is small doesn't mean that calling its copy constructor is inexpensive. Many objects — most STL containers among them — contain little more than a pointer, but copying such objects entails copying everything they point to. That can be very expensive.

Even when small objects have inexpensive copy constructors, there can be performance issues. Some compilers treat built-in and user-defined types differently, even if they have the same underlying representation. For example, some compilers refuse to put objects consisting of only a double into a register, even though they happily place naked doubles there on a regular basis. When that kind of thing happens, you can be better off passing such objects by reference, because compilers will certainly put pointers (the implementation of references) into registers.

Another reason why small user-defined types are not necessarily good pass-by-value candidates is that, being user-defined, their size is subject to change. A type that's small now may be bigger in a future release, because its internal implementation may change. Things can even change when you switch to a different C++ implementation. As I write this, for example, some implementations of the standard library's string type are seven times as big as others.

6、In general, the only types for which you can reasonably assume that pass-by-value is inexpensive are built-in types and STL iterator and function object types. For everything else, follow the advice of this Item and prefer pass-by-reference-to-const over pass-by-value.

7、Things to Remember

• Prefer pass-by-reference-to-const over pass-by-value. It's typically more efficient and it avoids the slicing problem.

• The rule doesn't apply to built-in types and STL iterator and function object types. For them, pass-by-value is usually appropriate.

<Item 21>Don't try to return a reference when you must return an object

8、C++中的引用类型对应指针类型，只是增加了编译期约束:一旦引用了一个对象则不能更换。

9、A function can create a new object in only two ways: on the stack(栈) or on the heap(堆). Creation on the stack is accomplished by defining a local variable.

10、返回不同类型变量的引用都可能会存在问题

• The fact is, any function returning a reference to a local object is broken. (The same is true for any function returning a pointer to a local object.)。对返回的局部变量的引用或者指针进行对象操作时未定义行为。因此返回stack上面的对象上面的引用是不可行的
• 通过new使重载的操作符返回heap上面的变量可能会造成内存泄露

const Rational& operator*(const Rational& lhs,   // warning! more bad
                          const Rational& rhs)   // code!
{
  Rational *result = new Rational(lhs.n * rhs.n, lhs.d * rhs.d);
  return *result;
}
Rational w, x, y, z;
w = x * y * z;                     // same as operator*(operator*(x, y), z)  没有delete内存泄漏

• Like all designs employing the use of static objects, this one immediately raises our thread-safety hackles, but that's its more obvious weakness. To see its deeper flaw, consider this perfectly reasonable client code:static对象会让编译器产生一段惰性初始化代码，使得代码多了一个条件分支，影响局部性能。

const Rational& operator*(const Rational& lhs,    // warning! yet more
                          const Rational& rhs)    // bad code!
{
  static Rational result;             // static object to which a
                                      // reference will be returned
  result = ... ;                      // multiply lhs by rhs and put the
                                      // product inside result
  return result;
}
Rational a, b, c, d;
...
if ((a * b) == (c * d))  {       //条件判断不符合预期
    do whatever's appropriate when the products are equal;
} else    {
   do whatever's appropriate when they're not;
}

11、The right way to write a function that must return a new object is to have that function return a new object. For Rational's operator*, that means either the following code or something essentially equivalent:

inline const Rational operator*(const Rational& lhs, const Rational& rhs)
{
  return Rational(lhs.n * rhs.n, lhs.d * rhs.d);
}

Like all programming languages, C++ allows compiler implementers to apply optimizations to improve the performance of the generated code without changing its observable behavior, and it turns out that in some cases, construction and destruction of operator*'s return value can be safely eliminated. It all boils down to this: when deciding between returning a reference and returning an object, your job is to make the choice that offers correct behavior. Let your compiler vendors wrestle with figuring out how to make that choice as inexpensive as possible.

12、Things to Remember

• Never return a pointer or reference to a local stack object, a reference to a heap-allocated object, or a pointer or reference to a local static object if there is a chance that more than one such object will be needed. (Item 4 provides an example of a design where returning a reference to a local static is reasonable, at least in single-threaded environments.)