邁向現代 C++練習題 (Practice - Moving to Modern C++)

w1 與 w2{} 都呼叫預設建構子——空大括號的意義是「沒有引數」，不是「空的 std::initializer_list」。
w3() 是 most vexing parse：宣告一個回傳 Widget 的函式，不是物件（函式參數列不能用 {} 宣告，故 {} 免疫此問題）。
想傳空 list，必須把空大括號變成建構子引數：Widget w4({}); 或 Widget w5{{}};。

v1 是 10 個元素、每個值 20（非 initializer_list 建構子）；v2 是兩個元素 10、20（initializer_list 建構子）。
規則：只要有任何辦法把 {} 中的引數轉換成 std::initializer_list 的元素型別，編譯器就強烈優先選 initializer_list 建構子——即使其他建構子匹配更佳，連 copy/move 建構都可能被劫持；若匹配上但需要 narrowing conversion，直接編譯錯誤而非 fallback。
只有引數完全無法轉換成元素型別（如 int → std::string）時，才回到正常 overload resolution。

f(0) 呼叫 f(int)——0 的本質是 int，只有在非指標不可的語境才 fallback 成 null pointer。
f(NULL) 可能編譯失敗（若 NULL 是 0L，long→int、long→bool、0L→void* 三種轉換同樣好而歧義），通常呼叫 f(int)，絕不會呼叫 f(void*)。
f(nullptr) 呼叫 f(void*)——nullptr 的型別是 std::nullptr_t，可隱式轉換為所有 raw pointer 型別，且無法被視為整數。配套守則：避免同時 overload 整數與指標型別。

r1、r2 編譯失敗；r3 成功。
0 被推導為 int、NULL 被推導為某整數型別——deduction 推導出的是它們的「真實型別」而非 fallback 的指標意義，int 無法轉成 std::shared_ptr<Widget> / std::unique_ptr<Widget> → 型別錯誤。
nullptr 被推導為 std::nullptr_t，可隱式轉換為 Widget* → 通過。這是「想表達 null pointer 一律用 nullptr」最有力的理由：直接呼叫 f1(0) 合法（語境明確要求指標），但經 template 轉手即失效。

決定性理由是模板化能力：alias declaration 可模板化成 alias template；typedef 只能巢狀塞進模板化 struct、以 MyAllocList<T>::type 存取（函式指標可讀性只是次要理由）。
模板內：巢狀 typedef 是 dependent type（可能有特化讓 ::type 不是型別），必須寫 typename MyAllocList<T>::type；alias template 是 non-dependent type，直接寫 MyAllocList<T>——typename 不需要也不允許。
同一演進：C++11 type traits 的 std::transformation<T>::type → C++14 alias template 版 std::transformation_t<T>。

enum Color; 編譯錯誤；enum class Status; 合法——scoped enum 永遠可前向宣告，因為底層型別永遠已知（預設 int）。
unscoped enum 沒有預設底層型別（編譯器針對每個 enum 自選），但指定底層型別後也能前向宣告：enum Color: std::uint8_t;。
最大好處是降低編譯依賴：enum 定義改動（如新增列舉子）時，只 include 前向宣告的檔案不必重編，避免全系統重新編譯。

三大優勢：(1) 一律編譯期報錯——member/friend 誤用 private 未定義版本要到 link 期才失敗；(2) 任何函式都能刪——non-member 函式（如 bool isLucky(double) = delete; 擋掉 double 與 float）與 template instantiation（如 processPointer<void> / <char>），private 只能用於 member functions；(3) 模板特化必須寫在 namespace scope、不能有不同存取層級，private 手法對 member template 特化完全失效。
宣告 public 的原因：C++ 先檢查存取權限、後檢查 deleted 狀態，private 的 deleted 函式在部分編譯器只報「函式是 private」，public 才能得到準確的錯誤訊息。

mf1：base 是 const、derived 不是 → constness 不同；mf2：int vs unsigned int → 參數型別不同；mf3：& vs && → reference qualifier 不同（C++11 新增的覆寫條件）；mf4：base 端根本不是 virtual。
四個函式都只是「同名新函式」，透過 Base 介面呼叫到的仍是 base 版本，且編譯器可能毫無警告（Meyers 實測兩款編譯器全警告開啟下無怨言）。
全部加上 override 後四個都變成編譯錯誤——這正是想要的效果：想覆寫卻沒覆寫成功時立即現形，也讓「修改 base virtual 簽章」的影響範圍可用重新編譯量化。

兩件事：(1) 成員函式 cbegin/cend 對 non-const 容器也回傳 const_iterator；(2) insert/erase 等指定位置的成員函式改為接受 const_iterator。
最大化泛型程式碼應用 non-member 版本 begin(container)/cbegin(container)（內建陣列與只有 free function 介面的第三方庫沒有成員版本）。
C++11 沒有 non-member cbegin（標準化疏漏，只加了 begin/end），C++14 才補齊；C++11 可自製——對 reference-to-const 參數呼叫 std::begin，const 容器的 begin 自然回傳 const_iterator。
另注意：const_iterator 無法可攜地轉回 iterator，任何 cast 都不行。

noexcept：stack 只是可能回溯（possibly unwound）後終止——優化器不必維持 runtime stack 的可回溯狀態、不必保證物件依建構反序解構 → 最可優化；throw()（已棄用）必定回溯到呼叫端，與無例外規格同樣較不可優化。
大多數函式是 exception-neutral：自己不丟例外，但被呼叫者的例外要「過境」傳往上層 handler → 永遠不該 noexcept；也不要扭曲實作（例外改錯誤碼）硬換 noexcept。
解構子與記憶體釋放函式（operator delete / delete[]）預設隱含 noexcept（唯一例外：某資料成員的解構子明確宣告 noexcept(false)）。noexcept 是介面的一部分，屬長期承諾。

會用 copy。C++98 的 push_back 以逐一複製提供 strong exception safety guarantee（複製途中丟例外，原 vector 不變）；若改用 move，第 n+1 個元素 move 時丟例外，已被搬走的 n 個元素無法安全復原（move 回去也可能再丟例外），保證即遭破壞。
因此標準庫採「move if you can, but copy if you must」：只有 move 操作已知不丟例外時才以 move 取代 copy。檢查鏈：push_back → std::move_if_noexcept → std::is_nothrow_move_constructible type trait → 由 move ctor 是否宣告 noexcept（或 throw()）決定。
結論：替 Widget 的 move ctor 加上 noexcept，擴容才會真正 move——這是「為 move 操作宣告 noexcept」最強烈的理由；std::vector::reserve、std::deque::insert 等同理。

不能編譯。const 只保證唯讀，不保證值在編譯期已知（可用執行期值初始化）；std::array 大小要求編譯期常量，只能靠 constexpr。
constexpr 物件：必為 const，且以編譯期已知的值初始化，可放唯讀記憶體、當陣列大小 / template 引數 / enumerator 值。
constexpr 函式：雙模式——引數全為編譯期常量時產生編譯期結果；任一引數為執行期值時退化為普通函式執行期計算。記法：所有 constexpr 物件都是 const，反之不成立；且不能假設 constexpr 函式的結果是 const 或編譯期已知——這是特性非缺陷。

不夠，應改用 std::mutex。一對 atomic 無論寫入順序都有問題：先寫 cachedValue 再設 cacheValid → 其他執行緒在旗標設定前看到 false，重複執行昂貴計算；先設 cacheValid 再寫 cachedValue → 其他執行緒看到 true 卻讀到尚未賦值的錯誤值（更糟）。
準則：單一變數/記憶體位置 → std::atomic；兩個以上需作為一個單位操作 → std::mutex（以 std::lock_guard 涵蓋整段「檢查—計算—寫入」）。
附帶注意：mutex 須宣告 mutable（lock/unlock 是 non-const 操作）；且 std::mutex 與 std::atomic 都是 move-only，加入後類別失去可複製性。

原因：move 生成的三條件是「無使用者宣告的 copy 操作、無 move 操作、無 destructor」——加入解構子後 move 操作不再生成，但 copy 操作照舊生成（僅標記 deprecated）。所有「move」StringTable 的程式碼依然合法：move 請求經 overload resolution 退回 copy，實際在複製底層的 std::map<int, std::string>，可能比 move 慢幾個數量級——因為語意正確、只是變慢，編譯與功能測試都抓不到。
修正：以 = default 明確宣告 move 與 copy 操作（StringTable(StringTable&&) = default; 等四個），意圖清楚且不受日後加 dtor 影響。多型基底類別的標準寫法同理：virtual ~Base() = default; + 四個 copy/move = default。
延伸：宣告 move 會使 copy 被 = delete；兩個 copy 操作彼此獨立、兩個 move 操作彼此不獨立；成員函式模板永遠不抑制 SMF 生成。