Boost::Spirit LL パーサー フレームワークの紹介を読んでいたところです。序文は、著者と作成者がそのような解析テクノロジを使用してプログラム オプションを読み取ることを好むことを示唆しています。Boost には、プログラム オプション用の独自のライブラリがありませんか?
Boost 委員会は、共通のテーマとスタイルについてすべてのライブラリ ノートを確認しますか? 各ライブラリのドキュメントには独自のフレーバーがあるようです。
それ以外の場合は素晴らしいソフトウェアに対する小さな不満ですが、私はそれが好奇心旺盛であることがわかりました.
簡単に言うと、Spirit は Boost.Program-Options ライブラリの前に存在していました。今では、Spirit を使用して手動でロールする代わりに、Boost.Program-Options を常に使用しています。
そうです、すべてのBoostライブラリが特にBoostに似ているわけではありません。スピリットはこの良い例です。その理由の一部は、それが受け入れられたとき、他のブーストライブラリがまだ受け入れられていない/Spiritがそれらを使用するのに十分に成熟していないことです。（そのため、独自の（互換性のない）プレースホルダー値_1、_2などを定義する3つのBoostライブラリのようなものがあります）。
これらのケースのほとんどで、私は彼らがこれらの奇妙なものを一緒に戻すことに徐々に取り組んでいると信じています。しかし、アファイク、スピリットが追加されたのは、それがとても大きくて印象的なものだったので、それが「無力」であることが許されたからです。;）
スピリットインブーストはいつかブーストインスピリットになるかもしれません:-)
Joel が言ったように、Spirit が生まれたとき、私たちは Program-Options を持っていませんでした。Hartmut Kaiser と私 (両方とも Spirit 開発者) は、独自の Spirit パーサーをロールアウトする代わりに、Program-Options を使用しています。Program-Options は構文解析よりも多くのことを行います。少なくとも、私たちのニーズでは、コマンド ライン構文解析のパフォーマンスは重要ではありません。パフォーマンスが重要な解析には、間違いなく Spirit を使用します。