C++26 靜態反射實戰：重構翻譯系統的幾種路徑
isocpp.org · 2026-05-12
C++26 的 compile-time 反射在 GCC 16.1 已納入實驗支援，作者 friedkeenan 以自己既有的翻譯系統為題，探索了多種利用反射升級設計的方向。文章並未宣稱某種做法「明顯最優」，而是呈現從當前實作到逐步引入反射的一系列選項及其取捨。
背景
傳統的 C++ 翻譯系統通常依賴手寫型態登錄表、巨集或模板特化，在每次新增語言字串時需維護多處同步改動。C++26 std::meta 提供 reflect_invoke、members_of、type_of 等工具，使程式在編譯期可查詢型態的成員並生成相應程式碼，消除人工登錄。
核心改動
文章探索的升級選項涵蓋三個層次。第一層是自動化成員枚舉：利用 members_of(^MyStruct) 在編譯期遍歷所有欄位，取代原本手寫的型態映射表。第二層是型態驅動的序列化/還原：根據每個欄位的 type_of 推導對應的翻譯函式，讓新增欄位時無需修改翻譯邏輯本身。第三層則是屬性標注：以反射屬性（[[=...]] 語法）標記哪些欄位需要翻譯，將「是否翻譯」的決策嵌入型態定義而非分散在外部表中。
影響範圍
C++26 反射為 zero-runtime-overhead：所有 std::meta 操作在編譯期完成，生成的程式碼與手寫版本等價，不引入額外間接呼叫。相對地，反射的代價是編譯時間增加，且目前主流工具鏈的 IDE 支援仍在追趕中。作者的分析顯示，較激進的反射化在維護性上有明顯收益，但需要團隊對 std::meta API 有一定熟悉度；對小型系統而言，最小侵入的局部反射（僅自動枚舉成員）投資報酬率最高。
Erlang/OTP 29.0 正式發布：原生 Record、後量子 SSH、多值 Comprehension
erlang.org · 2026-05-13
Erlang/OTP 29.0 於 2026 年 5 月正式釋出，帶來語言層面的實驗性原生 Record（EEP-79）、多值 Comprehension（EEP-78），以及在安全性上將後量子混合演算法 x25519mlkem768 設為 SSL/SSH 預設的重大改動。
語言新特性
原生 Record（EEP-79，實驗性）是 OTP 29 最受矚目的語言改動：相較於傳統 tuple-based record，原生 Record 是真正的資料型態，不再是語法糖展開成 tuple，使型態系統能更精確地推論欄位存取。多值 Comprehension（EEP-78）允許 [-I, I || I <- [1,2,3]] 在單次迭代中產出多個元素，消除先前需要 lists:flatmap/2 的樣板。is_integer/3 新 guard BIF 支援 is_integer(I, 0, 100) 的範圍驗證，簡化邊界檢查。
安全性改動
- SSH daemon：
shell與exec服務預設關閉；SFTP 子系統亦預設停用 - SSL/SSH 預設金鑰交換改為
mlkem768x25519-sha256（後量子混合 KEM） -unsafeattribute 標記不安全函式，啟用後編譯器發出警告- code path 中
.（當前目錄）移至最末位，降低路徑注入風險
編譯器與標準函式庫
新增 io_ansi 模組提供 Virtual Terminal Sequences（ANSI 色彩/樣式）的標準支援；ct_doctest 模組支援在文件範例中直接執行測試。rand:shuffle/1 和 rand:shuffle_s/2 提供列表隨機排列。編譯器新增四類預設啟用的警告：catch 算子棄用、子表達式變數匯出、and/or 算子廢用、模式匹配別名。32 位元 Windows 建置自此版本起不再提供。
Python 3.14/3.15 撤回增量式 GC：記憶體用量最差暴增 5 倍
Python Discourse · 2026-05-14
Python 3.13 引入的增量式垃圾回收器（Incremental GC）將在 3.14 與 3.15 中被撤回，替換回原本的世代式 GC（Generational GC）。Hugo van Kemenade 提出此提案，理由是增量式 GC 在生產環境中造成「顯著的記憶體壓力」，且原始實作未經過標準 PEP 流程審核。
效能回歸細節
Neil Schemenauer 以專用基準工具 cyclotron 測量後發現：記憶體使用量在最壞情況下可達原本的 5 倍，成因是循環垃圾在增量式回收節奏中積累過久。暫停時間確實改善——一組合成測試中增量式 GC 的最大暫停為 1.3 ms，世代式 GC 則為 26 ms——但代價是峰值記憶體高出 2.7 倍。增量式設計的核心假設（小批次回收可攤平暫停）在循環引用密集的工作負載下失效，整體吞吐量也因此下滑。
後續計畫
社群討論中有人提議在 3.14/3.15 同時保留兩種 GC 實作並以啟動旗標切換，但最終因維護成本考量未採納。增量式 GC 預計在 Python 3.16 透過完整 PEP 流程重新引入，並附帶更完善的評估與記憶體佔用測試。目前的決定是讓世代式 GC 這個「已知量」繼續服役，直到增量式方案能在記憶體效率上達到可接受的水準。