問題タブ [boost-spirit-x3]

\alphaLaTeX エスケープ コード (例: ) を Unicode (数学) 文字 (例: )に解析しようとしていますU+1D6FC。

現在、これは、このsymbolsパーサー (ルール)を使用していることを意味します。

これは正常に動作しますがstd::u32string、結果として取得していることを意味します。コード内に Unicode コード ポイントを保持するエレガントな方法 (おそらく将来の自動化のため) とメンテナンスの理由が必要です。この種のパーサーを UTF-8 に解析する方法はありstd::stringますか?

symbols構造体を a に解析することを考えましたstd::stringが、それは非常に非効率的です (時期尚早の最適化は bla bla です)。

これを機能させるために一連のフープを通過する代わりに、エレガントな方法があることを望んでいました（symbols結果に文字列を追加します）。

ただし、コード ポイント値を使用して UTF8 を使用すると、変換のランタイム コストが発生するのではないかと心配しています (または、constexprUTF32->UTF8 変換の可能性はありますか?)。

LaTeX数学を解析したい（最初の例では、記号のみを認識して保持する）。現在、上付き文字と下付き文字、中括弧との組み合わせに問題があります (たとえばa^{bc}、それらの組み合わせで、基本的なa^b動作は問題ありません)。最小限の例 (可読性を維持しながら人間的に可能な限り短く):

それもAvailable on Coliruです。

問題は、この segfaults (明らかな理由で確信しています) であり、これを表現文法で表現する方法が他にありません。

私は Spirit X-3 を使用しており、「00ff0af0」のように 16 進数で表される RAM アドレスを解析したいと考えています。64 ビット システムの場合、アドレスのサイズは 64 ビットになります。

残念ながらboost::spirit::x3::hexunsigned を使用しています。

boost-spirit で 64 ビットの 16 進数を解析するにはどうすればよいですか?

ボードゲームの位置の説明を読み取るための実用的なパーサーを入手しました（国際ドラフト、公式文法）：

Live On Coliru

次に、合成された属性から値を抽出したいので、Boost.Fusion などのボイラープレート ダンスを行いました。

Live On Coliru

ただし、次のエラーが表示されます

エラー: static_assert に失敗しました 「属性に予期されたサイズがありません。」

そして数ページ下：

^ main.cpp:16:8: 注: 候補コンストラクター (暗黙的な移動コンストラクター) は実行可能ではありません: ' std::vector<boost::variant<ast::num_rng, ast::num_pc>, std::allocator<boost::variant<ast::num_rng, ast::num_pc> > >' から 'ast::num_seq' への既知の変換はありません。最初の引数 struct num_seq { std::vector<rng_or_pc>sqrs; };

^ main.cpp:16:8: 注: 候補コンストラクター (暗黙のコピー コンストラクター) は実行できません:std::vector<boost::variant<ast::num_rng, ast::num_pc>, std::allocator<boost::variant<ast::num_rng, ast::num_pc> > >第 1 引数の ' ' から 'const ast::num_seq' への既知の変換はありません struct num_seq { std::vector<rng_or_pc>sqrs; };

質問: このエラーの原因と解決方法を教えてください。どうやら私のルールの合成属性はnum_seqと等しくありませんstd::vector<boost::variant>>。どうすればこれを修正できますか?

これは、この Q&Aのフォローアップです。文法が認識する 2 つの異なる形式に対応するnamespace ast2 つのサブ名前空間 (algebraicおよび) に分割された にいくつかのデータ構造があります。numeric

ワーキングパーサーLive On Coliru

さまざまなタイプのストリーミング演算子を定義しようとすると、問題が発生します。(リンクされた Q&A のように)さまざまな構造体と同じ名前空間でジェネリックoperator<<を使用すると、すべて問題ありません。しかし、2 つのサブ名前空間があり、これらの名前空間でさまざまな演算子を定義すると、次のようになります。vector<T>astalgebraicnumeric

Live On Coliru適切なオペレーターが見つかりません。

質問: 一致した AST を適切に出力するために、さまざまなストリーミング オペレーターを定義する方法を教えてください。

Boost.Spirit X3を使用して、範囲と個々の数字 (例: 1-4、6、7、9-12) のカンマ区切りのリストを単一の に解析したいと考えていますstd::vector<int>。これが私が思いついたものです：

入力を考えると

Live On Coliruこれは ( )として正常に解析されます。

質問expand: セマンティック アクションをパーツに適用する必要があることは理解していると思いますrangeが、なぜパーツにもセマンティック アクションを適用する必要があるpushのnumberですか? それがなければ (つまり、 の単純な( -(range [expand] | number) % ',')ルールでexprは、個々の数値は AST ( ) に伝播されませんLive On Coliru:

おまけの質問: これを行うにはセマンティック アクションが必要ですか? Spirit X3 のドキュメントは彼らを思いとどまらせているようです。

タグ付けされた AST ノードは、X3 での解析中に を使用してアクセスできますannotation_base::on_success。

それらのアドレスを取得し (そして、対応する入力範囲反復子のペアなどの別の情報と同様に保存しparse)、それらを使用するときにその不変性に依存することはできますか?後で？

ASTノードがすでに割り当てられている状態で、戻ったときに変更されないと仮定できparseますか?

AST は集約と STL コンテナーの組み合わせです: 再帰ツリー。

I'm trying to port a parser from Spirit V2 to X3. The overall experience is quite good but there are two problems.

The first one is that local variables are gone, which is quite inconvenient to me since I used them quite often to keep track of things. Hence I'm asking for something that would do the job of locals in V2.

The other one is best illustrated with this dummy example: I want to parse a comma separated list of integers into a vector<int>, but it should only parse when the list sums up to zero:

I'm stuck with the last checking here as I don't know how to get my hands on the vector<int> the rule is synthesizing.

X3 で構文解析している現在の文法では、空白と Perl スタイルのコメントは無視されます。

X3 のスキップ パーサーは単なる通常のパーサーであり、それが消費する入力はすべて「スキップされた」と見なされるように私には思えます。私はこれを思いつきました：

非常に基本的な入力 (2 行のコメント行と 1 つの引用符で囲まれた文字列行) の解析では、これはうまく機能しているようです。(コリルでライブ)

ただし、この問題に関するドキュメントが見つからず、現在のスキップ パーサーの詳細はテンプレートの複雑なシステムに隠されているため、何らかの情報を期待していました。

1. これは「スキップパーサー」を定義する適切な方法ですか? 標準的な方法はありますか？
2. このような実装にパフォーマンス上の懸念はありますか? どのように改善されますか？

以前に SO の詳細を検索したところ、Qi ( Custom Skip Parser with Boost::Spirit ) を使用して回答が見つかりました。私は気を学んだことがないので、詳細の多くを理解するのは難しい. 上で説明した方法は、より直感的に思えます。