陳碩 (giantchen_AT_gmail)
http://blog.csdn.net/Solstice http://weibo.com/giantchen
陳碩關(guān)于 C++ 工程實踐的系列文章： http://blog.csdn.net/Solstice/category/802325.aspx
排版正常的版本： http://www.cnblogs.com/Solstice/category/287661.html
陳碩博客文章合集下載： http://blog.csdn.net/Solstice/archive/2011/02/24/6206154.aspx
本作品采用“Creative Commons 署名-非商業(yè)性使用-禁止演繹 3.0 Unported 許可協(xié)議(cc by-nc-nd)”進行許可。http://creativecommons.org/licenses/by-nc-nd/3.0/
本文是前一篇《C++ 工程實踐(7)：iostream 的用途與局限》的后續(xù)，在這篇文章的“iostream 與標準庫其他組件的交互”一節(jié)，我簡單地提到iostream的對象和C++標準庫中的其他對象（主要是容器和string）具有不同的語義，主要體現(xiàn)在iostream不能拷貝或賦值。今天全面談一談我對這個問題的理解。
本文的“對象”定義較為寬泛，a region of memory that has a type，在這個定義下，int、double、bool 變量都是對象。
什么是值語義
值語義(value sematics)指的是對象的拷貝與原對象無關(guān)，就像拷貝 int 一樣。C++ 的內(nèi)置類型(bool/int/double/char)都是值語義，標準庫里的 complex<> 、pair<>、vector<>、map<>、string 等等類型也都是值語意，拷貝之后就與原對象脫離關(guān)系。Java 語言的 primitive types 也是值語義。
與值語義對應的是“對象語義/object sematics”，或者叫做引用語義(reference sematics)，由于“引用”一詞在 C++ 里有特殊含義，所以我在本文中使用“對象語義”這個術(shù)語。對象語義指的是面向?qū)ο笠饬x下的對象，對象拷貝是禁止的。例如 muduo 里的 Thread 是對象語義，拷貝 Thread 是無意義的，也是被禁止的：因為 Thread 代表線程，拷貝一個 Thread 對象并不能讓系統(tǒng)增加一個一模一樣的線程。
同樣的道理，拷貝一個 Employee 對象是沒有意義的，一個雇員不會變成兩個雇員，他也不會領(lǐng)兩份薪水。拷貝 TcpConnection 對象也沒有意義，系統(tǒng)里邊只有一個 TCP 連接，拷貝 TcpConnection 對象不會讓我們擁有兩個連接。Printer 也是不能拷貝的，系統(tǒng)只連接了一個打印機，拷貝 Printer 并不能憑空增加打印機。凡此總總，面向?qū)ο笠饬x下的“對象”是 non-copyable。
Java 里邊的 class 對象都是對象語義/引用語義。ArrayList<Integer> a = new ArrayList<Integer>(); ArrayList<Integer> b = a; 那么 a 和 b 指向的是同一個ArrayList 對象，修改 a 同時也會影響 b。
值語義與 immutable 無關(guān)。Java 有 value object 一說，按(PoEAA 486)的定義，它實際上是 immutable object，例如 String、Integer、BigInteger、joda.time.DateTime 等等（因為 Java 沒有辦法實現(xiàn)真正的值語義 class，只好用 immutable object 來模擬）。盡管 immutable object 有其自身的用處，但不是本文的主題。muduo 中的 Date、Timestamp 也都是 immutable 的。
C++中的值語義對象也可以是 mutable，比如 complex<>、pair<>、vector<>、map<>、string 都是可以修改的。muduo 的 InetAddress 和 Buffer 都具有值語義，它們都是可以修改的。
值語義的對象不一定是 POD，例如 string 就不是 POD，但它是值語義的。
值語義的對象不一定小，例如 vector<int> 的元素可多可少，但它始終是值語義的。當然，很多值語義的對象都是小的，例如complex<>、muduo::Date、muduo::Timestamp。
值語義與生命期
值語義的一個巨大好處是生命期管理很簡單，就跟 int 一樣——你不需要操心 int 的生命期。值語義的對象要么是 stack object，或者直接作為其他 object 的成員，因此我們不用擔心它的生命期（一個函數(shù)使用自己stack上的對象，一個成員函數(shù)使用自己的數(shù)據(jù)成員對象）。相反，對象語義的 object 由于不能拷貝，我們只能通過指針或引用來使用它。
一旦使用指針和引用來操作對象，那么就要擔心所指的對象是否已被釋放，這一度是 C++ 程序 bug 的一大來源。此外，由于 C++ 只能通過指針或引用來獲得多態(tài)性，那么在C++里從事基于繼承和多態(tài)的面向?qū)ο缶幊逃衅浔举|(zhì)的困難——資源管理。
考慮一個簡單的對象建模——家長與子女：a Parent has a Child, a Child knows his/her Parent。在 Java 里邊很好寫，不用擔心內(nèi)存泄漏，也不用擔心空懸指針：
public class Parent
{
private Child myChild;
}
public class Child
{
private Parent myParent;
}
只要正確初始化 myChild 和 myParent，那么 Java 程序員就不用擔心出現(xiàn)訪問錯誤。一個 handle 是否有效，只需要判斷其是否 non null。
在 C++ 里邊就要為資源管理費一番腦筋：Parent 和 Child 都代表的是真人，肯定是不能拷貝的，因此具有對象語義。Parent 是直接持有 Child 嗎？抑或 Parent 和 Child 通過指針互指？Child 的生命期由 Parent 控制嗎？如果還有 ParentClub 和 School 兩個 class，分別代表家長俱樂部和學校：ParentClub has many Parent(s)，School has many Child(ren)，那么如何保證它們始終持有有效的 Parent 對象和 Child 對象？何時才能安全地釋放 Parent 和 Child ？
直接但是易錯的寫法：
class Child;
class Parent : boost::noncopyable
{
private:
Child* myChild;
};
class Child : boost::noncopyable
{
private:
Parent* myParent;
};
如果直接使用指針作為成員，那么如何確保指針的有效性？如何防止出現(xiàn)空懸指針？Child 和 Parent 由誰負責釋放？在釋放某個 Parent 對象的時候，如何確保程序中沒有指向它的指針？在釋放某個 Child 對象的時候，如何確保程序中沒有指向它的指針？
這一系列問題一度是C++面向?qū)ο缶幊填^疼的問題，不過現(xiàn)在有了 smart pointer，我們可以借助 smart pointer 把對象語義轉(zhuǎn)換為值語義，從而輕松解決對象生命期：讓 Parent 持有 Child 的 smart pointer，同時讓 Child 持有 Parent 的 smart pointer，這樣始終引用對方的時候就不用擔心出現(xiàn)空懸指針。當然，其中一個 smart pointer 應該是 weak reference，否則會出現(xiàn)循環(huán)引用，導致內(nèi)存泄漏。到底哪一個是 weak reference，則取決于具體應用場景。
如果 Parent 擁有 Child，Child 的生命期由其 Parent 控制，Child 的生命期小于 Parent，那么代碼就比較簡單：
class Parent;
class Child : boost::noncopyable
{
public:
explicit Child(Parent* myParent_)
: myParent(myParent_)
{
}
private:
Parent* myParent;
};
class Parent : boost::noncopyable
{
public:
Parent()
: myChild(new Child(this))
{
}
private:
boost::scoped_ptr<Child> myChild;
};
在上面這個設計中，Child 的指針不能泄露給外界，否則仍然有可能出現(xiàn)空懸指針。
如果 Parent 與 Child 的生命期相互獨立，就要麻煩一些：
class Parent;
typedef boost::shared_ptr<Parent> ParentPtr;
class Child : boost::noncopyable
{
public:
explicit Child(const ParentPtr& myParent_)
: myParent(myParent_)
{
}
private:
boost::weak_ptr<Parent> myParent;
};
typedef boost::shared_ptr<Child> ChildPtr;
class Parent : public boost::enable_shared_from_this<Parent>,
private boost::noncopyable
{
public:
Parent()
{
}
void addChild()
{
myChild.reset(new Child(shared_from_this()));
}
private:
ChildPtr myChild;
};
int main()
{
ParentPtr p(new Parent);
p->addChild();
}
上面這個 shared_ptr+weak_ptr 的做法似乎有點小題大做。
考慮一個稍微復雜一點的對象模型：a Child has parents: mom and dad; a Parent has one or more Child(ren); a Parent knows his/her spouser. 這個對象模型用 Java 表述一點都不復雜，垃圾收集會幫我們搞定對象生命期。
public class Parent
{
private Parent mySpouser;
private ArrayList<Child> myChildren;
}
public class Child
{
private Parent myMom;
private Parent myDad;
}
如果用 C++ 來實現(xiàn)，如何才能避免出現(xiàn)空懸指針，同時避免出現(xiàn)內(nèi)存泄漏呢？借助 shared_ptr 把裸指針轉(zhuǎn)換為值語義，我們就不用擔心這兩個問題了：
class Parent;
typedef boost::shared_ptr<Parent> ParentPtr;
class Child : boost::noncopyable
{
public:
explicit Child(const ParentPtr& myMom_,
const ParentPtr& myDad_)
: myMom(myMom_),
myDad(myDad_)
{
}
private:
boost::weak_ptr<Parent> myMom;
boost::weak_ptr<Parent> myDad;
};
typedef boost::shared_ptr<Child> ChildPtr;
class Parent : boost::noncopyable
{
public:
Parent()
{
}
void setSpouser(const ParentPtr& spouser)
{
mySpouser = spouser;
}
void addChild(const ChildPtr& child)
{
myChildren.push_back(child);
}
private:
boost::weak_ptr<Parent> mySpouser;
std::vector<ChildPtr> myChildren;
};
int main()
{
ParentPtr mom(new Parent);
ParentPtr dad(new Parent);
mom->setSpouser(dad);
dad->setSpouser(mom);
{
ChildPtr child(new Child(mom, dad));
mom->addChild(child);
dad->addChild(child);
}
{
ChildPtr child(new Child(mom, dad));
mom->addChild(child);
dad->addChild(child);
}
}
如果不使用 smart pointer，用 C++ 做面向?qū)ο缶幊虒щy重重。
值語義與標準庫
C++ 要求凡是能放入標準容器的類型必須具有值語義。準確地說：type 必須是 SGIAssignable concept 的 model。但是，由 于C++ 編譯器會為 class 默認提供 copy constructor 和 assignment operator，因此除非明確禁止，否則 class 總是可以作為標準庫的元素類型——盡管程序可以編譯通過，但是隱藏了資源管理方面的 bug。
因此，在寫一個 class 的時候，先讓它繼承 boost::noncopyable，幾乎總是正確的。
在現(xiàn)代 C++ 中，一般不需要自己編寫 copy constructor 或 assignment operator，因為只要每個數(shù)據(jù)成員都具有值語義的話，編譯器自動生成的 member-wise copying&assigning 就能正常工作；如果以 smart ptr 為成員來持有其他對象，那么就能自動啟用或禁用 copying&assigning。例外：編寫 HashMap 這類底層庫時還是需要自己實現(xiàn) copy control。
值語義與C++語言
C++ 的 class 本質(zhì)上是值語義的，這才會出現(xiàn) object slicing 這種語言獨有的問題，也才會需要程序員注意 pass-by-value 和 pass-by-const-reference 的取舍。在其他面向?qū)ο缶幊陶Z言中，這都不需要費腦筋。
值語義是C++語言的三大約束之一，C++ 的設計初衷是讓用戶定義的類型(class)能像內(nèi)置類型(int)一樣工作，具有同等的地位。為此C++做了以下設計（妥協(xié)）：
- class 的 layout 與 C struct 一樣，沒有額外的開銷。定義一個“只包含一個 int 成員的 class ”的對象開銷和定義一個 int 一樣。
- 甚至 class data member 都默認是 uninitialized，因為函數(shù)局部的 int 是 uninitialized。
- class 可以在 stack 上創(chuàng)建，也可以在 heap 上創(chuàng)建。因為 int 可以是 stack variable。
- class 的數(shù)組就是一個個 class 對象挨著，沒有額外的 indirection。因為 int 數(shù)組就是這樣。
- 編譯器會為 class 默認生成 copy constructor 和 assignment operator。其他語言沒有 copy constructor 一說，也不允許重載 assignment operator。C++ 的對象默認是可以拷貝的，這是一個尷尬的特性。
- 當 class type 傳入函數(shù)時，默認是 make a copy （除非參數(shù)聲明為 reference）。因為把 int 傳入函數(shù)時是 make a copy。
- 當函數(shù)返回一個 class type 時，只能通過 make a copy（C++ 不得不定義 RVO 來解決性能問題）。因為函數(shù)返回 int 時是 make a copy。
- 以 class type 為成員時，數(shù)據(jù)成員是嵌入的。例如 pair<complex<double>, size_t> 的 layout 就是 complex<double> 挨著 size_t。
這些設計帶來了性能上的好處，原因是 memory locality。比方說我們在 C++ 里定義 complex<double> class，array of complex<double>， vector<complex<double> >，它們的 layout 分別是：（re 和 im 分別是復數(shù)的實部和虛部。）
而如果我們在 Java 里干同樣的事情，layout 大不一樣，memory locality 也差很多：
Java 里邊每個 object 都有 header，至少有兩個 word 的開銷。對比 Java 和 C++，可見 C++ 的對象模型要緊湊得多。
待續(xù)
下一篇文章我會談與值語義緊密相關(guān)的數(shù)據(jù)抽象(data abstraction)，解釋為什么它是與面向?qū)ο蟛⒘械囊环N編程范式，為什么支持面向?qū)ο蟮木幊陶Z言不一定支持數(shù)據(jù)抽象。C++在最初的時候是以 data abstraction 為賣點，不過隨著時間的流逝，現(xiàn)在似乎很多人只知 Object-Oriented，不知 data abstraction 了。C++ 的強大之處在于“抽象”不以性能損失為代價，下一篇文章我們將看到具體例子。