在上篇文章中，我提到了這樣一個觀點：作者在採取修訂的方式寫書的時候，把新的內容自然地融入到全書當中，比直接把所有新內容砸到一個章節裡顯得更加合理。不過採取這樣的做法，會給讀者的學習造成一定的困難，尤其是在新加入的內容使得原有的知識更加抽象的前提下——根據我與C++打交道30年來的經驗，C++的發展一直是讓這門語言越來越抽象的。
下面舉個例子說明這種現象。給C語言加上類的支援的最初目的，是為了讓C++類能夠向上相容C的結構體。尤其是，在早期版本的拷貝建構函式裡（大約是1984年左右的版本），如果沒有顯示定義拷貝建構函式，那麼拷貝一個類的時候，僅僅是拷貝其內部的C結構體。那時的程式設計師管這種操作叫“按位拷貝”（bitwise copy）。這種拷貝行為在下面的例子中會產生問題：
|
1 2 3 |
struct Person { String firstname, lastname; }; |
當時還沒有標準的string庫，因此我使用String這個名字來強調這是一個使用者自定義的類，用來實現多字元的串結構。
在早期的C++版本中，這個類將會成為一個災難。因為String 類很可能包含了一個指標，這個指標會直接指向存放字串內容的地址，指標在對Person物件進行拷貝時不會被簡單地拷貝過去。這麼做可能導致的結果就是，記憶體中的字串和可能會面臨兩次free操作，一次是針對原來的Person物件，另一次是針對Person物件的拷貝。如此一來，使用這個版本C++的程式設計師就必須提供顯示的拷貝建構函式來避免這個問題。
|
1 2 3 4 5 6 |
struct Person { Person(const Person& p): firstname(p.firstname), lastname(p.lastname) { } // and so on String firstname, lastname; }; |
所有早期C++版本的教學材料都會教給你上面的技術，因為如果你不這麼做的話，即使最簡單的抽象過程也會導致嚴重的bug。顯然，這些複雜的語言特性和隨之帶來的不便推動了對C++語言預設行為的改進：在進行預設物件拷貝時，不會再直接拷貝類的C結構體，C++編譯器會遍歷源類的結構，並遞迴地拷貝所有物件元素到目標物件。
Barbara Moo——《C++ Primer 5th edition》的作者
設想如果你就是書的作者。通過你的書，你的程式練習例子，讀者卻感到使用顯示拷貝建構函式是那麼的困難，這多糟糕！還好，現在這門語言已經改進了，所有這些累贅的程式碼都不需要了。但是這時，還需要你作者幹什麼呢？
作為作者，你可以遍歷全書，精於細節，找到每一個例子中曾經用到過那些累贅程式碼的片段，並進行簡化或者徹底刪掉重寫，讓各種細節都更加合理。或者，你可以增加一些章節，比如像“如何使用XXX新特性”這樣的章節，用來向讀者說明，之前的那些繁文縟節的程式碼已經不再需要了。
儘管第二個做法看上去比第一個做法要省力很多，但是修訂版（第五版）的《C++ Primer》卻採用了第一種策略。在C++11的語法中，很多程式碼的書寫方式已經被簡化了，不需要再像以前那麼麻煩了。這個特性會在很大程度上影響到本書對於C++11關鍵知識點的介紹順序。下週，我們會用具體的示例，來探討一下C++語言究竟有哪些改變。
英文原文：Andrew Koenig 編譯：伯樂線上 – 黃小非
【如需轉載，請標註並保留原文連結、譯文連結和譯者等資訊，謝謝合作！】