Item 17：理解特殊成員函式的生成規則 (Understand Special Member Function Generation)

Overview Table

特殊成員函式（special member functions, SMF） 是編譯器願意自行生成的成員函式。C++98 有四個（default constructor、destructor、copy constructor、copy assignment operator），C++11 新增兩個：move constructor 與 move assignment operator。生成的 SMF 一律是 public、inline、非 virtual（唯一例外：基底類別 destructor 為 virtual 時，衍生類別生成的 destructor 也是 virtual）。

六個 SMF 的 C++11 生成規則

class Widget {
public:
  Widget(Widget&& rhs);             // move constructor
  Widget& operator=(Widget&& rhs);  // move assignment operator
};

• 兩個 copy 操作彼此獨立：宣告其中一個，不妨礙編譯器生成另一個（C++98 與 C++11 皆然）。
• 兩個 move 操作彼此不獨立：宣告其中一個，另一個就不會生成——因為自訂 move ctor 暗示 memberwise move 對此類別不正確，那麼 memberwise move assignment 大概也不正確。

生成規則的互相影響與 Rule of Three

              編譯器是否生成 move operations？
              ────────────────────────────────
  類別宣告了 copy 操作？ ──是──▶ move 不生成（move 請求退回 copy）
       │ 否
  類別宣告了 move 操作？ ──是──▶ 另一個 move 不生成；
       │ 否                       兩個 copy 操作被 =delete
  類別宣告了 destructor？──是──▶ move 不生成
       │ 否                      （copy 仍生成，但已 deprecated）
       ▼
  （需要時）生成 memberwise move

• 宣告 copy 操作 → 抑制 move 生成：memberwise copy 不適用，memberwise move 大概也不適用。
• 宣告 move 操作 → copy 操作被 delete（機制見 Item 11 的 =delete）：memberwise move 不對，memberwise copy 也不會對。這不會破壞 C++98 舊碼——舊碼不可能有 move 操作，會加 move 的類別就必須遵守 C++11 規則。
• Rule of Three：宣告了 copy ctor、copy assign、destructor 其中之一，就該三個全部宣告——自訂 copy 幾乎都源自資源管理，而 destructor 通常也參與（釋放資源）。推論：有使用者宣告的 destructor，代表 memberwise copy 很可能不正確 → 這正是 C++11 「有 dtor 就不生成 move」的理論依據。

= default：明確要求預設行為

若編譯器生成的行為正確（memberwise 就是你要的），用 C++11 的 = default 明確聲明。典型場景是多型基底類別：需要 virtual destructor，但宣告 dtor 會抑制 move，宣告 move 又會 delete copy——於是層層 = default 補回來：

class Base {
public:
  virtual ~Base() = default;               // 讓 dtor 成為 virtual

  Base(Base&&) = default;                  // 支援 move
  Base& operator=(Base&&) = default;

  Base(const Base&) = default;             // 支援 copy
  Base& operator=(const Base&) = default;
};

即使編譯器願意生成且行為正確，主動宣告 + = default 仍是好政策：意圖更清楚，還能避開隱蔽 bug——

class StringTable {
public:
  StringTable()
  { makeLogEntry("Creating StringTable object"); }   // 後來加入 logging

  ~StringTable()                                     // 也加了 dtor —— 問題就在這
  { makeLogEntry("Destroying StringTable object"); }

private:
  std::map<int, std::string> values;
};

成員函式模板不抑制 SMF 生成

class Widget {
  template<typename T>                 // 可從任何型別建構 Widget
  Widget(const T& rhs);

  template<typename T>                 // 可從任何型別賦值
  Widget& operator=(const T& rhs);
};

即使 T = Widget 時模板可實例化出與 copy ctor / copy assign 相同的簽章，成員函式模板永遠不算「使用者宣告的 copy/move 操作」，編譯器照常生成 copy 與 move 操作（在一般條件滿足時）。看似邊角案例，但 Item 26 證明它有重要後果（生成的 copy ctor 與模板會同時參與 overload resolution）。

Exam/Test Patterns

Related Notes

• 04-Moving-To-Modern-Cpp/05-Deleted-Functions — 宣告 move 操作時，copy 操作正是以 = delete 的機制被停用
• 04-Moving-To-Modern-Cpp/08-Noexcept — 編譯器生成的 destructor 與 SMF 預設為 noexcept
• 06-Move-Semantics-And-Perfect-Forwarding/07-Move-Operation-Realities — 假設 move 不存在、不便宜、沒被用到：本 Item 的生成規則是主因之一
• 06-Move-Semantics-And-Perfect-Forwarding/01-Std-Move-And-Std-Forward — memberwise move 的核心是對成員套用 std::move 後的 overload resolution
• 06-Move-Semantics-And-Perfect-Forwarding/04-Overloading-On-Universal-References — 成員模板不抑制 SMF 生成所引發的 overload resolution 陷阱
• 05-Smart-Pointers/05-Pimpl-Idiom — Pimpl 類別中 SMF 必須在實作檔定義的實例