JPH1040114A

JPH1040114A - Ｃ＋＋プログラムのコンパイル方法及びコンパイラ

Info

Publication number: JPH1040114A
Application number: JP9105811A
Authority: JP
Inventors: Lee Richard Nackman; リー・リチャード・ナックマン; Michael Karasick; マイケル・カラスィック; John Joseph Barton; ジョン・ジョセフ・バートン; Derek Lieber; デレック・リェバー; David Joseph Streeter; デヴィット・ジョセフ・ストレッター
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1996-05-01
Filing date: 1997-04-23
Publication date: 1998-02-13
Also published as: EP0805391A3; TW308676B; EP0805391A2; CA2175711A1; US6182281B1

Abstract

(57)【要約】【課題】通常はプログラム・ヘッダ・ファイルに含まれ
るフォワード宣言を使用することなくＣ＋＋プログラム
をコンパイルするための機能強化されたコンパイラを提
供する。【解決手段】多数の構文解析パスを通して、コンパイラ
は、Ｃ＋＋ファイルの本体から直接宣言の定義を抽出す
る。定義を持続性プログラム表現、たとえばプログラム
・データベースに保存することにより、後続の掃引で
は、新たな宣言または変更された宣言の定義だけを更新
すればよい。このようにして、Ｃ＋＋プログラムを１宣
言ずつのベースで増分コンパイルすることができる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、Ｃ＋＋プログラム
のインクリメンタル・コンパイルを可能にする技術に関
する。

【０００２】

【従来の技術】Ｃ＋＋は、「クラス」と呼ばれる特定
の形態のユーザ定義型をサポートする言語ツール、抽象
化およびコンストラクトのセットを使用してプログラム
を作成すれるオブジェクト指向プログラミング言語であ
る。そのような各型は、宣言データの集合体をそのデー
タに対する演算のセットに関連させる。実行中のプログ
ラム中のそのような型の変数、あるいはインスタンスが
「オブジェクト」と呼ばれる。

【０００３】クラスは、継承によって互いに関連させる
ことができる。ある親、あるいは「基本」クラスの属
性、動作、データおよび演算は、子、あるいは「導出」
クラスによる変更なしで継承することもできるし、動
作、属性および演算をプログラマの制御の下で選択的に
洗練することもできる。導出クラスを定義するときに
は、作成しようとするクラスに類似した既存の基本クラ
スを基にして構築することによって出発することもでき
る。導出クラスは、導出クラス定義に詳述された修正に
よって変更されるようなものを除き、基本クラスのイン
プリメンテーションおよび動作を継承する。いくつかの
クラスが共通の親の動作を継承することができ、導出ク
ラスは、二つ以上の基本クラスから継承することもでき
る。メンバ関数とは、何らかのユーザ定義型の、その型
が他の型の階層に参入する動作として定義される関数ま
たは演算である。

【０００４】Ｃ＋＋プログラミングの特徴は、それがテ
キストベースであることと、そのクラスが別個のファイ
ルに記憶されることである。クラス宣言は普通、２個の
ファイル、すなわち、クラス宣言をメンバ・フィールド
およびメンバ関数ヘッダとともに含む、拡張子「.h」ま
たは「.hpp」をもつヘッダ・ファイルと、メンバ関数の
本体を含む、拡張子「.C」または「.cpp」をもつ本体フ
ァイルとに分割される。

【０００５】従来のＣ＋＋プログラミングでは、ヘッダ
・ファイルは、重要なプリプロセッサ（前処理系）指示
語およびフォワード宣言を含む。この後者は、各名前が
使用の前に宣言されることを保証するための宣言順序づ
けを提供する。ヘッダ・ファイルは、プリプロセッサ指
示語#includeの使用によってソース・ファイルに挿入さ
れる。

【０００６】しかし、フォワード宣言は、プログラマが
手作業によって作成しなければならない。ヘッダ・ファ
イルを書き、編成し、維持する（プログラム改訂を通じ
て）ことは、プログラマの相当な時間および思考を要す
る。その結果、ヘッダ・ファイルにおける間違いがしば
しばコンパイル誤りの原因である。

【０００７】ヘッダ・ファイルはまた、Ｃ＋＋プログラ
ミングにおける長いプログラム構築時間の主要な原因で
ある。プログラマがますますＣ＋＋クラスを利用するに
つれ、ヘッダ・ファイルを繰り返し再処理する費用がし
ばしば全体のコンパイル時間を支配する。ある結果は、
この問題に対処するため、今や大多数の市販Ｃ＋＋コン
パイラによってサポートされているプリコンパイルされ
たヘッダ・ファイルの導入であった。

【０００８】選択的なコンパイルに対応する考えは、異
なるレベルの粒度で扱われてきた。たとえば、「Comput
er System with Real-time Compilation」と題するReif
fenのイギリス特許第２，１３０，１０６号は、ユーザ
がソース・プログラムを編集する間に部分的にコンパイ
ルするシステムを論じている。コンパイラは、エディタ
（編集プログラム）によって決められるソース中の「休
止位置」までコンパイルしたのち、待機する。ユーザ
が、コンパイラがもっと処理できる、とエディタが考え
る地点まで変更を行ったところで、エディタは「休止位
置」を更新し、コンパイラはもう少しだけ作業を行う。
しかし、それでもこのコンパイラは、ソース・コードを
最初から最後まで順序どおりにコンパイルする。ユーザ
が「休止位置」の前でソースを変更するならば、エディ
タは、コンパイラに対し、再び初期化し、ソースの最初
から新たな「休止位置」までコンパイルを始めるように
指示する。

【０００９】Ｃ＋＋コンパイラでは、インクリメンタル
・コンパイルの形態をインプリメントするための技術で
あって、「メイク」と呼ばれるツールが、タイムスタン
プをもつファイルを最後のコンパイルの後に位置づけた
のち、コンパイラに対し、必要なファイルをコンパイル
するよう指示することにより、どのファイルを再コンパ
イルする必要があるかを決定する技術が開発された。し
かし、ファイルベースのバッチ処理を実施する従来のＣ
＋＋コンパイラは、宣言を順序どおりに読まなければな
らず、しばしば、変更された宣言を処理するまでに、フ
ァイルまたはファイルが含むヘッダ・ファイル中で何千
ラインもの未変更のコードを読まなければならない。変
更されたヘッダ・ファイルを含むファイルは、変更がそ
のファイルの何らかの定義に影響するかどうかにかかわ
らず、再コンパイルされなければならない。また、プロ
グラマは、ファイルレベル従属性を「メイク」に伝えな
ければならず、この従属性情報は、開発中のシステムが
進化する間、維持されなければならない。従属性を自動
的に維持するためのツールが存在するが、それらは非常
に遅く、その結果、不変的には使用されず、従属性情報
における誤り、そして最終的には、再コンパイル中の問
題につながる。

【００１０】したがって、Ｃ＋＋プログラムに対する変
更のインクリメンタル・コンパイルを考慮したシステム
が最高水準宣言のインクリメント性で実現されるなら
ば、プログラムの開発および維持におけるコンパイル時
間を大幅に減らすことになろう。

【００１１】また、Ｃ＋＋プログラミングにおけるフォ
ワード宣言の必要性を完全に除くことができるならば、
はじめにヘッダ・ファイルを作成し、コンパイルの間に
確認された誤りを訂正するのに伴う作業を除くことによ
り、プログラマの生産性に大きな改善をもたらすことに
なろう。コンパイラの機能強化は、フォワード宣言で提
供される順序づけの要件をなしで済ますのに必要であ
る。

【００１２】

【発明が解決しようとする課題】本発明の目的は、コン
パイル中にＣ＋＋プログラムを構文解析するための手段
であって、フォワード宣言または定義づけ宣言の他の順
序づけをなしで済まし、プログラマがプログラム編集中
にファイルレベル従属性情報を維持する要件をなしで済
ます手段を提供することである。

【００１３】本発明のもう一つの目的は、ソース・ファ
イル全体をコンパイルし、連結するのではなく、Ｃ＋＋
プログラム中の小さな変更だけをコンパイルし、連結す
ることができるシステム、すなわち、インクリメンタル
・プログラミングのためのシステムを提供することであ
る。

【００１４】本発明のさらなる目的は、コンパイラの多
数の構文解析パスを通して持続する全プログラム的表現
を作成するための手段を提供することである。

【００１５】

【課題を解決するための手段】したがって、本発明は、
ソース・コードで書かれたＣ＋＋プログラムをコンパイ
ルするための方法であって、そのソース・コードの最初
の掃引を一度に１宣言ずつ実施して宣言を得ることから
なる方法を提供する。前記最初の掃引で識別子が全部は
わからなった宣言を別にしておき、少なくとも１回の後
続の掃引を実施して、最初の掃引から別にしておいた宣
言の定義を得る。

【００１６】好ましくは、ソース・コードの各掃引のの
ち、宣言をプログラム表現に保存し、そのプログラム表
現がコンパイルとコンパイルの間で持続する。

【００１７】本発明はまた、順序づけまたはフォワード
宣言なしで、あるいはヘッダ・ファイルなしで、Ｃ＋＋
ソース・コードで書かれたプログラムを構文解析する方
法を提供する。この方法では、構文解析は、最高水準宣
言に対して直接実施する。

【００１８】さらなる実施態様では、本発明は、Ｃ＋＋
ソース・コード・プログラムを、字句解析を実施してソ
ース・コード・プログラムをトークン化し、構文解析お
よび意味解析を実施してソース・コード・プログラムの
中間表現を生成する機能強化されたコンパイラにおいて
コンパイルする方法を提供する。本発明の改良点は、ト
ークン化したソース・コード・プログラムを多数の構文
解析パスを通して構文解析することからなる。各パス
は、ソース・コード・プログラム中の宣言をプログラム
定義から構文解析するための情報を蓄積する。好ましく
は、最初のパスで、トークン化したソース・コード・プ
ログラムの型宣言だけを構文解析し、後続のパスで、ソ
ース・コード・プログラム中の型名、変数および関数に
関する情報を蓄積する。

【００１９】本発明はまた、Ｃ＋＋ソース・コードで書
かれたプログラムをコンパイルするためのコンパイラに
関する。コンパイラは、ソース・コードの多数の構文解
析掃引を実施することにより、プログラムで使用される
宣言の定義をソース・コードから直接抽出するためのパ
ーザ（構文解析系）を含む。好ましくは、コンパイラは
また、ソース・コードの前記構文解析掃引からのオブジ
ェクトを、たとえばコンパイルとコンパイラの間で持続
するプログラム表現として記憶するための手段を含む。

【００２０】好ましくは、オブジェクトを記憶するため
の手段は、ソース・コード・プログラムからのトークン
順序の優先順位つき待ち行列を記憶するための手段を含
む。各トークン順序は、構文解析のための少なくとも１
個の宣言を含むものである。

【００２１】本発明はまた、順序づけ、フォワード宣言
またはヘッダ・ファイルなしでＣ＋＋ソース・コードで
書かれたプログラムをコンパイルするための機構であっ
て、Ｃ＋＋ソース・コードからの最高水準宣言を直接構
文解析するための手段からなる機構に関する。

【００２２】最後に、本発明は、上述の方法およびコン
パイラ機構をインプリメントするためのプログラム・コ
ード手段を具現化するコンピュータ読み出し可能なプロ
グラム・コード手段の新規で有用な、自明ではない組み
合わせを有するコンピュータ・プログラム製品に関す
る。

【００２３】

【発明の実施の形態】従来の１パス・コンパイラの動作
の概要を図１に示す。このコンパイラは、ソース・テキ
ストの構造および意味を解析するフロント・エンド１を
含んでいる。フロント・エンド１は、文字ストリーム３
として入力されたソース・コードから、バック・エンド
２に渡されるプログラムの中間表現５を生成する。コン
パイラのバック・エンド２は、目標言語（普通は、リン
カまたは連結ローダによって合わされて機械実行可能な
プログラムを形成することができる、目的コードで書か
れたモジュール。「目的モジュール」と呼ばれる）で等
価プログラムを生成し、また、最適な実行時性能のため
のコードの再編成を提供することもできる。

【００２４】フロント・エンド１はさらに、三つの動作
または段階、すなわち、字句解析、構文解析および意味
解析に細分することができる。字句解析系またはスキャ
ナ６が簡単な構造解析を実行して、ソース・プログラム
・テキストの個々の記号をトークンとしてそれらの論理
的要素に分類し、トークンのストリーム４を次の段階に
渡す。構文解析系またはパーザ７が全プログラムの全体
構造を解析し、トークンを、プログラム全体を構成する
より大きなコンストラクト（ステートメント、ループお
よびルーチン）に分類する。ひとたびプログラムの構造
が決定されると、意味解析系８が、プログラムの構成成
分が意味的に適合するかどうかをチェックする（すなわ
ち、どの変数が浮動小数点を保持し、どの変数が整数を
保持するかを決定し、配列サイズの定義をチェックす
る、など）。

【００２５】従来のＣ＋＋コンパイラは、１パス構文解
析をサポートするためにフォワード宣言および順序を必
要とする。Ｃ＋＋の構文解析には、以下の例のように、
識別子が型名であるかどうかを知っていなければならな
い。

【００２６】 void f(){ T* p;// T is type => Declaration of a pointer variable p. // T is variable => operator*(T,p) }

【００２７】型名のフォワード宣言は、相互参照型を１
パスで構成することを可能にする。たとえば次のとおり
である。

【００２８】 struct T; // Forward declaration struct S {T* t;};// ok, T is a typename struct T {S* s;};

【００２９】最後に、フォワード宣言は、型チェックし
ながらの別個のコンパイルを許す。フォワード宣言はヘ
ッダ・ファイル中に配置され、このヘッダ・ファイル
が、その宣言を使用するソース・ファイルおよびその宣
言の定義を提供するソース・ファイルの両方に含まれ
る。たとえば、次のようなフォワード宣言 typedef float T; extern T a t; //a t is a variable, its type is T extern int foo(T); // foo is a function, it takes a T argument // and returns an int を含むヘッダ・ファイルfoo.hは、a tおよびfoo()を使
用する定義を書くことを許す。このヘッダ・ファイルが
含まれた状態で、以下のコードがコンパイルする。

【００３０】

【００３１】a tおよびfoo()の定義をコンパイルしてフ
ォワード宣言と定義との間の整合性を保証するとき、同
じヘッダ・ファイルが再び含まれる。

【００３２】したがって、１回の構文解析パスしか実行
しない従来のＣ＋＋コンパイラの場合、プログラマは、
フォワード宣言を使用するヘッダ・ファイルを上述した
方法で作成し、順序づけ、維持することを求められる。

【００３３】本発明の機能強化されたコンパイラの使用
を通じて、ヘッダ・ファイルおよびヘッダ・ファイルが
もたらす開発環境問題をなくすことができるように、Ｃ
＋＋プログラミングにおいてフォワード宣言および順序
づけをなくすことができる。

【００３４】フォワード宣言および順序は、１パス構文
解析および別個のコンパイルのために必要である。対照
的に、本発明は多重パス構文解析を使用する。Ｃ＋＋識
別子の意味に関する情報は、プログラマの定義から抽出
されるのであって、型名、変数もしくは関数のためのフ
ォワード宣言または最高水準宣言のプログラマ定義順序
づけから抽出されるのではない。これは、定義のすべて
がコンパイル中に同時に利用できなければならず、多数
回構文解析できることを要する。上記の例では、main()
を含むファイルと、foo()およびa tの定義を含むファイ
ルとの両方が同時に利用できなければならず、これらの
宣言それぞれが２回以上構文解析されるかもしれない。
たとえば、コンパイルされた形態で供給されるクラス・
ライブラリのように、定義のすべてがソースの形態で利
用できるわけではないとき、対応するヘッダ・ファイル
中に供給されたフォワード宣言を代わりに使用すること
ができる。

【００３５】本発明によると、最高水準宣言は、最高水
準宣言ステートメント（たとえば、大域関数および大域
変数）であるように定義され、メンバ関数は、クラス定
義の外にあり、変数定義を有する静的メンバであるであ
るように定義される。最高水準宣言は順序づけされない
が、最高水準宣言内の宣言どうしは互いに対して順序づ
けされなければならない。したがって、以下の宣言は不
当である。

【００３６】

【００３７】ソース・コードは、一度に１宣言ずつ構文
解析される。構文解析することができない宣言は、後の
パスにとっておかれる。各パスは、プログラム中の型
名、変数および関数に関する情報を蓄積する。この情報
は、従属性、すなわち、ある宣言で宣言された名前を別
の宣言で使用することを含む。従属性は、オーバロード
（多重定義）された名前の順序なし処理に必須である。
プログラムが正しいならば、多数のパスが、構文解析に
必要な情報のすべてを明らかにする。プログラマが、プ
ログラムで使用される型名、変数または関数をすべては
定義できなかったならば、多数のパスは、従来のコンパ
イラからの誤りに類似した誤りをもって停止する。

【００３８】以下の簡単な例は、２個の関数および１個
の大域変数からなる。

【００３９】

【００４０】当面いくつかの重要な詳細を省くと、この
プログラムの最初のパスでは、クラスＴだけを構文解析
する。二回目のパスで、関数および変数の型が構文解析
される。三回目のパスで、変数イニシャライザおよび関
数本体が構文解析される。このように、多数のパスによ
り、プログラマが手作業でタイプした宣言なしで、また
順序なしで、プログラムを構文解析することができる。

【００４１】好ましい実施態様では、多重パス構文解析
の各パスを「構文解析掃引」と呼ぶ。最高水準宣言を含
む各Ｃ＋＋ステートメントの処理を「構文解析」と呼
ぶ。構文解析掃引によって生成または更新されるデータ
構造をCodeStoreと呼ぶ。完全な構文解析の実行（多数
の掃引を通じてのもの）は、すべてのソース・コードの
構文解析に成功することによって終了するのか、入力が
正当なＣ＋＋ではないと決定することによって終了する
のかにかかわらず、「組み込み」と呼ばれ、これは、Ｃ
＋＋ソース・ファイル中の変更を既存の（ただし、おそ
らく空の）CodeStoreに組み込むための多重パス構文解
析の使用を指す。したがって、組み込みは、それぞれが
最高水準宣言に対して作用する構文解析からなる多数の
構文解析掃引からなる。

【００４２】プログラム全体を構文解析した結果は、持
続性の全プログラム的表現として記憶され、最後の組み
込み以来、変更を受けたか、そのような変更によって影
響されるソース・コードだけが後の再コンパイルの際に
処理される。好ましい実施態様では、プログラム・デー
タベース（Codestoreと呼ぶ）を使用して、多数の構文
解析パスを通して持続性のプログラム表現を保持する。
しかし、持続性のデータベースは、本発明の多重パス構
文解析コンパイラの動作に必須の特徴ではないことを認
識すべきである。多重パス構文解析の要件は、単一パス
構文解析の要件、すなわち、テキスト入力、満たすべき
内部データ構造、記帳構造に類似している。しかし、構
文解析技術の多数の掃引を使用して持続性のプログラム
・データベースを更新するならば、データ構造のいくつ
かは持続性になるであろう（以下に説明する）。

【００４３】持続性のプログラム表現またはプログラム
・データベースは他の言語の開発システムと統合してい
たが、従来のコンパイルからの利点が性能の費用に見合
うほど大きくはないため、それらはＣ＋＋では一般に使
用されない。Ｃ＋＋コンパイラに関連する限られたプロ
グラム・データベースの形態が導入された区域は、プリ
コンパイルされたヘッダ・ファイル（上記に論じたも
の）およびテンプレート・リポジトリを含む。後者によ
って扱われる問題は、テンプレート具体例を格納する場
所がないならば、Ｃ＋＋テンプレートの広範な使用はコ
ンパイル時間を増す（そしてコード・ブロートを加え
る）ということである。多くの市販コンパイラが使用す
るテンプレート・リポジトリは、この問題に対処するた
めのものである。しかし、本発明まで、より多くの情報
をプログラム・データベースに記憶する能力は、得られ
る利点に対して比較考量して大きいデータベース・サイ
ズの性能の暗示によって束縛されてきたため、これらの
解決方法は全プログラム的データベースではない。

【００４４】本発明の好ましい実施態様では、多重パス
構文解析技術を、全プログラム的表現、たとえばプログ
ラム・データベースと組み合わせた。プログラム・デー
タベースは、ファイルよりもきめ細かな従属性解析をイ
ンプリメントすることができ、不必要なコンパイルを減
らすということがわかった。

【００４５】本発明に使用されるオブジェクトは、持続
性、つまり複数の組み込みにわたって存続することがで
きるか、一時的、つまり一つの組み込みの最後で捨てら
れるかのいずれかである。好ましい実施態様では、持続
性オブジェクトはプログラム・データベースに記憶され
る。一時的なオブジェクトは、組み込みのために作成さ
れる。それらが含むいずれの状態も、組み込みの新たな
サイクルを開始するのには必要ない。

【００４６】CodeStoreプログラム表現は、以下のタイ
プの持続性オブジェクトを含む。

【００４７】Source ソース・オブジェクトは、ソース・コードをコンパイラ
に供給する。大部分のソース・オブジェクトはSourceFi
leオブジェクト、すなわち、ソース・コードを含むファ
イルである。フォワード宣言は必要ではなく、宣言を順
序づけする必要はないが、フォワード宣言および順序は
いずれも既存のソース・ファイルとの互換性を考慮され
ている。他の種類のソース・オブジェクトが、宣言のプ
ログラム的生成、たとえばソース・コード・ビルダ、ウ
ィザードなどを指定する。

【００４８】ProjectControlSource プロジェクト制御ソースは、ソース・コードを含むファ
イルおよび／またはソース・コードを生成するために実
行されるコマンドの名前をリストする。プロジェクト制
御ソースはまた、組み込みの間に使用される、コンパイ
ラ・オプションに類似したオプションを含む。好ましい
実施態様では、CodeStoreごとに１個のプロジェクト制
御ソースがある。

【００４９】SourceStore ソース・ストアは、本発明の処理への入力を構成するSo
urceオブジェクトのリストである。ProjectControlSour
ceがこのリストに載っており、リストの残りをうめるた
めに処理される。

【００５０】Macro マクロ・オブジェクトはＣ＋＋プリプロセッサ（#defin
e）マクロを表す。

【００５１】MacroStore マクロ・ストア・オブジェクトは、識別子をその名前の
マクロにマッピングする辞書である。

【００５２】SourceRegion ソース領域は、１個の最高水準宣言のソース・コード字
句トークンの順序を表す。

【００５３】Declaration 宣言オブジェクトはＣ＋＋宣言の内部表現である。各So
urceRegionが１個以上のDeclarationに対して構文解析
し、各Declarationを多数のSourceRegionで指定するこ
とができる。

【００５４】DeclarationStore 宣言ストア・オブジェクトはＣ＋＋有効範囲を表す。こ
れは、処理に成功した有効範囲中のすべての名前のDecl
arationオブジェクトを含む。これらのオブジェクトは
辞書である。DeclarationStoreに名前を与えることによ
り、定義を検索することができる。これらの辞書は、識
別子参照のためのＣ＋＋規則を使用して、参照要求に応
答する。概して、宣言ストアおよびそれらが含む宣言
は、従来のコンパイラの記号表に見られるデータ構造に
相当する。

【００５５】Implementation インプリメンテーション・オブジェクトは、関数本体ま
たは変数イニシャライザを構文解析した結果を表す。た
とえば、インプリメンテーション・オブジェクトは、抽
象構文木を含むことができる。

【００５６】DependencyNode 従属性ノード・オブジェクトは、オブジェクト参照をオ
ブジェクト定義に関連させる方向つきグラフにおけるノ
ードを表す。直前のオブジェクトのすべては従属性ノー
ドの種類である。

【００５７】WorkQueue 作業待ち行列は、Source、SourceRegionおよびDeclarat
ionが処理される順序を表す。WorkQueueの内部構造は以
下に説明する。

【００５８】MarkerNode マーカ・ノードは、待ち行列処理の順序を変更するため
にWorkQueueに配置される特別な種類のDependencyNode
である。

【００５９】一時的なオブジェクト、たとえばプリプロ
セッサおよびパーザは、組み込みの間に、持続性オブジ
ェクトに対して作用するか、持続性オブジェクトを作成
する。Incorporatorオブジェクトは一時的オブジェクト
をすべて含む。

【００６０】持続性オブジェクトのうち、作業待ち行列
を除くすべては、従属性ノードの動作を示す。本処理の
Ｃ＋＋インプリメンテーションでは、持続性オブジェク
トのクラスは、従属性ノード抽象基本クラスから導出さ
れる。各従属性ノードは、その先行従属性ノードのリス
トおよびそれに従属する従属性ノードのリストを含む。
従属性ノードＤの先行オブジェクトはすべて、Ｄそのも
のの処理への入力として使用されるオブジェクトであ
る。Ｄの従属オブジェクトは、Ｄを先行オブジェクトと
して有するすべてのオブジェクト、すなわち、Ｄを参照
するすべてのオブジェクトである。従属性ノードと、先
行オブジェクトおよび従属オブジェクトのリストとが、
いっしょになって、変更の効果を管理するのに使用され
る従属性グラフを形成する。

【００６１】処理を発生させる従属性ノードの作業待ち
行列が二つある。各ステップで、従属性ノードを待ち行
列から取り出し、処理する。この処理を「更新」と呼
ぶ。この主作業待ち行列は優先順位に基づくものであ
り、従属性ノードが一般にそれらの従属オブジェクトよ
りも先に処理されるように優先順位が割り当てられてい
る。副作業待ち行列は先入れ先出し（ＦＩＦＯ）ベース
で作動し、その構成要素は、主待ち行列にある特定の種
類のすべての従属性ノード（たとえば、Source、Source
RegionおよびImplementation）を処理した後で処理され
る。

【００６２】各従属性ノードは、それに関連する１個以
上の値、たとえばその型またはサイズを有している。こ
れらの値は通常、更新によって計算される。更新が、従
属性ノードの値が変化したと判断したとき、それらの値
を使用する対応する従属ノードが主作業待ち行列に追加
される。このようにして、Sourceへの変更がSourceRegi
onの再構文解析を生じさせ、Declarationへの変更がImp
lementationの再生を生じさせる、などが起こる。

【００６３】主作業待ち行列の各オブジェクトが優先順
位を割り当てられる。最高の優先順位のオブジェクトが
次に処理される。最初の優先順位は、従属グラフ・ノー
ドへのトポロジー的順序づけを近似するように割り当て
られる。オブジェクトの種類に基づいて大まかな相対的
優先順位を割り当てて、通常は最初に処理する必要があ
る種類のオブジェクトを最高位に格づけする。したがっ
て、SourceStoreが最高の優先順位を有し、Sourceが次
に高い優先順位を与えられ、次に、型を宣言するであろ
うSourceRegionが続き、さらに非型を宣言するであろう
SourceRegionが続き、そしてImplementationが続く。こ
れらの大まかな相対的優先順位は、それらの従属関係に
基づいてきめ細かな優先順位を個々のオブジェクトに割
り当てることができるよう、数値的にかなり離間してい
る。このような細かな優先順位が大まかな優先順位を補
間し、理想的には、高い優先順位のオブジェクトがそれ
よりも低い優先順位のオブジェクトに従属することはめ
ったにない。

【００６４】オブジェクトが更新されるとき、処理は成
功するか、失敗するか、失敗するが進展するかのいずれ
かである。「成功」とは、オブジェクトの先行オブジェ
クトがCodeStore中に存在し、プロセッサ（処理系）が
そのオブジェクトを正しいものとして受け入れたことを
いう。「失敗」とは、先行オブジェクトがCodeStore中
に存在しなかったか、処理されるオブジェクトが誤りで
あったかのいずれかをいう。「失敗するが進展」とは、
プロセッサは失敗したが、処理の結果としてさらなる情
報がCodeStore中に配置されたことをいう。一例とし
て、パーザがソース領域を処理する場合の可能性を考え
てみる。構文解析は成功することができ、これは、ソー
ス領域中に現れたすべての名前がわかっており、ソース
領域に含まれた宣言が正しかったということを意味す
る。あるいはまた、ソース領域に使用される名前の１個
が未知であるかもしれず、ソース領域に含まれる宣言が
誤りかもしれない。これは失敗である。しかし、新たな
情報（たとえばクラスの名前）が収集されるならば、そ
の失敗は、失敗でも進展するものであろう。

【００６５】オブジェクトに対する更新が成功するなら
ば、そのオブジェクトは主待ち行列から取り出され、そ
の処理が完了する（それが後で待ち行列に配置されない
限り）。更新が失敗する（進展してもしなくても）なら
ば、そのオブジェクトは主待ち行列から取り出され、先
入れ先出しで順序が決まる副待ち行列に載せられる。副
待ち行列のノードは、以下に説明する方法で再び処理さ
れる。

【００６６】本発明によると、構文解析は、すべてのノ
ードの更新が成功するか、主待ち行列が空であり、副待
ち行列のすべてのノードを更新する試みがすべてのノー
ドにおいて進展なしの失敗に終わるかのいずれかまで継
続する。前者の場合、構文解析は完了であり、後者の場
合、副待ち行列に残るノードによって表現されるソース
領域は誤りであり、エラー・メッセージが生成される。

【００６７】構文解析の第一の段階で、すべてのインタ
フェースを構文解析する試みが成される。すべてのイン
タフェースとは、本質的に、中括弧に含まれる本体を含
まないすべての関数と、イニシャライザを含まない最高
水準変数宣言と、typedefと、関数本体を含まないクラ
ス、共用体および構造体とを含む。他の宣言を処理する
前のインタフェースの処理は、フォワード宣言を書き、
それを維持する負担をプログラマに課すことなく、フォ
ワード宣言の効果を得る。効率への鍵は、最後の組み込
み以来、変更のない宣言について、すでにCodeStoreに
あるDeclarationオブジェクトを使用して、ただし、ソ
ース・コードが変更したときには更新された、または新
たなDeclarationオブジェクトを使用して、できるだけ
多くの処理を行うことである。

【００６８】ここで図２を参照すると、組み込みが開始
するとき、MacroStoreは、前の組み込みでスキャンされ
たSourceからのMacroを含み、DeclarationStoreは、前
の組み込みの結果を表現するDeclarationオブジェクト
を含む。図示するように、SourceStoreを最高の優先順
位で主WorkQueueに配置する（ブロック１０）。加え
て、２個のMarkerNodeを、１個は型名処理の完了ため
に、もう１個は非型名処理の完了のために、主WorkQueu
eに配置する（ブロック１２）。最高優先順位のDepende
ncyNodeを主WorkQueueから取り出し、従属性を処理する
（ブロック１４、１６）。DependencyNodeがSourceStor
eであるならば、その従属性は、図３のステップの後で
処理する。Sourceであるならば、図４のステップが次に
くる。SourceRegionであるならば、図６のステップが次
にくる。MarkerNodeであるならば、図８のステップが次
にくる。Implementationであるならば、図９のステップ
が次にくる。組み込みは、すべてのDependencyNodeの処
理に成功したとき（ブロック２０）またはDependencyNo
deが組み込みの終了を要求したとき（ブロック１８）に
終了する。これは、たとえば、MarkerNodeが副（再試
行）待ち行列中のノードすべてを正常には処理できない
ときに起こる。

【００６９】次に図３を参照すると、主WorkQueue上の
最優先項目はSourceStore である（ブロック２１）。So
urceStore が待ち行列から取り出されると（図２のブロ
ック１４を参照）、その更新機能が、対応するプロジェ
クト制御ファイルのタイムスタンプをチェックし、必要
ならば、SourceStore に含まれるSourceのリストを更新
する（図３、ブロック２２）。そして、Sourceオブジェ
クトごとに、対応するファイルのタイムスタンプをチェ
ックして、最後の組み込み以来、変更があったかどうか
を判定し（ブロック２４）、各アウト・オブ・デートの
SourceのDependencyNodeを不当としてマークし、主Work
Queueに追加する（ブロック２６）。

【００７０】Sourceの無効化は、そのSourceで定義され
たすべてのMacroを隠す（ブロック２８）。これは、Mac
roStoreが、それらのMacroに関する名前参照に対し、あ
たかもそれらが存在しないかのように返答することを意
味する。ひとたびSourceStoreがすべてのSourceをチェ
ックしたならば、処理は、図２の主ループにしたがって
継続する（図３のブロック２２、２９）。

【００７１】次の段階で、各SourceオブジェクトがSour
ceRegionに分解される。これは、Sourceオブジェクトが
主WorkQueueの一番上に現れるたびに起こる。図４およ
び５は、組み込みの前処理段階を示す。図５のデータ制
御流れ図では、長方形がCodeStore中の持続性オブジェ
クトを表し、楕円が一時的オブジェクトを表す。細い矢
印はオブジェクト間のポインタを表す。太い矢印はデー
タの流れを表す。まず図４を参照すると、主WorkQueue
の一番上のSourceが取り出され、その更新機能が呼び出
される（ブロック３０、３２）。

【００７２】Source更新機能は、図５に示す以下の一時
的オブジェクトを使用する。

【００７３】マクロ定義を抽出し、ソース・コード・フ
ァイルで定義されたマクロを展開するための、ソース・
テキスト６８およびMacroStore７０を取り出し、新たな
マクロ７２および前処理したＣ＋＋トークンのストリー
ムを発するＣ＋＋Preprocessor６２

【００７４】新たなマクロ定義をPreprocessorから取り
出し、MacroStore７０を更新するMacroReconciler６４

【００７５】Preprocessor６２からSourceRegionへのト
ークンのストリームを断つDeclarationIsolator６６

【００７６】まず、Sourceのテキスト・ストリームをMa
croStoreとともにPreprocessorに渡し（図４、ブロック
３２）、Preprocessorがその入力をトークン化する（ブ
ロック３４）。#defineコマンドによって認識される、S
ource中で定義されたMacroはいずれも更新のためにMacr
oReconcilerに渡される（ブロック３６）。定義されたM
acroが既存のMacroと同一であるならば、既存のMacroに
おける隠れた状態を取り出す。同一でなければ、新たな
MacroをMacroStoreに追加し（ブロック３８、４０）、M
acroReconcilerが、新たなMacroまたは変更されたMacro
によって変更することができる、再処理のためのSource
を待ち行列に入れることにより、影響を受けたSourceを
主WorkQueueに追加する（ブロック４２）。次に、Prepr
ocessorが、可能なマクロ展開を求めて各トークンを参
照する（ブロック４４）。これが、当業者によって理解
されるような通常のマクロ展開である。そして、Prepro
cessorから出力されたトークンをDeclarationIsolator
に送って（ブロック４６）、そこで、宣言分離ステッ
プ、優先順位選択ステップおよび待ち行列配置ステップ
に続くことにより、SourceRegionを識別し、新規なもの
または変更されたものをWorkQueueに配置する（ブロッ
ク４８〜５４）。

【００７７】宣言分離は、中括弧、括弧および大括弧を
一致させることにより、トークンのストリームを個々の
宣言に分けることからなる。連結規格および名前空間規
格は、それらに含まれる宣言にわたって分散している。

【００７８】この分離処理の結果として、Sourceのため
のSourceRegionのリストが生成される。すべてＣ＋＋宣
言は、１個のSourceRegionに全体が含まれる。プリプロ
セッサから出力されたトークンのすべてがSourceRegion
に割り当てられる。

【００７９】ソース・コードによってはSourceRegionに
分割できないかもしれない。例えば、中括弧の不一致ま
たはセミコロンの抜けが、宣言の最後を探索する間に、
SourceRegionアルゴリズムをしてファイルの最後にヒッ
トさせる。この場合、エラー・メッセージを発すること
ができ、そのSourceの処理は停止する。

【００８０】このSourceが最後の組み込み中に存在した
ならば、新たに抽出された各SourceRegionを、記憶され
ているSourceRegionと比較する。これらの比較のいずれ
かが正確な一致を出すならば、その新たなバージョンは
削除される。このように、変更のないＣ＋＋宣言を構文
解析したり、他の方法で処理したりする必要はない。こ
の比較は前処理されたトークンにおいて起こるため、注
釈および空白に対する変更が再コンパイルを生じさせる
ことはない。

【００８１】DeclarationIsolatorはまた、各SourceReg
ionをおそらくは型定義領域または非型定義領域として
分類する。SourceRegion中の最高水準トークンが、キー
ワードであるクラス、構造体、共用体typedefまたはenu
mの一つを含むならば、そのSourceRegionはおそらく型
定義領域である。型定義領域は、構文解析パスの数を減
らすため、WorkQueueにおいて非型定義領域よりも優先
順位を与えられる。誤った分類が、本発明の技術を使用
する結果の正しさに影響することはない。

【００８２】分類ののち、SourceRegionおよびそれが表
現するトークンのストリームをCodeStoreに追加する
（ブロック５２）。そして、SourceRegionを主WorkQueu
eに配置する（ブロック５４）。Source中のすべてのテ
キストを処理したのち、前の組み込みから残ったSource
のSourceRegion、すなわち、入ってくるSourceRegionと
で一致しなかったSourceRegionがあるならば、それらを
隠し、処理を図２に続ける（図４のブロック５６、ブロ
ック５８）。

【００８３】要するに、処理の第一段階は、WorkQueue
上のSourceとで始まり、WorkQueue上のSourceRegionと
で終わる。間に、Sourceがプリプロセッサによって汲み
上げられ、MacroStoreが満たされ、使用され、Declarat
ionIsolatorが実行されて、アルゴリズムの次の段階の
ために待ち行列に入れられるSourceRegionを作り出す。
この第一段階は、主待ち行列の一番前にSourceRegionが
あるときに終了する（図６、ブロック８０）。

【００８４】次の処理段階は、WorkQueue上のSourceReg
ion中で宣言された「インタフェース」を収集するよう
に設計されており、これを図６および７に示す。インタ
フェースとは、大まかには、ヘッダファイル中のＣ＋＋
宣言のようなものであるが、次のように定義される。

【００８５】・変数の型。const整数変数は特別に扱わ
れる（以下を参照）・関数の復帰型および引数リスト。デフォルト関数引数
は除く。・型の種類（クラス、構造体、共用体またはenum）。ク
ラス、構造体または共用体に含まれるインタフェース・列挙子イニシャライザ・typedef定義・アクセス宣言有効範囲・extern宣言および名前空間に含まれるインタフェース・関数テンプレート復帰型、引数リストおよびパラメー
タ宣言・クラス・テンプレート・パラメータ宣言、種類および
含まれるインタフェース

【００８６】定数式で初期化された定数整数型変数およ
びイニシャライザをもつ列挙子は、型を定義する定数式
に現れることがあるため、特殊なケースとして扱う。

【００８７】概して、インタフェースは、SourceRegion
に記憶されたトークンを構文解析することによって抽出
される。しかし、インタフェースは、それ自体が型定義
のサイズに従属することができる定数式に従属すること
ができるため、構文解析だけでは不十分であり、非テン
プレートを構文解析するためにはテンプレートを具体化
しなければならないかもしれない。

【００８８】アルゴリズムのこの段階で使用される一時
的オブジェクトを図７に示す。次のものである。

【００８９】SourceRegionのトークンを読み、Declarat
ionStore７５中のプログラマ定義記号を参照することに
よってそれらを解析してDeclaration７６またはエラー
・メッセージを出すParser７３

【００９０】Parserによって作成された新たなDeclarat
ion７６を取り出し、それをDeclarationStore７５にロ
ードし、新たな宣言の存在によって変更されうる構文解
析をもつDeclaration７６のSourceRegion６９オブジェ
クトをWorkQueue６０に配置するDeclarationReconciler
７４

【００９１】Ｃ＋＋式を取り出し、その式が評価するＣ
＋＋型、すなわち、変数の型、関数の復帰型または式の
結果型を与えるTypeAnalyzer７７

【００９２】Ｃ＋＋型を取り出し、その型の値のＣ＋＋
サイズを返すObjectModel７８

【００９３】Ｃ＋＋式を取り出し、その式のＣ＋＋値の
計算結果を返すExpressionAnalyzer７９。定数式だけを
評価する。

【００９４】図６を参照すると、IncorporatorがWorkQu
eueの一番上からSourceRegionを取り、その更新機能を
呼び出すたびに（ブロック８０）、SourceRegionのToke
nStreamがParserに渡される（ブロック８２）。パーザ
は、既存のCodeStoreを使用して、Ｃ＋＋宣言を形成す
るのに使用した名前を参照しながら、新たな宣言名を求
めてスキャンする（ブロック８６）。新たな宣言が認識
されると、パーザはDeclarationReconcilerを呼び出
す。DeclarationReconcilerは、Declaration名をDeclar
ationStoreと比較し（ブロック８８）、新たなDeclarat
ionを追加するか、DeclarationStore中にすでにあるも
のを変更する（ブロック９０）。制御がParserに戻る
と、新たに追加された宣言が記録されており、その後の
参照に利用できる（ブロック９２）。ひとたびすべての
トークンが処理されると、主ループのステップは処理を
続ける（図６のブロック８４、９４）。

【００９５】いくつかの宣言の構文解析は、Declaratio
nStore中に２個以上のエントリを生じさせるかもしれな
い。これらのケースは、複合宣言、無名共用体および列
挙を含む。たとえば次のとおりである。

【００９６】 // Compound declaration: 1 parse, 2 declarations entered. int i,j; // Anonymous union: 1 parse, 3 declarations union { int u; float v;}; // enumeration, 1 parse, 3 declarations. enum Polygon { triangle=3, rectangle=4};

【００９７】後者の二つのケースは、一致する中括弧の
中から包囲する有効範囲に宣言を入れ込む。

【００９８】DeclarationRecocilerでは、このDeclarat
ionのSourceRegionを構文解析する際にParserによって
使用される他のDeclarationを「先行」宣言として記録
する（ブロック９２）。簡潔に述べるならば、各Source
Regionは、それを構文解析するために使用されるDeclar
ation（先行）へのポインタのリストを有し、各Declara
tionは、それが参照されるSourceRegion（従属）へのポ
インタのリストを有している。これらのポインタは、以
下に説明するようなオーバロード処理に使用される。

【００９９】関数定義の場合、DeclarationReconciler
は、関数本体のための新たなエントリをWorkQueueに作
成する。変数定義の場合、DeclarationReconcilerは、
変数イニシャライザのための同様なエントリを作成す
る。これらのエントリは、Implementation構文解析の間
に考慮されるよう、どのSourceRegionエントリよりも低
い優先順位でWorkQueueに配置される。成功したSourceR
egionはWorkQueueから取り出され、インタフェース構文
解析ステップは終了する。

【０１００】インタフェース構文解析ステップの失敗
は、プログラマによって提供される誤ったソース・テキ
ストまたはDeclarationStore中の名前を参照していると
きのParserの障害のいずれかの結果として起こりうる。
一般に、プログラマが宣言を省略したかどうか、また
は、宣言がWorkQueueのさらに下のほうで後のSourceReg
ionに現れるかどうかを判断することはできないため、
構文解析に失敗したSourceRegionは副（再試行）待ち行
列に配置される。

【０１０１】インタフェース構文解析が失敗するとして
も、宣言がDeclarationStoreに入れられているかもしれ
ない。Parserが、その宣言がクラスであると判断するな
らば、それは、以下に説明するように、DeclarationRec
oncilerをして「部分的に定義済み」とマークされたク
ラス宣言をDeclarationStoreに入れさせる。

【０１０２】インタフェースを構文解析するとき、クラ
ス・テンプレートのインスタンスの名前に遭遇するかも
しれない。構文解析するために具体化されたテンプレー
トの本体が必要であり、そのテンプレートがまだ十分に
は具体化されていないならば、構文解析は失敗する（他
の名前参照の失敗の場合と同様）。加えて、テンプレー
ト具体化のDependencyNodeがWorkQueueに追加される。
ちょうどＣ＋＋言語の規則が指図するように、テンプレ
ート・クラス名だけがフォワードクラス宣言の等価を作
成する。クラスの本体またはメンバ関数の本体のいずれ
も、必要とされないうちは具体化されない。すべての場
合において、テンプレート展開が失敗するならば、従属
するSourceRegionの構文解析は成功しない。

【０１０３】各インタフェース構文解析ステップの最後
には、１個のSourceRegionが構文解析されるためにWork
Queueから取り出されており、１個以上の宣言がDeclara
tionStoreに追加されているか、SourceRegionが副ＦＩ
ＦＯQueueに配置されているかのいずれかであり、ある
いは、テンプレート・インスタンスのクラス、enumおよ
び宣言の場合には、これらの両方が起こっているかもし
れない。いずれかの宣言がDeclarationStoreに入ったな
らば、Incorporatorが、それが進展したことを記録す
る。

【０１０４】インタフェース構文解析の第一のパスは、
型名処理の完了のためのMarkerNodeに遭遇するまで継続
する（図８、ブロック９６）。MarkerNodeが待ち行列か
ら外されるとき、副（再試行）待ち行列のサイズが試験
される（ブロック９８）。

【０１０５】再試行待ち行列が空ではないならば、それ
は、そのDepencencyNodeそれぞれを更新することによ
り、待ち行列が空になるか（更新の成功により）、すべ
てのDependencyNode更新が失敗するまで、繰り返し処理
される（ブロック１００、１０２）。ひとたび副（再試
行）待ち行列が空になると、処理は主ループに戻る（ブ
ロック９８、１０４）。

【０１０６】次のDependencyNodeがWorkQueueの主待ち
行列から取り出され、その更新機能が呼び出される（図
２のブロック２０、１２、１４）。この段階で遭遇され
るSourceRegionは、前と同じ方法で処理される。これら
二つの段階を有する全体の目的は、見当たらない型名か
らの構文解析失敗の数を減らすことである。まず、型名
SourceRegionに戻ることにより、型名を含まない領域を
試す前に、すべての型名を抽出する。非型名の完了のた
めに第二のMarkerNodeが主WorkQueueの一番上に上る
と、再試行待ち行列を再び収束まで処理する。

【０１０７】上記の記述は、クラス宣言に用いるための
特殊な処理に関する。クラス宣言は、それらがメンバ宣
言を含む理由から、特殊なケースとして扱われる。その
ようなメンバ宣言のいくつかは、他の宣言の明瞭な構文
解析にきわめて重要な型であるかもしれない。含まれる
型名、含まれるメンバ関数のインタフェースおよび含ま
れるメンバ変数のインタフェースは、他の型の定義に現
れるかもしれないsizeofを計算するのに必要である。１
個または数個のメンバを構文解析できなくても、クラス
の構文解析の完全な失敗を招くことはなく、進展しない
ということもない。

【０１０８】たとえば、Parserは、Ｙの本質がわからな
いとしても、Ｘがこのコードにおいてクラスであると判
断することができる。

【０１０９】 struct X { Y* y; // Parse fails if Y is not in the declaration store. };

【０１１０】Ｘがクラスであるという情報を記録するこ
とは、Ｘのメンバを指定するのに使用される他のクラス
がそれらの宣言において型名Ｘを使用するとき、きわめ
て重要である。たとえば、以下のソース・コード・オブ
ジェクトが上記のソース・コード・オブジェクトの後に
現れるならば、コンパイラは、Ｘが型名であることを知
らなければならない。

【０１１１】

【０１１２】したがって、それらの含まれる宣言の構文
解析が失敗したときでも、クラス宣言をDeclarationSto
reに入れなければならない。さらには、入れ子型を捜す
ためにも、クラス本体を構文解析しなければならない。
クラスが完了したならば、そのクラスを再び考慮する必
要はないため、これを実施したところで、構文解析に成
功したメンバ宣言があるならばそれらを保存することが
できる。

【０１１３】クラス宣言の特殊な処理は以下のものから
なる。ParserがＣ＋＋キーワードの一つ、すなわちクラ
ス、構造体、共用体またはenumを見たのち、前に宣言さ
れていない識別子を見るならば、Parserは、その識別子
によって命名されるクラス宣言を作成し、そのクラスま
たはenumを「部分的に定義済み」とマークする。このク
ラス宣言はDeclarationReconcilerに渡され、このDecla
rationReconcilerがそれをDeclarationStoreに入れて、
クラスメンバのためのDeclarationStoreを作成する。ク
ラス本体構文解析の残りの作業が成功し、その結果がク
ラス宣言であるならば、そのクラスは「定義済み」とマ
ークされる。そうでなければ、Parserがエラーを報告
し、しかし、部分的に定義されたクラス宣言がDeclarat
ionStore中に残り、Incorporatorは、進展したものとし
てマークされる。

【０１１４】部分的定義は特殊なケースとして説明する
が、この動作は、Ｃ＋＋宣言の構文解析には典型的なも
のである。Ｃ＋＋は、識別子が構文解析されるとただち
にその型宣言がそのようなものとして認知されるという
ことを指定する。たとえば、１パスパーザでは、次のよ
うなコードは、Ｚの使用がクラス宣言の右中括弧の前に来るとして
も、規則に適合している。

【０１１５】定数式が、変数および関数のインタフェー
スに現れる型を含む型を定義する配列の上下限およびテ
ンプレート引数に現れることがある。定数式はまた、す
べて直接またはsizeof演算子を介して定数式に現れるこ
とがあるconst 整数変数、列挙子およびビット・フィー
ルド長のイニシャライザ中に現れることもできる。その
結果、すべてのインタフェースを構文解析するために
は、インタフェース構文解析掃引中に定数式を構文解析
し、評価しなければならない。

【０１１６】定数式は、値が直接与えられるリテラル
と、実行時情報、すなわち、列挙子の値（定数整数オブ
ジェクト）、定数式で初期化された定数整数変数の値お
よびsizeof式の値なしで値を演繹することができるオブ
ジェクトからなる。演繹しなければならない値は、以下
の方法で処理される。

【０１１７】列挙子の値は、CodeStoreに入れられる際
に前計算される。列挙子は、定数式で初期化しなければ
ならない。ひとたび列挙が処理されていることをParser
が認識すると、Parserは、クラス処理におけるように、
列挙名をDeclarationReconcilerに送る。そして、Parse
rは、含まれる列挙子の構文解析を試みる。イニシャラ
イザが構文解析され、型が解析され、評価される。結果
が定数整数値ではないならば、その構文解析ステップは
失敗である。

【０１１８】constと宣言された整数変数は、列挙子の
場合と同様に前計算される。これらの変数は、定数式で
初期化する必要はなく、したがって、非const値が構文
解析ステップを失敗させることはない。

【０１１９】sizeof式の値は必要に応じて計算される。
sizeofのオペランドは、インタフェース構文解析中に遭
遇されるたびに構文解析される。sizeofに対する引数
は、型名または式のいずれかであることができる。型名
であるならば、それは完全に定義された型まで解かなけ
ればならない。そうしなければ、構文解析は失敗する。
式であるならば、その式を型解析し、得られる型のサイ
ズを計算する。

【０１２０】インタフェースの構文解析に成功したの
ち、WorkQueueは、DeclarationがDeclarationStoreに追
加されたときに見いだされた関数本体および変数イニシ
ャライザごとに「インプリメンテーション」と呼ばれる
１個のエントリを有する。インプリメンテーション構文
解析の際、すなわち、主WorkQueueの最優先項目がImple
mentationであるときに（図９、ブロック１１０）、こ
れらのエントリが一度に１個ずつ取り出され（ブロック
１１２）、解析される（ブロック１１４）。この構文解
析で遭遇するＣ＋＋宣言を使用して、関数の局所有効範
囲を表す、DeclarationStoreに挿入するためのDeclarat
ionが作成される。この構文解析で遭遇するＣ＋＋式はT
ypeAnalyzerに渡される。これらのステップが、インプ
リメンテーションとDeclarationとの間に追加すべき、
それを構文解析し、型解析するために必要なさらなる従
属性グラフ・アークを生じさせる（ブロック１１６）。

【０１２１】インタフェースの構文解析におけるよう
に、クラス・テンプレート・インスタンス名の参照がク
ラス・テンプレート展開を生じさせるかもしれない。加
えて、TypeAnalyzerが関数呼び出しを関数テンプレート
名に一致させるかもしれない。対応するテンプレート・
インスタンス名が前に使用されたことがないならば、テ
ンプレート・インスタンスの本体は、他のどのインプリ
メンテーションよりも下でWorkQueueに配置される。こ
れらのインプリメンテーションは、それらのWorkQueue
エントリがこのインプリメンテーション構文解析掃引中
に遭遇されたときに処理される。ひとたび型解析がうま
く完了したならば（ブロック１１６）、そのインプリメ
ンテーションは、機械コードを生成するのに適した、よ
り簡単な形態に変形される（ブロック１１８）。インプ
リメンテーション処理のこの段階で、より効率的な機械
コードが生成されるよう、この簡単な形態を最適化する
ことができる（ブロック１２０）。そして、インプリメ
ンテーション処理を続けて機械コードを生成し、それを
プログラムに連結したのち（ブロック１２２、１２
４）、本発明の主ループに戻ることができる（ブロック
１２６）。この簡潔なパターンの例外は、以下に論じる
ようなオーバロードによって起こる。

【０１２２】インプリメンテーション構文解析の際のテ
ンプレートの展開が、インタフェースまたは他のインプ
リメンテーション構文解析で使用される名前空間に新た
なDeclarationを入れ込むおそれがある。たとえば、ク
ラス・テンプレートにおけるインライン・フレンド関数
を考えてみる。

【０１２３】 template<class T> class X { public: friend int operator==(const T&a, const T&b){return a.quiv(b);} };

【０１２４】テンプレートの具体化の際、この演算子が
大域名前空間に加えられる。入れ込まれたのち、このイ
ンタフェースを考慮せずにコンパイルされた関数は不当
になるかもしれない。たとえば次のものである。

【０１２５】

【０１２６】この地点まで誤りはない。この関数を組み
込むと、次のようになる。

【０１２７】

【０１２８】この入れ込みはfnc a の型解析を変更す
る。関数のオーバロードは、型に対して同様な効果を及
ぼすことができる。たとえば、次のようなコードを構文
解析したと仮定する。

【０１２９】 int foo(int I){ return I;} int bar[10*sizeof(foo(1.0))];

【０１３０】式１．０がintに変換され、唯一の関数foo
()、intの復帰型が配列サイズ式に使用される。そし
て、次のようなSourceRegionに遭遇する。

【０１３１】double foo(float f){ return f+0.5;}

【０１３２】ここで、バーの型を再評価して配列のサイ
ズを修正しなければならない。

【０１３３】これらの例はいずれも、CodeStore更新を
もインプリメントする汎用機構によって扱われる。何箇
所かで述べたように、Declarationが参照されるごと、
ポインタがDeclarationのDependencyNodeに配置され
て、参照する側のDependencyNodeを逆に指し示す。この
わかりやすい使用のリストを用いて、宣言の入れ込みお
よびオーバロードの存在におけるDeclarationを修正す
る。オーバロードされた名前の場合、修正は簡単であ
る。同じ名前の宣言のユーザをCodeStoreから取り出
し、それらのSourceRegionを再処理のための待ち行列に
入れる。入れ込まれた演算子および大域演算子の場合、
変換演算子のすべての使用を、入れ込まれた演算子の引
数として、上述した型の待ち行列に入れなければならな
い。

【０１３４】WorkQueueエントリは常に最高優先順位の
順序で処理されるため、インタフェース構文解析サイク
ルがインプリメンテーション構文解析掃引を中断するこ
ともある。ひとたびWorkQueue中の最後のインプリメン
テーション・エントリに達したならば、組み込みは終了
である。

【０１３５】組み込みが正常に終了したならば、Declar
ationStoreを、点検およびその後のコンパイルを含むさ
らなる処理に引き渡すことができる。組み込みが失敗し
たならば、一般的には、プログラマが誤りおよびその誤
りの場所を通知される。プログラマは、DeclarationSto
reを検査してソース・コードを修正する必要があるかも
しれない。この場合、DeclarationStoreの詳細な検査
は、部分的にしか定義されて宣言があるかもしれないこ
とを認識している必要がある。

【０１３６】まとめとして、本発明の構成に関して以下
の事項を開示する。（１）ソース・コードで書かれたＣ＋＋プログラムをコ
ンパイルする方法において、前記ソース・コードの最初
の掃引を一度に１宣言ずつ実施して宣言を得るステップ
と、前記最初の掃引で識別子が全部はわからなった宣言
を別にしておくステップと、前記ソース・コードの少な
くとも１回の後続の掃引を実施して、前記最初の掃引か
ら別にしておいた宣言の定義を得るステップと、を含む
ことを特徴とする方法。（２）前記ソース・コードの各掃引ののち、前記宣言を
プログラム表現に保存するステップをさらに含む上記
（１）記載の方法。（３）前記プログラム表現がコンパイルとコンパイルと
の間で持続する上記（２）記載の方法。（４）前記プログラム表現をプログラム・データベース
に保存する上記（３）記載の方法。（５）前記宣言をプログラム表現に保存する前記ステッ
プが、新たな定義または変更された定義で既存の表現を
更新するステップを含む上記（２）記載の方法。（６）順序づけまたはフォワード宣言なしでＣ＋＋ソー
ス・コードで書かれたプログラムを構文解析する方法に
おいて、前記構文解析を最高水準宣言に対して直接実施
することを特徴とする方法。（７）ヘッダ・ファイルなしでＣ＋＋ソース・コードで
書かれたプログラムを構文解析する方法において、前記
構文解析を最高水準宣言に対して直接実施することを特
徴とする方法。（８）Ｃ＋＋ソース・コード・プログラムを、字句解析
を実施して前記ソース・コード・プログラムをトークン
化し、構文解析および意味解析を実施して前記ソース・
コード・プログラムの中間表現を生成する機能強化され
たコンパイラにおいてコンパイルする方法において、そ
れぞれが前記ソース・コード・プログラム中の宣言をプ
ログラム定義から構文解析するための情報を蓄積する複
数の構文解析パスを通して前記トークン化したソース・
コード・プログラムを構文解析するステップを特徴とす
る方法。（９）前記複数のパスが最初のパスおよび後続のパスを
少なくとも含み、前記最初のパスで、前記トークン化し
たソース・コード・プログラムの型宣言だけを構文解析
する上記（８）記載の方法。（１０）前記後続のパスで、前記ソース・コード・プロ
グラム中の型名、変数および関数に関する情報を蓄積す
る上記（９）記載の方法。（１１）前記最初のパスおよび後続のパスが３回のパス
を含み、前記ソース・コード・プログラムからの関数お
よび変数の型を第二のパスで構文解析し、前記ソース・
コード・プログラムからの変数イニシャライザおよび関
数本体を第三のパスで構文解析する上記（９）記載の方
法。（１２）各構文解析パスののち、構文解析した宣言のプ
ログラム表現を保存するステップをさらに含む上記
（８）記載の方法。（１３）前記プログラム表現がコンパイルとコンパイル
との間で持続する上記（１２）記載の方法。（１４）前記プログラム表現をプログラム・データベー
スに保存する上記（１３）記載の方法。（１５）構文解析パスののち、前記構文解析パス中に得
られた宣言に関する新たな情報または変更された情報で
前記プログラム表現を更新するステップをさらに含む上
記（１２）記載の方法。（１６）Ｃ＋＋ソース・コードで書かれたプログラムを
コンパイルするためのコンパイラにおいて、前記ソース
・コードの複数の構文解析掃引を実施することにより、
前記プログラムで使用される宣言の定義を前記ソース・
コードから直接抽出するためのパーザを含むことを特徴
とするコンパイラ。（１７）前記ソース・コードの前記構文解析掃引からの
オブジェクトを記憶するための手段をさらに含む上記
（１６）記載のコンパイラ。（１８）オブジェクトを記憶するための前記手段が、構
文解析掃引から構文解析された前記ソース・コードの表
現をプログラム表現として記憶するための手段を含む上
記（１７）記載のコンパイラ。（１９）オブジェクトを記憶するための前記手段が、オ
ブジェクトを、コンパイルとコンパイルとの間で持続す
る表現で記憶するための手段を含む上記（１７）記載の
コンパイラ。（２０）オブジェクトを記憶するための前記手段がプロ
グラム・データベースを含む上記（１９）記載のコンパ
イラ。（２１）オブジェクトを記憶するための前記手段が、構
文解析掃引から構文解析された前記ソース・コードの全
プログラム的表現を前記プログラム・データベースに記
憶するための手段を含み、後続の構文解析掃引ののち、
前記全プログラム的表現を更新するための手段をさらに
含む上記（２０）記載のコンパイラ。（２２）オブジェクトを記憶するための前記手段が前記
ソース・コード・プログラムからのトークン順序の優先
順位つき待ち行列を記憶するための手段を含み、各トー
クン順序が構文解析のための少なくとも１個の宣言を含
む上記（１８）記載のコンパイラ。（２３）前記優先順位つき待ち行列が主待ち行列および
副待ち行列を含み、前記主待ち行列が、構文解析掃引の
前に前記ソース・コード・プログラムから最初に得られ
た少なくとも１個のトークン順序を記憶するためのもの
であり、前記副待ち行列が、構文解析掃引ののち、構文
解析できなかった宣言のトークン順序を記憶するための
ものである上記（２２）記載のコンパイラ。（２４）マクロ定義を抽出し、前記ソース・コード・プ
ログラムで定義されたマクロを展開し、新たなマクロを
前記プログラム表現に発送し、前処理したＣ＋＋トーク
ンのストリームを前記主待ち行列に発送するためのプリ
プロセッサをさらに含む上記（２３）記載のコンパイ
ラ。（２５）前記プリプロセッサが前記プログラム表現から
前記マクロ定義を抽出する上記（２４）記載のコンパイ
ラ。（２６）順序づけまたはフォワード宣言なしでＣ＋＋ソ
ース・コードで書かれたプログラムをコンパイルするた
め機構において、前記Ｃ＋＋ソース・コードから最高水
準宣言を直接構文解析するための手段を含むことを特徴
とする機構。（２７）ヘッダ・ファイルなしでＣ＋＋ソース・コード
で書かれたプログラムをコンパイルするため機構におい
て、前記Ｃ＋＋ソース・コードから最高水準宣言を直接
構文解析するための手段を含むことを特徴とする機構。（２８）ソース・コードで書かれたＣ＋＋プログラムを
コンパイルするための方法を機械によって実行可能な命
令のプログラムで具現化する、前記機械によって読み出
し可能なプログラム記憶装置において、前記方法ステッ
プが、前記ソース・コードの最初の掃引を一度に１宣言
ずつ実施して宣言を得るステップと、前記最初の掃引で
識別子が全部はわからなった宣言を別にしておくステッ
プと、前記ソース・コードの少なくとも１回の後続の掃
引を実施して、前記最初の掃引から別にしておいた宣言
の定義を得るステップと、を含むものであることを特徴
とするプログラム記憶装置。（２９）順序づけまたはフォワード宣言なしでＣ＋＋ソ
ース・コードで書かれたプログラムを構文解析するため
の方法を機械によって実行可能な命令のプログラムで具
現化する、前記機械によって読み出し可能なプログラム
記憶装置において、前記方法ステップが、最高水準宣言
を直接構文解析するステップを含むものであることを特
徴とするプログラム記憶装置。（３０）ヘッダ・ファイルなしでＣ＋＋ソース・コード
で書かれたプログラムを構文解析するための方法をプロ
グラムで具現化する、機械によって読み出し可能なプロ
グラム記憶装置において、前記方法ステップが、最高水
準宣言を直接構文解析するステップを含むものであるこ
とを特徴とするプログラム記憶装置。（３１）Ｃ＋＋ソース・コード・プログラムを、字句解
析を実施して前記ソース・コード・プログラムをトーク
ン化し、構文解析および意味解析を実施して前記ソース
・コード・プログラムの中間表現を生成することによっ
てコンパイルするための方法を機能強化されたコンパイ
ラのための命令のプログラムで具現化する、機械によっ
て読み出し可能なプログラム記憶装置において、前記方
法ステップが、それぞれが前記ソース・コード・プログ
ラム中の宣言をプログラム定義から構文解析するための
情報を蓄積する多数の構文解析パスを通して前記トーク
ン化したソース・コード・プログラムを構文解析するス
テップを含むものであることを特徴とするプログラム記
憶装置。

【図面の簡単な説明】

【図１】簡易な１パス・コンパイラでの従来のコンパイ
ルを示す略図である。

【図２】プログラムのコンパイルまたは再コンパイルに
用いるための本発明の多重パス構文解析技術の主ループ
を示す流れ図である。

【図３】本発明の一つの態様による、ソース・ファイル
変更の検出を示す流れ図である。

【図４】本発明のもう一つの態様による、再コンパイル
中のソース・ファイル更新を示す流れ図である。

【図５】図４に示すステップのデータ制御の流れを表現
した図である。

【図６】本発明のさらなる態様による、SourceRegionと
呼ばれる持続性オブジェクトの更新を示す流れ図であ
る。

【図７】図６に示すステップのデータ制御の流れを表現
した図である。

【図８】本発明のもう一つの態様による、MarkerNodeと
呼ばれる持続性オブジェクトの処理を示す流れ図であ
る。

【図９】本発明のもう一つの態様による、Implementati
onと呼ばれる持続性オブジェクトの処理を示す流れ図で
ある。

【符号の説明】

６０ WorkQueue ６２ Preprocessor ６４ MacroReconciler ６６ DeclarationIsolator ６８ Source ６９ SourceRegion ７０ MacroStore ７１ Macro ７２ TokenStream ７３ Parser ７４ DeclarationReconciler ７５ DeclarationStore ７６ Declaration ７７ TypeAnalyzer ７８ ObjectModel ７９ＥｘｐｒｅｓｓｉｏｎＡｎａｌｙｚｅｒ

───────────────────────────────────────────────────── フロントページの続き (72)発明者マイケル・カラスィックアメリカ合衆国10562、ニューヨーク州オッシニングブルッククラブドライブ 11−４ (72)発明者ジョン・ジョセフ・バートンアメリカ合衆国ニューヨーク州マホポックテニスコートロード 13 (72)発明者デレック・リェバーアメリカ合衆国10598、ニューヨーク州ヨークタウンハイツウェルシュコート 2497 (72)発明者デヴィット・ジョセフ・ストレッターカナダ国エム１ブイ２イー８、オンタリオ州スカーボラウキャンパニアクレセント 97

Claims

【特許請求の範囲】

【請求項１】ソース・コードで書かれたＣ＋＋プログラ
ムをコンパイルする方法において、前記ソース・コードの最初の掃引を一度に１宣言ずつ実
施して宣言を得るステップと、前記最初の掃引で識別子が全部はわからなった宣言を別
にしておくステップと、前記ソース・コードの少なくとも１回の後続の掃引を実
施して、前記最初の掃引から別にしておいた宣言の定義
を得るステップと、を含むことを特徴とする方法。
【請求項２】前記ソース・コードの各掃引ののち、前記
宣言をプログラム表現に保存するステップをさらに含む
請求項１記載の方法。
【請求項３】前記プログラム表現がコンパイルとコンパ
イルとの間で持続する請求項２記載の方法。
【請求項４】前記プログラム表現をプログラム・データ
ベースに保存する請求項３記載の方法。
【請求項５】前記宣言をプログラム表現に保存する前記
ステップが、新たな定義または変更された定義で既存の
表現を更新するステップを含む請求項２記載の方法。
【請求項６】順序づけまたはフォワード宣言なしでＣ＋
＋ソース・コードで書かれたプログラムを構文解析する
方法において、前記構文解析を最高水準宣言に対して直
接実施することを特徴とする方法。
【請求項７】ヘッダ・ファイルなしでＣ＋＋ソース・コ
ードで書かれたプログラムを構文解析する方法におい
て、前記構文解析を最高水準宣言に対して直接実施する
ことを特徴とする方法。
【請求項８】Ｃ＋＋ソース・コード・プログラムを、字
句解析を実施して前記ソース・コード・プログラムをト
ークン化し、構文解析および意味解析を実施して前記ソ
ース・コード・プログラムの中間表現を生成する機能強
化されたコンパイラにおいてコンパイルする方法におい
て、それぞれが前記ソース・コード・プログラム中の宣言を
プログラム定義から構文解析するための情報を蓄積する
複数の構文解析パスを通して前記トークン化したソース
・コード・プログラムを構文解析するステップを特徴と
する方法。
【請求項９】前記複数のパスが最初のパスおよび後続の
パスを少なくとも含み、前記最初のパスで、前記トーク
ン化したソース・コード・プログラムの型宣言だけを構
文解析する請求項８記載の方法。
【請求項１０】前記後続のパスで、前記ソース・コード
・プログラム中の型名、変数および関数に関する情報を
蓄積する請求項９記載の方法。
【請求項１１】前記最初のパスおよび後続のパスが３回
のパスを含み、前記ソース・コード・プログラムからの
関数および変数の型を第二のパスで構文解析し、前記ソ
ース・コード・プログラムからの変数イニシャライザお
よび関数本体を第三のパスで構文解析する請求項９記載
の方法。
【請求項１２】各構文解析パスののち、構文解析した宣
言のプログラム表現を保存するステップをさらに含む請
求項８記載の方法。
【請求項１３】前記プログラム表現がコンパイルとコン
パイルとの間で持続する請求項１２記載の方法。
【請求項１４】前記プログラム表現をプログラム・デー
タベースに保存する請求項１３記載の方法。
【請求項１５】構文解析パスののち、前記構文解析パス
中に得られた宣言に関する新たな情報または変更された
情報で前記プログラム表現を更新するステップをさらに
含む請求項１２記載の方法。
【請求項１６】Ｃ＋＋ソース・コードで書かれたプログ
ラムをコンパイルするためのコンパイラにおいて、前記
ソース・コードの複数の構文解析掃引を実施することに
より、前記プログラムで使用される宣言の定義を前記ソ
ース・コードから直接抽出するためのパーザを含むこと
を特徴とするコンパイラ。
【請求項１７】前記ソース・コードの前記構文解析掃引
からのオブジェクトを記憶するための手段をさらに含む
請求項１６記載のコンパイラ。
【請求項１８】オブジェクトを記憶するための前記手段
が、構文解析掃引から構文解析された前記ソース・コー
ドの表現をプログラム表現として記憶するための手段を
含む請求項１７記載のコンパイラ。
【請求項１９】オブジェクトを記憶するための前記手段
が、オブジェクトを、コンパイルとコンパイルとの間で
持続する表現で記憶するための手段を含む請求項１７記
載のコンパイラ。
【請求項２０】オブジェクトを記憶するための前記手段
がプログラム・データベースを含む請求項１９記載のコ
ンパイラ。
【請求項２１】オブジェクトを記憶するための前記手段
が、構文解析掃引から構文解析された前記ソース・コー
ドの全プログラム的表現を前記プログラム・データベー
スに記憶するための手段を含み、後続の構文解析掃引の
のち、前記全プログラム的表現を更新するための手段を
さらに含む請求項２０記載のコンパイラ。
【請求項２２】オブジェクトを記憶するための前記手段
が前記ソース・コード・プログラムからのトークン順序
の優先順位つき待ち行列を記憶するための手段を含み、
各トークン順序が構文解析のための少なくとも１個の宣
言を含む請求項１８記載のコンパイラ。
【請求項２３】前記優先順位つき待ち行列が主待ち行列
および副待ち行列を含み、前記主待ち行列が、構文解析
掃引の前に前記ソース・コード・プログラムから最初に
得られた少なくとも１個のトークン順序を記憶するため
のものであり、前記副待ち行列が、構文解析掃引のの
ち、構文解析できなかった宣言のトークン順序を記憶す
るためのものである請求項２２記載のコンパイラ。
【請求項２４】マクロ定義を抽出し、前記ソース・コード・プログラムで定義されたマクロを
展開し、新たなマクロを前記プログラム表現に発送し、前処理したＣ＋＋トークンのストリームを前記主待ち行
列に発送するためのプリプロセッサをさらに含む請求項
２３記載のコンパイラ。
【請求項２５】前記プリプロセッサが前記プログラム表
現から前記マクロ定義を抽出する請求項２４記載のコン
パイラ。
【請求項２６】順序づけまたはフォワード宣言なしでＣ
＋＋ソース・コードで書かれたプログラムをコンパイル
するため機構において、前記Ｃ＋＋ソース・コードから
最高水準宣言を直接構文解析するための手段を含むこと
を特徴とする機構。
【請求項２７】ヘッダ・ファイルなしでＣ＋＋ソース・
コードで書かれたプログラムをコンパイルするため機構
において、前記Ｃ＋＋ソース・コードから最高水準宣言
を直接構文解析するための手段を含むことを特徴とする
機構。
【請求項２８】ソース・コードで書かれたＣ＋＋プログ
ラムをコンパイルするための方法を機械によって実行可
能な命令のプログラムで具現化する、前記機械によって
読み出し可能なプログラム記憶装置において、前記方法
ステップが、前記ソース・コードの最初の掃引を一度に１宣言ずつ実
施して宣言を得るステップと、前記最初の掃引で識別子が全部はわからなった宣言を別
にしておくステップと、前記ソース・コードの少なくとも１回の後続の掃引を実
施して、前記最初の掃引から別にしておいた宣言の定義
を得るステップと、を含むものであることを特徴とする
プログラム記憶装置。
【請求項２９】順序づけまたはフォワード宣言なしでＣ
＋＋ソース・コードで書かれたプログラムを構文解析す
るための方法を機械によって実行可能な命令のプログラ
ムで具現化する、前記機械によって読み出し可能なプロ
グラム記憶装置において、前記方法ステップが、最高水
準宣言を直接構文解析するステップを含むものであるこ
とを特徴とするプログラム記憶装置。
【請求項３０】ヘッダ・ファイルなしでＣ＋＋ソース・
コードで書かれたプログラムを構文解析するための方法
をプログラムで具現化する、機械によって読み出し可能
なプログラム記憶装置において、前記方法ステップが、
最高水準宣言を直接構文解析するステップを含むもので
あることを特徴とするプログラム記憶装置。
【請求項３１】Ｃ＋＋ソース・コード・プログラムを、
字句解析を実施して前記ソース・コード・プログラムを
トークン化し、構文解析および意味解析を実施して前記
ソース・コード・プログラムの中間表現を生成すること
によってコンパイルするための方法を機能強化されたコ
ンパイラのための命令のプログラムで具現化する、機械
によって読み出し可能なプログラム記憶装置において、
前記方法ステップが、それぞれが前記ソース・コード・プログラム中の宣言を
プログラム定義から構文解析するための情報を蓄積する
多数の構文解析パスを通して前記トークン化したソース
・コード・プログラムを構文解析するステップを含むも
のであることを特徴とするプログラム記憶装置。