從一開始就讓我們簡化這次的討論。你有兩類你能夠繼承的函數：虛函數和非虛函數。然而，重新定義一個非虛函數總是錯誤的（Item 36），所以我們可以安全的把這個條款的討論限定在繼承帶預設參數值的虛函數上。

1. 虛函數是動態綁定的，而預設參數是靜態綁定的

在這種情況下，這個條款的驗證就相當直接了：虛函數是動態綁定的，而預設參數值是靜態綁定的。

這是什麼？你說你不堪重負的腦袋已經忘記了動態綁定和靜態綁定之間的區別？（為了好記，靜態綁定也叫做早綁定（early binding），動態綁定也叫做晚綁定（late binding））。讓我們看一下：

一個對象的靜態類型是你已經在程式文本中聲明的類型，考慮如下的類繼承體系：

 1 // a class for geometric shapes
 2 class Shape {
 3 public:
 4 enum ShapeColor { Red, Green, Blue };
 5 // all shapes must offer a function to draw themselves
 6 virtual void draw(ShapeColor color = Red) const = 0;
 7 ...
 8 };
 9 
10 class Rectangle: public Shape {
11 public:
12 // notice the different default parameter value — bad!
13 virtual void draw(ShapeColor color = Green) const;
14 ...
15 };
16 class Circle: public Shape {
17 public:
18 virtual void draw(ShapeColor color) const;
19 ...
20 };

畫成類繼承圖會是下麵這個樣子：

現在考慮三個指針：

1 Shape *ps;                               // static type = Shape*
2 
3 Shape *pc = new Circle;           // static type = Shape*
4 
5 Shape *pr = new Rectangle;    // static type = Shape*

在這個例子中，ps,pc和pr都被聲明為指向shape的指針，所以它們用Shape作為它們的靜態類型。註意無論shape指針真正指向的是什麼對象，靜態類型都是Shape*。

一個對象的動態類型由指針當前指向的對象類型來決定。也就是，它的動態類型表明瞭它的行為會是怎樣的。看上面的例子，pc的動態類型是Circle*，pr的動態類型是Rectangle*。對於ps，它實際上沒有動態類型，因為它還沒有引用任何對象。

正如字面意思所表示的，在程式運行時動態類型是可以改變的，特別是通過賦值：

1 ps = pc;      // ps’s dynamic type is now Circle* 
2 ps = pr;      // ps’s dynamic type is now Rectangle*

虛函數是動態綁定的，意味著哪個函數被調用是由發出調用的對象的動態類型來決定的：

1 pc->draw(Shape::Red);          // calls Circle::draw(Shape::Red)
2 
3 pr->draw(Shape::Red);          // calls Rectangle::draw(Shape::Red)

這些都是舊知識了，我知道你肯定瞭解虛函數。當你考慮帶預設參數值的虛函數時，麻煩出現了，因為虛函數是動態綁定的，但是預設參數是靜態綁定的。這意味著你可能會終止一個虛函數的調用，因為函數定義在派生類中卻使用了基類中的預設參數：

1  pr->draw();                           // calls Rectangle::draw(Shape::Red)!

在這種情況中，pr的動態類型是Rectangle*，所以Rectangle的虛函數被調用，這也是你所期望的。在Rectangle::draw中，預設參數值是Green。然而因為pr的靜態類型是Shape*,這個函數調用的預設參數值是來自於Shape類而不是Rectangle類！最後的結果是這個調用由一個奇怪的也幾乎是你意料不到的組合組成：也即是Shape類和Rectangle類中的draw聲明混合而成。

Ps,pc和pr都為指針不是造成這個問題的原因。如果它們是引用也同樣會出現這個問題。唯一重要的事情是draw是一個虛函數，並且預設參數中的一個在派生類中被重新定義了。

2. C++為什麼不對參數進行動態綁定？

為什麼C++堅持用一種反常的方式來運行？答案和運行時效率相關。如果一個預設參數是動態綁定的，編譯器就需要用一種方法在運行時為虛函數參數確定一個合適的預設值，比起當前在編譯期決定這些參數的機制，它更慢更加複雜。做出的決定是更多的考慮了速度和實現的簡單性，結果是你可以享受高效的執行速度，但是如果你沒有註意到這個條款的建議，你就會很迷惑。

3. 個例討論——為基類和派生類提供相同的預設參數

這都很好，但是看看如果這麼做會發生什麼：遵守這個條款的規定並且為基類和派生類函數同時提供預設參數：

 1 class Shape {
 2 
 3 public:
 4 
 5 enum ShapeColor { Red, Green, Blue };
 6 
 7 virtual void draw(ShapeColor color = Red) const = 0;
 8 
 9 ...
10 
11 };
12 
13 class Rectangle: public Shape {
14 public:
15 virtual void draw(ShapeColor color = Red) const;
16 ...
17 };

代碼重覆的問題出現了。更糟糕的是，與代碼重覆問題便隨而來的代碼依賴問題：如果Shape中的預設參數被修改了，所有重覆這個參數的派生類都需要被修改。否則重新定義繼承而來的預設參數值的問題會再度出現。該怎麼做？

當你讓虛函數按照你的方式來運行時遇到了麻煩，考慮替代設計方法是很明智的，Item 35中介紹了替換虛函數的不同方法。其中的一個是非虛介面用法（NVI idiom）：用基類中的public非虛函數調用一個private虛函數，private虛函數可以在派生類中重新被定義。現在，我們用非虛函數指定預設參數，而用虛函數來做實際的工作：

 1 class Shape {
 2 public:
 3 enum ShapeColor { Red, Green, Blue };
 4 
 5 void draw(ShapeColor color = Red) const   // now non-virtual
 6 
 7 {                                                                 
 8 
 9  
10 
11 doDraw(color);                            // calls a virtual
12 
13 }                                                  
14 
15 ...                                                 
16 
17 private:                                       
18 
19 
20 virtual void doDraw(ShapeColor color) const = 0; // the actual work is
21 }; // done in this func
22 class Rectangle: public Shape {
23 public:
24 ...
25 private:
26 
27 virtual void doDraw(ShapeColor color) const; // note lack of a
28 
29 ...                                                                       // default param val.
30 
31 };               

因為非虛函數應該永遠不會在派生類中被重定義（Item 36），這個設計保證draw的color預設參數應該永遠是Red。

4. 總結

永遠不要重新定義一個繼承而來的預設參數值，因為預設參數值是靜態綁定的，而虛函數——你應該重新定義的唯一的函數——是動態綁定的。