陳碩 (giantchen_AT_gmail)
http://blog.csdn.net/Solstice http://weibo.com/giantchen
陳碩關於 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 署名-非商業性使用-禁止演繹 3.0 Unported 許可協議(cc by-nc-nd)”進行許可。http://creativecommons.org/licenses/by-nc-nd/3.0/

本文是前一篇《C++ 工程實踐(7)：iostream 的用途與侷限》的後續，在這篇文章的“iostream 與標準庫其他組件的交互”一節，我簡單地提到iostream的對象和C++標準庫中的其他對象（主要是容器和string）具有不同的語義，主要體現在iostream不能拷貝或賦值。今天全面談一談我對這個問題的理解。

本文的“對象”定義較爲寬泛，a region of memory that has a type，在這個定義下，int、double、bool 變量都是對象。

如果出現排版錯亂，請移步： http://www.cnblogs.com/Solstice/archive/2011/08/16/2141515.html

什麼是值語義

值語義(value sematics)指的是對象的拷貝與原對象無關，就像拷貝 int 一樣。C++ 的內置類型(bool/int/double/char)都是值語義，標準庫裏的 complex<> 、pair<>、vector<>、map<>、string 等等類型也都是值語意，拷貝之後就與原對象脫離關係。Java 語言的 primitive types 也是值語義。

與值語義對應的是“對象語義/object sematics”，或者叫做引用語義(reference sematics)，由於“引用”一詞在 C++ 裏有特殊含義，所以我在本文中使用“對象語義”這個術語。對象語義指的是面向對象意義下的對象，對象拷貝是禁止的。例如 muduo 裏的 Thread 是對象語義，拷貝 Thread 是無意義的，也是被禁止的：因爲 Thread 代表線程，拷貝一個 Thread 對象並不能讓系統增加一個一模一樣的線程。

同樣的道理，拷貝一個 Employee 對象是沒有意義的，一個僱員不會變成兩個僱員，他也不會領兩份薪水。拷貝 TcpConnection 對象也沒有意義，系統裏邊只有一個 TCP 連接，拷貝 TcpConnection 對象不會讓我們擁有兩個連接。Printer 也是不能拷貝的，系統只連接了一個打印機，拷貝 Printer 並不能憑空增加打印機。凡此總總，面向對象意義下的“對象”是 non-copyable。

Java 裏邊的 class 對象都是對象語義/引用語義。ArrayList<Integer> a = new ArrayList<Integer>(); ArrayList<Integer> b = a; 那麼 a 和 b 指向的是同一個ArrayList 對象，修改 a 同時也會影響 b。

值語義與 immutable 無關。Java 有 value object 一說，按(PoEAA 486)的定義，它實際上是 immutable object，例如 String、Integer、BigInteger、joda.time.DateTime 等等（因爲 Java 沒有辦法實現真正的值語義 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 的成員，因此我們不用擔心它的生命期（一個函數使用自己stack上的對象，一個成員函數使用自己的數據成員對象）。相反，對象語義的 object 由於不能拷貝，我們只能通過指針或引用來使用它。

一旦使用指針和引用來操作對象，那麼就要擔心所指的對象是否已被釋放，這一度是 C++ 程序 bug 的一大來源。此外，由於 C++ 只能通過指針或引用來獲得多態性，那麼在C++裏從事基於繼承和多態的面向對象編程有其本質的困難——資源管理。

考慮一個簡單的對象建模——家長與子女：a Parent has a Child, a Child knows his/her Parent。在 Java 裏邊很好寫，不用擔心內存泄漏，也不用擔心空懸指針：

public class Parent
{
    private Child myChild;
}
    
public class Child
{
    private Parent myParent;
}

只要正確初始化 myChild 和 myParent，那麼 Java 程序員就不用擔心出現訪問錯誤。一個 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;
};

如果直接使用指針作爲成員，那麼如何確保指針的有效性？如何防止出現空懸指針？Child 和 Parent 由誰負責釋放？在釋放某個 Parent 對象的時候，如何確保程序中沒有指向它的指針？在釋放某個 Child 對象的時候，如何確保程序中沒有指向它的指針？

這一系列問題一度是C++面向對象編程頭疼的問題，不過現在有了 smart pointer，我們可以藉助 smart pointer 把對象語義轉換爲值語義，從而輕鬆解決對象生命期：讓 Parent 持有 Child 的 smart pointer，同時讓 Child 持有 Parent 的 smart pointer，這樣始終引用對方的時候就不用擔心出現空懸指針。當然，其中一個 smart pointer 應該是 weak reference，否則會出現循環引用，導致內存泄漏。到底哪一個是 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 的指針不能泄露給外界，否則仍然有可能出現空懸指針。

如果 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++ 來實現，如何才能避免出現空懸指針，同時避免出現內存泄漏呢？藉助 shared_ptr 把裸指針轉換爲值語義，我們就不用擔心這兩個問題了：

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++ 做面向對象編程將會困難重重。

值語義與標準庫

C++ 要求凡是能放入標準容器的類型必須具有值語義。準確地說：type 必須是 SGIAssignable concept 的 model。但是，由於C++ 編譯器會爲 class 默認提供 copy constructor 和 assignment operator，因此除非明確禁止，否則 class 總是可以作爲標準庫的元素類型——儘管程序可以編譯通過，但是隱藏了資源管理方面的 bug。

因此，在寫一個 class 的時候，先讓它繼承 boost::noncopyable，幾乎總是正確的。

在現代 C++ 中，一般不需要自己編寫 copy constructor 或 assignment operator，因爲只要每個數據成員都具有值語義的話，編譯器自動生成的 member-wise copying&assigning 就能正常工作；如果以 smart ptr 爲成員來持有其他對象，那麼就能自動啓用或禁用 copying&assigning。例外：編寫 HashMap 這類底層庫時還是需要自己實現 copy control。

值語義與C++語言

C++ 的 class 本質上是值語義的，這纔會出現 object slicing 這種語言獨有的問題，也纔會需要程序員注意 pass-by-value 和 pass-by-const-reference 的取捨。在其他面向對象編程語言中，這都不需要費腦筋。

值語義是C++語言的三大約束之一，C++ 的設計初衷是讓用戶定義的類型(class)能像內置類型(int)一樣工作，具有同等的地位。爲此C++做了以下設計（妥協）：

class 的 layout 與 C struct 一樣，沒有額外的開銷。定義一個“只包含一個 int 成員的 class ”的對象開銷和定義一個 int 一樣。
甚至 class data member 都默認是 uninitialized，因爲函數局部的 int 是 uninitialized。
class 可以在 stack 上創建，也可以在 heap 上創建。因爲 int 可以是 stack variable。
class 的數組就是一個個 class 對象挨着，沒有額外的 indirection。因爲 int 數組就是這樣。
編譯器會爲 class 默認生成 copy constructor 和 assignment operator。其他語言沒有 copy constructor 一說，也不允許重載 assignment operator。C++ 的對象默認是可以拷貝的，這是一個尷尬的特性。
當 class type 傳入函數時，默認是 make a copy （除非參數聲明爲 reference）。因爲把 int 傳入函數時是 make a copy。
當函數返回一個 class type 時，只能通過 make a copy（C++ 不得不定義 RVO 來解決性能問題）。因爲函數返回 int 時是 make a copy。
以 class type 爲成員時，數據成員是嵌入的。例如 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 分別是複數的實部和虛部。）

而如果我們在 Java 裏幹同樣的事情，layout 大不一樣，memory locality 也差很多：

Java 裏邊每個 object 都有 header，至少有兩個 word 的開銷。對比 Java 和 C++，可見 C++ 的對象模型要緊湊得多。

待續

下一篇文章我會談與值語義緊密相關的數據抽象(data abstraction)，解釋爲什麼它是與面向對象並列的一種編程範式，爲什麼支持面向對象的編程語言不一定支持數據抽象。C++在最初的時候是以 data abstraction 爲賣點，不過隨着時間的流逝，現在似乎很多人只知 Object-Oriented，不知 data abstraction 了。C++ 的強大之處在於“抽象”不以性能損失爲代價，下一篇文章我們將看到具體例子。

陳碩

發佈了145 篇原創文章 · 獲贊 114 · 訪問量 363萬+

他的留言板關注

C++ 工程實踐(8)：值語義

什麼是值語義

值語義與生命期

值語義與標準庫

值語義與C++語言

待續

從《C++ Primer 第四版》入手學習 C++

C++ 工程實踐(12)：C++ 編譯鏈接模型精要

發佈適合服務端C++程序的高效日誌庫

《Muduo 網絡庫：現代非阻塞C++網絡編程》演講

C++ 工程實踐(7)：iostream 的用途與侷限

Mac下配置sublime實現LaTeX

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結