C++ 面試：std::inplace_vector 的固定容量如何影響設計？

題干與適用場景

請解釋 C++26 的 std::inplace_vector<T, N> 如何在物件內提供可變長度但固定容量的連續儲存，並設計安全的 append 策略，涵蓋容量溢出、例外、移動、迭代器失效和何時仍應使用 std::vector。

std::inplace_vector 是 C++26 的定長容量連續容器：元素數量可以變化，但儲存空間直接位於物件內，容量由非型別模板參數 N 固定。它適合上限明確且希望避免動態配置的路徑，卻不等於 std::array，也不提供無限增長。回答應圍繞容量契約和物件生命週期，而非只比較語法。

面試官考察點

• 是否區分 size、capacity、物件內儲存和動態配置。
• 是否說明容量達到 N 後的操作語義與錯誤處理。
• 是否理解連續儲存、移動、引用和迭代器失效。
• 是否討論元素建構例外和強例外保證能否成立。
• 是否知道 N 會影響物件大小、堆疊布局和 ABI。
• 是否能判斷何時選擇 inplace_vector、array、vector 或其他容器。

回答前需要釐清的問題

1. N 是編譯期可證明的上限，還是執行期設定？
2. 容量溢出是程式錯誤、可恢復輸入，還是必須丟棄的訊息？
3. 元素型別是否可移動、可複製、可拋出例外？
4. 容器位於堆疊、物件池、共享記憶體還是熱路徑結構中？
5. 呼叫者是否保存元素引用、指標或迭代器？

30 秒回答框架

我會先把 N 定義成可驗證的容量契約，再按業務選擇溢出策略：拒絕、返回錯誤或截斷，絕不假設它會自動擴容。inplace_vector 保持連續儲存但把緩衝區放在物件內，因此物件大小和移動成本都隨 N 增長。append 前檢查 size，使用符合元素例外保證的建構路徑；插入和 size 增長仍可能使引用和迭代器失效。上限不明確或需要攤銷增長時繼續使用 std::vector。

分步驟深入解答

1. 先寫清容量和生命週期

std::inplace_vector<T, N> 的 size 在 [0, N] 之間，元素按連續位址儲存；N 是型別的一部分。物件建構時不會預設建構所有 N 個元素，元素在插入時建構，銷毀時只銷毀目前元素。

2. 設計 append 契約

追加前判斷 size() == capacity()，把溢出映射到業務錯誤、丟棄或上游背壓。不要把 reserve 當成擴容手段，也不要靜默覆蓋尾部。批量追加要麼先檢查剩餘容量，要麼定義部分成功語義並讓呼叫者知道已寫入數量。

template<class T, std::size_t N>
bool try_append(std::inplace_vector<T, N>& out, T value) {
  if (out.size() == out.capacity()) return false;
  out.push_back(std::move(value));
  return true;
}

3. 處理例外安全

如果元素建構或移動可能拋例外，追加操作應保持容器不變量，並明確是基本保證還是強保證。批量追加可以先在臨時容器中建構，再移動到目標；但移動本身也可能拋例外，不能憑容器名稱承諾交易式提交。

4. 討論引用和迭代器

插入新元素可能改變後續元素位置；保存的引用、指標和迭代器應按標準規定判斷是否失效。即使沒有堆重新配置，連續緩衝區內的移動仍會讓某些位置變化。API 可以返回索引或穩定控制代碼，避免呼叫者長期持有元素位址。

5. 比較物件大小與移動成本

緩衝區在物件內，sizeof(inplace_vector<T, N>) 通常隨 N 和元素對齊增長。把大容量容器放進堆疊框架、訊息物件或複製頻繁的結構可能增加堆疊壓力、快取壓力和移動成本；必要時把物件放進池或減少 N。

6. 選擇替代容器

上限明確、需要連續存取、希望避免單次動態配置時可選 inplace_vector；固定元素數量用 std::array；上限不確定或需要增長用 std::vector；需要穩定節點位址則考慮其他容器。選擇應由容量、生命週期、局部性和錯誤語義決定。

7. 測試和觀測

測試空容器、恰好滿容量、超容量、例外元素、移動和複製、巢狀物件及大 N。記錄溢出計數、批量部分成功、物件大小和關鍵路徑延遲，使用 sanitizer 檢查生命週期錯誤。編譯器和標準庫支援 C++26 特性時，再驗證 feature-test macro 和實作差異。

高品質示範回答

我會把 N 當成編譯期容量契約：size 可變但不能超過 N，元素連續且儲存在物件內。追加前檢查剩餘容量，溢出按業務返回錯誤或觸發背壓，不覆蓋已有元素。對可能拋例外的元素定義基本或強保證，批量操作明確是否允許部分成功；引用和迭代器不能因為「沒有堆擴容」就假設永遠穩定。

我還會評估物件大小、堆疊和快取壓力、移動成本及 ABI。上限明確且熱路徑需要連續存取時選擇它；上限未知、需要攤銷增長時使用 std::vector，固定數量用 std::array。測試容量邊界、例外和實作支援，並觀測溢出和延遲。

常見錯誤

• 把它當成會自動擴容的 vector → 容量到 N 就結束 → 明確溢出契約。
• 認為物件內儲存意味引用永不失效 → 元素移動仍會改變位置 → 遵循插入失效規則。
• 預設所有元素已經建構 → 實際只建構目前 size → 分開討論儲存與生命週期。
• 只看零配置忽略物件大小 → 大 N 會增加堆疊和快取壓力 → 測量布局與移動成本。
• 批量追加例外時假設自動回滾 → 元素移動可能拋例外 → 明確保證級別並測試。
• 上限未知仍強行使用 → 業務錯誤被截斷或拒絕 → 選擇 vector 或其他容器。

追問及應對

inplace_vector<T, N> 與 std::array<T, N> 有何不同？

前者的 size 可在 0 到 N 之間變化，元素按需建構；後者固定包含 N 個元素。兩者都使用物件內儲存，但生命週期和 API 契約不同。

容量已滿時應該拋例外嗎？

取決於業務。可恢復輸入通常返回錯誤或背壓；程式錯誤可以使用斷言或例外。關鍵是不能靜默覆蓋，也要統一批量操作的部分成功語義。

移動 inplace_vector 會發生什麼？

元素需要被移動或複製到目標物件內的緩衝區，成本與 size 和元素型別相關；它不像指標交換那樣只交換一塊堆記憶體。

為什麼不把 N 設得很大？

緩衝區會增大物件、堆疊框架、複製和快取占用。應以真實分布、尾部容量和溢出成本選擇 N。

如何處理不支援 C++26 的標準庫？

檢查 feature-test macro 和實作文件，提供明確的建置門檻或替代容器，不把實驗性實作靜默當成標準行為。

如何保證元素引用安全？

限制引用生命週期，優先返回索引或穩定控制代碼；在插入、移動和容器銷毀後禁止使用舊引用，並用 sanitizer 和邊界測試驗證。