Boost 1.92.0の更新判断：HTTP解析の厳格化とCUDA対応を読み解く

Boost 1.92.0では、BeastのHTTP解析が厳格化され、Charconvの整数変換とDecimalの十進浮動小数点型にCUDA対応が加わりました。既存通信への影響、新機能の有効化条件、WindowsのDLL配置変更を分けて、更新時に検証する箇所を整理します。

こはるの読みどころ

新機能を使わなくても、通信の受理条件やDLLの配置は変わるんだね。自分のアプリが使うライブラリと、その動作を支える前提を一緒に見ていこう。

Boostの更新では、新しいAPIを使う予定がなくても、既存アプリの動作が変わることがあります。Boost 1.92.0で見ておきたいのは、通信を受け入れる条件と、コードを実行・配置する条件の変化です。

2026年9月29日のISO C++ Blogの紹介をきっかけに、既存プロジェクトへ取り込むときの判断を考えてみます。リリース自体は、Boost Release Teamが2026年8月12日に公開を告知しています。

「更新するだけで効く変更」と「設定して初めて使える機能」を分けると、検証する順番も決めやすくなります。まず既存通信への影響を押さえ、その後にCUDAの利用条件と配布環境を見ていきましょう。

Beastの解析厳格化で、既存通信の受理条件が変わる

Boost.Beastは、1.92.0で Content-Length と Transfer-Encoding が同居するメッセージを、フィールドの順序によらず拒否するようになりました。HTTP/1.0リクエストのchunked転送も拒否し、チャンク拡張の引用文字列の検証も強化しています。Beastの変更履歴に、対象となるパーサーの変更がまとまっています。

なぜヘッダーの組み合わせが問題になるのでしょうか。Content-Length は本文の長さを示し、chunked転送ではチャンク列の終端から本文の終わりを決めます。経路上の実装が異なる解釈をすると、メッセージの区切りが食い違う原因になります。RFC 9112の6.3節も、両フィールドを含むメッセージはリクエストスマグリングなどの兆候になり得るため、エラーとして扱うべきだとしています。

ここでの互換性確認は、コンパイルが通るかどうかだけでは足りません。自前のHTTP送信処理やプロキシとの結合テストでは、次の入力条件を区別すると、変更点を狙って検証できます。

検証する入力	1.92.0で着目する挙動
`Content-Length` の後に `Transfer-Encoding` がある	両フィールドの併存を拒否する
上記と逆のフィールド順序	順序を変えても拒否する
HTTP/1.0リクエストにchunked転送を指定する	パーサーが拒否する

これは変更履歴から組み立てたテスト観点です。正常な通信も並べて実行すれば、不正な入力を意図どおり拒否した結果と、アプリ側の回帰を切り分けやすくなります。

同じリリースには、Boost.URLの normalize_path でauthorityを持たず、正規化後のパスが // で始まるURLを扱う際のヒープバッファオーバーフロー修正も含まれます。公式リリースノートのURL欄に条件が記載されています。外部入力を扱うアプリでは、利用するパーサーや正規化処理を棚卸しすることが、更新の優先度を決める出発点になります。

CUDA対応は、呼び出せる型と関数を選んで有効にする

既存通信に関わる変更を押さえたら、次は新しい実行環境を使うかどうかの判断です。1.92.0では、Charconvの整数用 to_chars と from_chars、Decimalの decimal32_t・decimal64_t・decimal128_t がCUDAカーネル内で利用可能になりました。

Charconvは、数値と文字バッファを相互変換するライブラリです。たとえばGPU側で持つ整数を文字列へ変換したい処理では、この対応が検討材料になります。ただし、整数の対応を浮動小数点変換まで広げて解釈しないようにしたいですね。

CharconvのCUDA対応ドキュメントでは、BOOST_CHARCONV_ENABLE_CUDA を定義して有効にし、BOOST_CHARCONV_HOST_DEVICE が付いた関数をホストとデバイスの両方で実行できるとしています。それ以外の関数はホスト専用です。「ライブラリがCUDA対応」という見出しだけでなく、実際に呼ぶ関数までたどる必要があります。

Decimalにも独立した設定があります。Decimalの設定マクロでは、NVCCでのコンパイル時に BOOST_DECIMAL_ENABLE_CUDA を定義すると、対応する型と関数をデバイスで利用できます。同時に BOOST_DECIMAL_DISABLE_EXCEPTIONS と BOOST_DECIMAL_DISABLE_CASSERT も定義されるため、例外やアサーションに依存する検証方法はそのまま持ち込めません。

したがって、CUDA対応の採用では、対象関数がコンパイルできるかに加えて、入力と結果をどこで検証するかまで決めておくとよさそうです。性能の判断は、必要なデータ転送も含めたアプリの処理全体で測るのが自然です。対応機能の追加だけから、高速化の幅までは決まりません。

WindowsのDLL配置とC++要件まで含めて更新を完了する

通信や計算のテストが通っても、配布先で起動できなければ更新は完了しません。1.92.0では、b2 install がWindowsのDLLを配置する既定の場所が、ライブラリ用ディレクトリからバイナリ用ディレクトリへ変わりました。既定パスは <PREFIX>/lib から <PREFIX>/bin になり、従来から後者を使っていたCygwinとそろいます。

lib 配下からDLLを集める配布スクリプトでは、収集先の見直しが必要になります。新しい --dlldir オプションで配置先を指定することもできます。公式リリースノートのGeneral Notesが、この互換性維持の方法を案内しています。

同じ箇所では、b2 install が生成するCMake設定に、ヘッダーオンリーライブラリを find_package のコンポーネントとして要求できる変更もあります。find_package(Boost REQUIRED COMPONENTS mp11) で Boost::mp11 が定義され、CMakeでBoostをビルドした場合との使い方がそろいます。一方で COMPONENTS ALL は削除されているため、利用しているプロジェクトでは、必要なコンポーネントを明示する形へ見直したいところです。

言語標準については、HeapとLockfreeがC++14をサポートする最後のリリースとなり、今後はC++17が必要になります。これは当該ライブラリについての予告で、1.92.0のBoost全体が一律にC++17必須になったという意味ではありません。公式リリースノートのHeap・Lockfree欄を、利用ライブラリに照らして読むと分かりやすいです。

Boost 1.92.0へ進めるかどうかは、使うライブラリと既存の前提を対応させると判断できます。外部入力を扱うなら受理・拒否の挙動を先に確かめ、CUDAを採用するなら関数とエラー処理の条件を詰め、最後に配布物の起動まで通す。この順番なら、新機能を試す作業と、既存アプリを動かし続けるための作業を混同せずに更新を進められます。