微調練習題 (Practice - Tweaks)

值傳遞：lvalue → 1 copy + 1 move；rvalue → 2 moves。
By-reference 方案（overloading / universal reference）：lvalue → 1 copy；rvalue → 1 move。
結論：值傳遞對 lvalue 與 rvalue 恆多一次 move——這正是「cheap to move」是前提條件的原因。

Consider：值傳遞恆有額外成本（且有 assignment、呼叫鏈等隱藏開銷），只能個案評估。
copyable：move-only 型別只需單一 rvalue reference overload，值傳遞反而把 1 move 變 2 moves。
cheap to move：多出的那次 move 若昂貴，等同做了不必要的 copy。
always copied：條件式複製時，不符合條件仍白付參數的建構＋解構成本。

安全的兩個理由：(1) newName 是與呼叫端引數完全獨立的物件，move 它不影響呼叫端；(2) 這是函式內最後一次使用 newName，之後不再讀取。

Slicing problem：值傳遞只複製 base 部分，函式看到的是 Widget 而非 SpecialWidget，衍生類別的特性被「切掉」。
因此 base class 參數型別通常不適合值傳遞——這是效能之外，值傳遞在 C++98 名聲不佳的另一原因。

寫單一 rvalue reference overload：void setPtrstring>&& ptr) { p = std::move(ptr; }，總成本 1 move。
std::unique_ptr 是 move-only：copy ctor 已 delete，本來就不需要 lvalue overload，「只寫一個函式」的優勢不存在。
值傳遞版本會 move construct 參數再 move assign 給成員 = 2 moves，成本加倍。

值傳遞版：newPwd copy construct 需配置新記憶體，move assign 給 text 又釋放 text 舊記憶體 → 一次配置＋一次釋放。
Reference overload 版：text = newPwd 在 text.capacity() >= newPwd.size() 時可重用既有記憶體，零配置零釋放——記憶體管理成本可比一次 move 高數個數量級。
成本取決於：型別是否用動態記憶體、lvalue/rvalue 比例、目標容量是否 ≥ 來源、SSO 是否容納該值——取決於「值」而非只有「型別」（rvalue 幾乎都靠 move，問題主要在 lvalue）。
實務採「有罪推定」：先用 overloading / universal reference，證明值傳遞夠快才採用。

push_back：2 次建構 + 1 次解構——(1) 由字面值建立暫時物件 temp；(2) temp（rvalue）綁定 push_back(T&&) 後 move 建構進 vector；(3) temp 解構。
emplace_back("xyzzy")：字面值被 perfect forwarding 直達容器內部，就地建構僅 1 次，無暫時物件。

Insertion 函式接收「要插入的物件」；emplacement 函式接收「建構物件用的建構子引數」，以 perfect forwarding 直達容器內部建構點。
因此當引數型別與容器元素型別不符時，emplacement 可避免暫時物件的建構與解構——這是它效率優勢的來源。

(1) 新值以「建構」進入容器而非「指派」（如加到尾端的 emplace_back）；
(2) 傳入的引數型別異於容器持有型別（才有暫時物件可省）；
(3) 容器不太可能因重複值而拒絕新值（set/map 常先建 node 再比對，重複則白付建構/解構）。

= 語法是 copy initialization，不可使用 explicit 建構子 → 編譯錯誤；()（或 {}）是 direct initialization，可以使用 explicit 建構子 → 編譯通過（但 null 不是合法 regex 字串，執行期 UB）。
對應到容器：insertion 用 copy init（擋下 explicit 轉換），emplacement 用 direct init（放行）。

emplace_back 把 nullptr 當作 std::regex 的建構子引數，direct initialization 允許呼叫 explicit 的 regex(const char*) 建構子 → 編譯通過，但 null 指標不是合法 regex 字串 → UB（幸運的話當場崩潰）。
push_back(nullptr) 要求 nullptr → std::regex 的隱式轉換（copy init），被 explicit 擋下 → 編譯期即報錯。
教訓：用 emplacement 時要特別確認引數正確——insertion 幫你擋的型別錯誤，emplacement 會滑落到執行期。

問題：raw pointer 被 perfect forwarding 延後交給管理物件，若配置 list node 時拋出例外，尚無任何物件管理該指標 → Widget 洩漏。
正確寫法：先在獨立敘述建立管理物件，再以 rvalue 傳入——
std::shared_ptr<Widget> spw(new Widget, killWidget); ptrs.push_backmove(spw);
此時 node 配置失敗，spw 解構會呼叫 killWidget 釋放資源；且既然都付出 spw 的建構/解構成本，emplacement 已無優勢。

vs.emplace(vs.begin(), ...)：目標位置已有物件，多數實作不會就地建構，而是 move assignment 把值移入——但 move assignment 需要來源物件，仍得建立暫時物件當 move 來源 → emplacement「免暫時物件」的核心優勢消失（違反三條件之 1）。
std::set 加入重複值：emplacement 實作常先建構一個 node 才能與既有節點比對，若值已存在則丟棄該 node → 建構＋解構成本白付，且這種 node 在 emplacement 中比 insertion 更常建立（違反三條件之 3）。
實務效率還受引數型別、容器種類、插入位置、元素建構子的例外安全性等影響，難以簡單歸類 → 通則是兩者都 benchmark。
補充：node-based 容器幾乎一律用建構加值；非 node-based 只有 vector、deque、string，其中可放心依賴「用建構」的是 emplace_back 與 deque 的 emplace_front。