0

レックスからです。

lex 構造体の定義を次のように仮定します。

... definitions ...
%%
... rules ...
%%
... subroutines ...

サンプル ファイルの 1 つで、定義 PART から次の行を最初に確認します。

  %x PP PRAGMA

次に、ルール部分で、私は見ました：

<PP>[ \t\r]*                { }
<PRAGMA>.                   { }
^[ \t]*#[ \t]*version       { BEGIN PP; return VERSION_TOK; }

それで、ここに私の質問があります（lexの一般的な概念を理解しています）：

  1. PPプラグマとは？%x をどのように理解すればよいですか?
  2. RULE PART: とはどういう意味ですか? それらはトークンであってはなりませんよね？
  3. BEGIN PP とはどういう意味ですか?
4

1 に答える 1

2

<PP>そして<PRAGMA>「開始条件」です。実際、これらは で宣言されているため、「排他的な」開始条件です%x。( %s「包括的」開始条件を宣言していたでしょう。)

それらが開始条件と呼ばれる理由がわかりません。「開始」という言葉は少し紛らわしいです。それらを語彙的な状態と考えることができますが、「状態」は通常別のものを意味するため、少し混乱することもあります。

字句解析中の任意の時点でlex、アクティブな「開始条件」があります。ほとんどの場合、(定義済みのデフォルト) 開始条件 INITIAL がアクティブです。これは、開始条件を宣言していない場合に常に当てはまります。マクロで開始条件を「入力」できますBEGIN(CONDITION)。

ルールの開始<CONDITION>は、CONDITION がアクティブな開始条件である場合にのみ使用されます。ルールは、山括弧内に複数の条件名を持つことも、<*>(すべての条件を意味する) 持つことも、まったく条件を持たないこともできます。アクティブな条件が「包括的」である場合は常に、条件を指定しないルールが使用されます。アクティブな条件が「排他的」である場合、条件を具体的に指定するルールのみが使用されます (<*>ワイルドカード ルールを含む)。

条件は実際には整数定数であり、現在の条件は YY_START の値です。たとえば、それらを保存して後で復元することができますが、lexそれを簡単にする便利な条件スタックが提供されています。

BEGIN の通常の定義は次のとおりだと思います。

#define BEGIN YY_START =

これが、(BEGIN PP のように) 条件名を括弧で囲む必要がない理由ですが、個人的には、これは悪いスタイルだと思います。少なくとも一部の lex-alike は、BEGIN を引数をとるマクロとして実際に定義しているためです。

ちなみに、開始条件は非常に便利です。

于 2012-10-11T05:32:34.043 に答える