typedef のサポートを実装するには、レクサーが識別子を識別して別のトークンを返すたびに、シンボル テーブルを検索する必要があります。これは、flex lexer で簡単に実行できます。私はブーストスピリットを使用してパーサーを構築しようとしていますが、例を調べましたが、レクサーとパーサーの間でコンテキスト情報を渡すものはありません。ミニ C コンパイラのチュートリアルの例でこれを行う最も簡単な方法は何ですか?
2 に答える
5
それはSpirit.Lexでも同様に簡単です。必要なのは、トークンを照合した後、トークンをパーサーに返す前にコードを呼び出す機能だけです。これが字句解析アクションです。
this->self += identifier[ lex::_tokenid = lookup(lex::_val) ];
ここlex::_tokenidで、は現在のトークンのトークンIDを参照するプレースホルダーでありlex::_val、一致したトークン値を参照し（その時点で、おそらくこれはiterator_range<>基になる入力ストリームを指している）、ルックアップは遅延関数（つまり、次のような関数オブジェクト）です。 a phoenix::function）実際のルックアップロジックを実装します。
このテクニックを示すSpiritに追加される小さな例を実装する時間を見つけようと思います。
于 2011-08-10T11:11:03.397 に答える
1
typedef のサポートを実装するには、レクサーが識別子を識別して別のトークンを返すたびに、シンボル テーブルを検索する必要があります。
カートを馬よりも先に置いていませんか？レクサーの目的は、テキスト入力を受け取り、それを単純なトークンのストリームに変換することです。これにより、「これらは float の可能な表現です」などの低レベルのものを処理する必要がないため、パーサーの指定と処理が容易になります。
識別子トークンのシンボルへの言語ベースのマッピング (つまり、typedef) は、レクサーが行うべきことではありません。これは、構文解析の段階で発生するものですが、抽象構文ツリーの後処理として発生する可能性もあります。
qi::symbols別の言い方をすれば、 がパーサー オブジェクトであり、レクサー オブジェクトではないのには十分な理由があります。この種のことを処理するのは、レクサーの仕事ではありません。
いずれにせよ、あなたがしたいことは、（パーサーで）識別子トークンをtypedefされた型を表すオブジェクトにマップする手段を構築することだと私には思えます。qi::symbolsパーサーは、この種のことを行う方法のようです。
于 2011-08-10T05:45:27.013 に答える