X3 パーサーを、ルール (およびその定義) がメンバーであるクラスにカプセル化しようとしました。つまり、boost::spirit::qi::grammar から派生する必要がある Qi パーサーの構造に似ています。
このアプローチの利点は次のとおりです。
- 例で使用されている名前空間アプローチよりもコードの分離が優れています (たとえば、名前空間の競合を回避するため)。
- パーサーは、静的であるパーサー (個々のルール) の代わりに、このクラスのオブジェクトが生成されたときにのみインスタンス化されます。
- 潜在的なパラメーター (例: parameterに依存するquestionパーサー ルール) はコンストラクターに与えられ、 with<> ディレクティブを使用する代わりに「直接」の方法で統合される場合があります。
しかし、これは不可能のようです。フォームでルール (またはルール定義) を定義することは、クラス メンバーでは不可能であるためauto name = rule<class name, std::string>() = alpha >> *alnum;、オプションではありません。auto一方、実際の型を記述することも、非常に小さなパーサーを除けば実用的ではないようです。モデリングの代替手段は、ルールをメンバーとして持ち、コンストラクターで定義を作成することですが、ここでは、通常 BOOST_SPIRIT_DEFINE で行われるそれらの間のリンクは不可能であり、ルールだけでは解析するのに十分ではありません (static_assert に失敗しました "BOOST_SPIRIT_DEFINE undefined forこのルール」）。
また、パーサー全体をクラスメソッドに含めることは、たとえばParseXYZ::parse()、パーサーを作成し、おそらく一度だけ作成されるような別のメソッドを介して入力を解析し、コードの再利用に関しては実際にはオプションではありません（コピーと貼り付けは別として） ）。
X3 パーサーをクラスにカプセル化できるかどうか知っていますか? それ以外に、X3 で再利用可能なパーサーを構築するための提案は何ですか?