JPH09101897A - オブジェクト指向ｃ＋＋言語のソースコードから実行可能コードを生成する方法および装置 - Google Patents

Abstract

(57)【要約】 【課題】 アプリケーションプログラムとそれに関連す
るヘッダファイルとをコンパイルしてＣ＋＋の実行可能
コードを生成する方法において、ヘッダファイルのみが
変更された際の、膨大な再コンパイルの負担をなくす。 【解決手段】 ヘッダファイルのコンパイルコードをク
ラス定義のオブジェクトインスタンスへのアクセスを実
施するアクセッサを含むものとして生成し、アプリケー
ションプログラムのコンパイルコードを、オブジェクト
リファレンスを該当するアクセッサへのプロシージャコ
ールに置き換えたものとして生成し、ヘッダファイルの
コンパイルコードとアプリケーションプログラムのコン
パイルコードをリンクすることによってＣ＋＋の実行可
能コードを生成する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はオブジェクト指向の
コンピュータ言語、詳しくはＣ＋＋言語のコンパイルお
よびコード生成の分野に関する。

【０００２】

【従来の技術】近年、Ｃ＋＋プログラミング言語は、多
くのコンピュータプラットフォームにおいて、プログラ
マたちの間で広く受け入れられるようになった。Ｃ＋＋
がプログラマたちを惹きつけたのは、異なるクラスのオ
ブジェクト間で関数の処理を分配、割当できること、ま
た異なるオブジェクト間で明瞭かつ簡潔なコミュニケー
ションインタフェースを定義できることといったオブジ
ェクト指向の機能のためである。同時に、Ｃ＋＋言語で
は、プログラマは、データのレイアウトやコードのイン
ライン処理など、性能に関連する多くの事項をコントロ
ールすることができる。そのため一見すると、Ｃ＋＋
は、理想的な特徴の組み合わせを提供しているように見
えるかもしれない。すなわち、Ｃ＋＋はＣプログラミン
グ言語に匹敵する高い性能を実現し、同時に、プログラ
マがインプリメンテーションの詳細を隠すための抽象レ
イヤを構築できるようにしているのである。実際、Ｃ＋
＋言語は、大抵の目的において十分に機能する。ここ
で、上記のようなオブジェクト指向的な特徴を含め、Ｃ
＋＋プログラミング言語に関する詳細な情報は、Ellis
&Stroustrup, The Annotated C++ Reference Manual, A
ddison-Wesley(1990)に記載されており、本明細書にお
いては、このリファレンスの内容を全てを引用するもの
とする。

【０００３】しかしながら、Ｃ＋＋では、オブジェクト
のインタフェースが頻繁に変更される場合に問題が生じ
る。Ｃ＋＋プログラマなら誰でも知っていることだが、
クラス定義を含むヘッダファイルを修正すると、そのク
ラス定義に基づいて作成されているアプリケーションプ
ログラム（または”クライアント”）コードを全部コン
パイルしなおさなければならないという喜ばしくない現
象が発生するのである。言い換えれば、コンパイルされ
たクライアントのコード（以下、クライアントのコンパ
イルコードなどという）は、そのコードが使用する各ク
ラスの、ある特定のインプリメンテーションにおいての
み機能することができる。あるクラスのインプリメンテ
ーションが変更されれば、コンパイルコードは「使えな
くなる(break)」（つまり、互換性がなくなる）。例え
ば、Ｃ＋＋の複素数のクラスの実数要素と虚数要素の宣
言の順番を入れ替えると、そのクラスの言語レベルの意
味は変わらないが、そのクラスのほとんど全てのクライ
アントは使えなくなる。このクラスのインプリメンテー
ションについてのこのコードの感度を”脆弱性（brittl
eness）”という。コンパイルコードが脆弱な場合に
は、そのコードを頻繁に再コンパイルしなければならな
いが、それは単調で退屈でうんざりするような作業であ
る。（注：「コンパイルコード」は、通常「オブジェク
トコード」と呼ばれているものであるが、Ｃ＋＋のよう
なオブジェクト指向プログラミング言語の文脈において
は「オブジェクト」という言葉は特別異なる意味を有す
るため、本明細書においては「オブジェクトコード」と
いう言葉は使用しないものとする。） この大量な再コンパイル問題は、情報隠蔽の失敗を意味
している。効率を最優先にすると、コンパイルされたＣ
＋＋のオブジェクトのコードは、通常、オブジェクトの
インプリメンテーション情報の詳細を隠すことができ
ず、その結果、情報隠蔽、カプセル化、コード再利用と
いったオブジェクト指向プログラミングの恩恵を受ける
ことができなくなる。概して、あるクラスのオブジェク
トへの各アクセスは、、そのクラスに関する全ての情報
を含む環境のもとでコンパイルされる。全てのインプリ
メンテーション情報を入手できるということは、データ
の構造体へのアクセスについて、Ｃ言語の「構造体」の
ような、非常にタイトなコードが実現できるということ
であるが、これには重大な欠点がある。それは、クラス
が変更された場合に、まさにそのタイトなコードを再配
置しなければならなくなることである。コンパイル時に
使用される情報は、インタフェースの背後に隠すことは
できない。そして、隠される情報が少なくなると、クラ
イアントとサービスとの間により大きな相互依存関係が
できてしまう。同様に、Ｃ＋＋の他の特徴で、例えばモ
ジュラースコープやオーバロード関数は、コンパイル時
にインプリメンテーション情報を使用してタイトなコン
パイルコードを生成するが、Ｃ＋＋の"テンプレート"
は、コンパイル時にテキストを置き換えて定義される場
合を除き、意味をもたない。

【０００４】このように、実際は、昔からのＣ＋＋のコ
ンパイルコードのタイトな結合が、クラス定義に関する
コンパイルコードの”脆弱性”の原因となっている。プ
ロジェクトのコードの大部分は、オブジェクトのクラス
を定義するヘッダファイルに含まれる場合が多いが、ヘ
ッダファイルを変更すれば、必ず、（おそらく）全ての
プロジェクトバイナリが使えなくなるので、結局は大量
の再コンパイルによって修正するしかない。

【０００５】現在の多くのＣ＋＋プログラミング環境に
おいては、アプリケーションプログラムのコンパイルコ
ードの生成に、システムユーティリティ（"make"ユーテ
ィリティなど）が用いられている。通常"make"ユーティ
リティは、各ソースコードファイルのタイムスタンプ
と、そのソースコードファイルに対応する既存のコンパ
イルコードファイルのタイムスタンプとを比較して、前
回その既存のコンパイルコードが生成されたとき以降
に、そのソースコード（あるいはそのソースコードが参
照するヘッダファイル）が変更されたか否かを判断す
る。そのソースコードが最近変更されていなければ、再
コンパイルする必要がないことは明らかなので、"make"
は既存のコンパイルコードファイルを使用する。しかし
ながら、このようなタイムスタンプのみを根拠とする方
法によると、ヘッダファイルが変更された際に、たとえ
その変更が些細な変更、あるいは不適切な変更であって
も、そのヘッダファイルを直接あるいは間接的に使用し
ている全てのソースファイルが再コンパイルされること
になる。

【０００６】これまでこの問題に対しては、依存関係を
より厳密に追跡することによって余計な再コンパイルを
減らすいくつかの試みがなされた。例えば、変更された
のがヘッダファイルのコメントであって、事実上クラス
定義が変更されていない場合には、そのオブジェクトフ
ァイルの内容が現在も有効であることがわかるようにそ
のオブジェクトファイルのタイムスタンプを更新するだ
けで、再コンパイルは行わずに、クライアントオブジェ
クトファイルの内容をそのまま使用すればよい。しか
し、依存関係情報を厳密に維持することは、再コンパイ
ルするのと同じくらい大変な場合もある。さらに、依存
関係の追跡を行えば、依存関係をなくすということは、
基本的には不可能となる。例えば、新しい仮想関数がＣ
＋＋のあるクラスに追加されるとすると、そのような追
加は、そのクラス、およびそのクラスの全ての派生クラ
スの仮想関数テーブルのレイアウトを変更することにな
り、そのクラスを呼び出す全てのクライアントコードを
再コンパイルしなければならなくなる。すなわち、この
ような大量の再コンパイルを避ける唯一の方法は、依存
関係をなくして、依存関係の追跡を行わなくすることな
のである。

【０００７】これまで、コンピュータサイエンスにおい
てモジュール分割のメカニズムとして、AlgolやFortran
やLispなどの言語で使用されてきたのが、プロシージャ
コールである。一般に、プロシージャコールでは、プロ
シージャの中身は、そのプロシージャを呼び出すクライ
アントからは見えなくすることになっており、引数およ
びリターン値のみが、通常は共通のプログラムスタック
を通して、受け渡される。言い換えれば、現在のプロシ
ージャコールは、インタフェース以外の全ての情報を隠
蔽することになっている。したがって、このプロシージ
ャコールのメカニズムを２つのプログラムを連結する手
段として用いることによって、それぞれのプログラムを
別々にコンパイルすることができ、プロシージャの明ら
かに内部的な仕様に対して変更が行われる度に、呼び出
しプログラムを再コンパイルしなければならないといっ
たことがなくなる。しかしながら、これまでの知識およ
び従来の技術では、このプロシージャコールのメカニズ
ムを、Ｃ＋＋のコードにおけるオブジェクト指向オペレ
ーションのインプリメントに使用することは避けられて
きた。これは、プロシージャコールを頻繁に実行すると
実行時の性能が低下するという問題があるからである。

【０００８】カリフォルニアのMountain ViewにあるSil
icon Graphics社のDelta C++コンパイラプロダクトは、
内部クラスの依存関係をなくすことにより再コンパイル
を不要にするという１つの実現可能な方法をインプリメ
ントしたものといわれている。Delta C++プロダクト
は、クライアントコードとは別のグローバルデータ構造
体あるいはシンボルテーブルに定数の形式で記憶され
る、いくつかの内部的なクラスインプリメンテーション
情報をコード化するものと考えられる。このインプリメ
ンテーション情報は、続いて実行時に、リンカによって
クライアントコードの中に”インライン展開”される。
Delta C++プロダクトは余分な再コンパイルを不要にし
たという点で進歩を遂げたものとみなされているが、ス
キームの強さや、クライアントコードから除かれるイン
プリメンテーションの依存関係の範囲が限定されている
という点で特に、さらなる改良の余地がある。

【０００９】

【発明が解決しようとする課題】したがって、コンパイ
ルコードレベルでも情報隠蔽などオブジェクト指向の全
ての恩恵を提供し、かつ性能や効率の面で受容できるレ
ベルのコンパイルコードを生成するような、Ｃ＋＋のコ
ンパイル方法の改良方法が望まれている。

【００１０】本発明は、Ｃ＋＋ソースコードとして書か
れたアプリケーションプログラムの実行可能なコンピュ
ータのコードを生成するための改良された方法および装
置を提供するものである。従来の典型的なシステムにお
いては、アプリケーションプログラムのソースコード
は、別のヘッダファイルに含まれているそのアプリケー
ションプログラムが使用するオブジェクト指向クラス定
義が変更された場合には、アプリケーションのソースコ
ード自体が変更されていなくても、再コンパイルしなけ
ればならないのが一般的であった。これに対し、本発明
の方法および装置は、コンパイルコードレベルでオブジ
ェクト指向インタフェースをインプリメントする手続イ
ンタフェースを使用することにより、このような再コン
パイルを不要にするものである。

【００１１】

【課題を解決するための手段】本発明によれば、コンパ
イルヘッダファイルコードは、クラス定義のオブジェク
トインスタンスにアクセスする複数のアクセッサを含む
ものとして生成され、この各アクセッサが、対応するク
ラス定義のオブジェクトインスタンスにアクセスする機
能をもつプロシージャとなっている。また、コンパイル
アプリケーションプログラムコードは、オブジェクトリ
ファレンスが、それに該当するアクセッサを呼び出すプ
ロシージャに置き換えられたものとして生成される。そ
して、このコンパイルヘッダファイルコードとコンパイ
ルアプリケーションコードがリンクされ、これにより実
行可能なコンピュータのコードが生成される。

【００１２】本発明の他の特徴としては、関連付けられ
たクラスのオブジェクトインスタンスに対して所定の関
数を実行するアクセッサの構造が挙げられる。この関数
には、データ要素の読み出し、書き込み、アドレス関連
の操作；メンバ関数の呼び出し；そのクラスに関連付け
られた定数の取り出し；そして関連付けられたクラスの
オブジェクトインスタンスの使用頻度の統計値の記録な
どを行うものがある。

【００１３】

【発明の効果】本発明によれば、アプリケーションプロ
グラムとヘッダファイルのクラス定義は、インプリメン
テーションの細部においては、コンパイルコードレベル
でも互いにそれぞれ独立した関係を維持しているため、
その後にヘッダファイルのクラス定義が変更されたとし
ても、変更されたヘッダファイルを再コンパイルして得
られるオブジェクトのコードをリンクしなおすだけでよ
く、アプリケーションプログラムコードを再コンパイル
しなくても、新しい実行可能コードを生成することがで
きる。

【００１４】

【発明の実施の形態】本発明について説明するにあた
り、まず、本明細書における表記、用語その他の前提事
項について述べる。

【００１５】以下の詳細な説明は、主としてコンピュー
タメモリに記憶されるデータファイルやビットについて
行われるオペレーションのアルゴリズムに関するもので
ある。このオペレーションには、種々の処理とともに、
コンピュータのソースコードとコンパイルコードの生
成、コンパイル、変更、コンペア、リンク、そして記憶
などのオペレーションが含まれている。アルゴリズムの
説明および表記には、データプロセッシングの分野の当
業者が、同じくその分野の当業者に対し自分の仕事の内
容を最も効果的に伝えるために使用する方法を用いるも
のとする。

【００１６】アルゴリズムとは、ここでは、あるいは一
般的には、望ましい結果を導く自己矛盾のないステップ
のシーケンスと考えられている。これらのステップは物
理量の物理的な操作を要求するものである。必ずではな
いが大抵の場合において、これらの物理量は、記憶、転
送、結合、比較、その他の操作が施されることが可能
な、電気信号あるいは磁気信号の形式をとる。これは、
主として一般的な使用方法において、ビット、値、要
素、シンボル、文字、単語、数などとしてこれらの信号
を参照することが、時として便利だからである。ここで
は、上記および同様の全ての項目が適切な物理量に関連
付けられるものであり、各項目はそのような物理量に適
用される便宜上のラベルにすぎないということを心に留
めておかなければならない。

【００１７】本発明のオペレーションの実行に適した装
置の中は、汎用のデジタルコンピュータや同様のデバイ
スも含まれる。図１は、以下の処理に適した汎用デジタ
ルコンピュータシステムを示す図である。プロセッサ10
0は、標準的な商用のデジタルコンピュータのマイクロ
プロセッサ、例えばSunのSPARC、Intelのx86、あるいは
Motorollaの680x0シリーズのＣＰＵであることが望まし
い。プロセッサ100は、システムソフトウェア120を実行
するが、このシステムソフトウェア120は、ストレージ
ユニット110、例えば標準的な内蔵ハードディスクドラ
イブなどに記憶され、UNIXオペレーティングシステムの
ような標準的なオペレーティングシステムソフトウェア
を含むものである。本発明によれば、システムソフトウ
ェア120には、改良されたコード生成ソフトウェア130が
さらに追加され、このコード生成ソフトウェア130が、
プロセッサ100に対して、以下に説明するようなコード
生成処理、およびそれに関連するオペレーションの実行
を指示する。ディスプレイ出力はプロセッサ100からビ
デオモニタ140に転送される。また、ユーザが、望まし
くは標準的なパーソナルコンピュータのキーボード150
とカーソルコントロールデバイス160（例えばマウスや
トラックボールなど）を使用して、必要に応じてコマン
ドを入力すれば、そのコマンドはプロセッサ100に転送
される。

【００１８】このように、本発明は例えば図１に示され
るデジタルコンピュータシステムのようなコンピュータ
を動かして電気信号あるいは他の物理的な信号を処理
し、必要とする他の物理的な信号を生成するための方法
ステップに関するものである。この点に関して心に留め
ておくべきことは、コンピュータを動作させる方法と、
計算方法は異なるものであるということである。本明細
書において説明する発明は前者として理解されるべきも
のである。本発明はまた、これらのオペレーションを実
行する装置に関するものである。この装置は、要求され
る目的のために専用に作られた装置でもよいし、図１の
コンピュータシステムのような汎用のコンピュータであ
って、コンピュータメモリに記憶されるコード生成ソフ
トウェア130のようなコンピュータプログラムによって
選択的に動作を行う、あるいは選択的に変更される装置
であってもよい。本明細書に示されるアルゴリズム、方
法、および装置は、特定のコンピュータに限定されるも
のではない。ここに示されるプログラムは、あらゆる汎
用マシンにおいて使用することができるものである。あ
るいは、要求される方法ステップを実行するために専用
の装置を作ってもよい。なお、これらの様々なマシンに
対して一般的に要求される構造は、以下の説明により当
業者には明らかであろう。

【００１９】本発明はまた、コード生成ソフトウェア13
0のような、電気的、磁気的あるいは他の物理的な媒体
に記憶されるコンピュータプログラムのセットからな
り、図１に示されるような汎用デジタルコンピュータに
対して、ここで説明するオペレーションを実行するよう
制御を行い、命令を与えるように設計された手段に関す
る。なお、このようなコンピュータプログラムに対して
一般的に要求される構造もまた、以下の説明から明らか
であり、コンピュータサイエンス、特にコンピュータプ
ログラミング言語の設計および実装の分野の当業者であ
れば、他のあらゆるプログラミング言語および所定のア
ルゴリズムを使用することによって、このようなプログ
ラムを様々な形態で実施することができるであろう。

【００２０】次に、アクセッサの使用に関する方法論の
基本概念について説明する。本発明は、概して言えば、
コンパイルコードレベルでオブジェクト指向インタフェ
ースをインプリメントするための優れた方法として、手
続インタフェースを導入したものであるという見方がで
きる。本発明は、オブジェクト指向的な方法を使用し
て、コンパイラに対し、複数の互いに独立したソースか
らプロシージャの定義をアセンブルするための体系的手
法を提供している。基本的に、この方法とは、コード生
成ソフトウェア130を提供することであるが、このコー
ド生成ソフトウェア130には、改良されたＣ＋＋コンパ
イラおよびそれに関連するコード生成ユーティリティが
含まれている。Ｃ＋＋コンパイラが、あるソースレベル
のオペレーションのコンパイルを行うためにヘッダファ
イルからインプリメンテーション情報を通常の方法で使
用する場合には常に、替わりに、改良されたコンパイラ
が、特別なプロシージャセットの中の１つを実行時に呼
び出してそのオペレーションをインプリメントするよう
な替わりのコードを生成する。この特別なプロシージャ
は、定義された各オブジェクトクラス（あるいは他のヘ
ッダファイル構造体）ごとに、改良されたコンパイラに
よって自動的に生成されるものであるが、クラスオブジ
ェクトへのアクセスに関するタスクを実行するために使
用されるものであることから、ここではこれを”アクセ
ッサ”と称するものとする。アクセッサは、後ににさら
に説明するように、データ要素の読み出し、書き込み、
アドレス関連の操作；メンバ関数の呼び出し；そのクラ
スに関連付けられた定数の取り出し；その他の関数を含
む関数を実行するために作成されるものである。定義ク
ラスのオブジェクトを呼び出す、あるいは使用する全て
のクライアントコードについて、コード生成ソフトウェ
ア130の改良されたコンパイラは、そのような呼出し
を、対応するアクセッサルーチンに対する手続呼出しに
翻訳する。このようにする目的は、手続インタフェース
を使用してＣ＋＋クラス定義をクライアントから切り離
し、クラス定義を変更してもクライアントプログラムの
コードをコンパイルしなおさなくてもよいようにするた
めである。

【００２１】ここでさらに、アクセッサに関して便宜上
使用するいくつかの用語を定義する。アクセッサがクラ
スのカプセル化に使用されることを、ここではそのクラ
スが「アクセサライズされる」ということにする。同様
に、クラス定義を含むヘッダファイルを「アクセサライ
ジング」するという表現も用いる。ヘッダファイル用
の、コンパイルされたアクセッサ関数の集まりは、「コ
ンパイルヘッダファイル」と呼ぶ。実際には、このよう
な集まりは１つのコードファイルとして実現してもしな
くてもよいし、一度に生成されてもされなくてもよい。
また、アクセッサは、複数のヘッダファイルから生成さ
れることもある。

【００２２】本発明によるコンパイルコードおよび実行
可能コードの生成に関する好ましい方法の概要を、図２
のフローダイアグラムに示す。本実施の形態において、
図２の、ステップ280を除く各ステップは、コード生成
ソフトウェア130によって実行される（ただし図２にお
いて、長方形は実行されるステップを表し、楕円は処理
される、あるいはこれらのステップにより得られるコン
ピュータのコードを表すものとする。）。楕円200は、
望ましいクライアントアプリケーションプログラムにお
いて使用される様々なオブジェクトクラスについての、
ユーザ定義のＣ＋＋ソースコード定義を表している。通
常、これらのクラス定義は、１つあるいはそれ以上の
「ヘッダファイル」に記憶され、そのヘッダファイル
が、その定義クラスのオブジェクトを使用するクライア
ントプログラムにおいて参照によってインクルードされ
る。ステップ210では、各ヘッダファイルがコンパイル
される。このステップの一部として、コンパイラによっ
て、アクセサライズされた各ヘッダファイルの中のクラ
ス定義ごとに、コンパイルコードアクセッサが生成され
る。アクセッサは、外部プロシージャの形式で、クライ
アントプログラムがそのオブジェクトに対して行う可能
性がある全ての形式のアクセスをインプリメントする簡
単なルーチンであることが望ましい。また、アクセッサ
は、インタプリティブであってもかまわない。すなわ
ち、アクセッサは、コンパイラにより生成されたテーブ
ルから適切なアクションを選択することによって動作す
るものであってもよい。アクセッサの望ましい仕様につ
いては後述する。いずれの場合も、ステップ210でコン
パイルした結果コンパイルコード220が生成されるが、
これはステップ200で定義されたクラス定義のアクセサ
ライズされたバージョンを表している。なお、コンパイ
ルコード220はレポジトリ（すなわちデータベース）に
記憶されることが望ましい。

【００２３】また、クライアントコンパイルコードも生
成される。これはヘッダファイルの処理とは別個に行わ
れてもよいが、通常は"make"のようなコード生成ユーテ
ィリティが使用されてクライアントソースコードの初期
化処理を行い、続いてステップ210のような、参照され
るヘッダファイルの処理を行われるようにする。いずれ
の場合も、ステップ230において、クライアントソース
コードがユーザによって定義される。ステップ240で
は、そのクライアントコードがコンパイルされるが、こ
れは少なくともステップ242と244の２つのステップで構
成される。ステップ242では、本発明のコンパイラは、
クライアントソースコードの中の、アクセサライズされ
たクラスに属するオブジェクトをアクセスまたは参照す
る全てのコードステートメントを割り出す。ステップ24
4では、このコンパイラは、そのようにして割り出され
たコードステートメントを、適切なアクセッサへの（コ
ンパイルコード形式の）プロシージャコールに置き換え
る。図３は、この置き換えの技術を詳細に示したもので
ある。クライアントコード300は、あるオブジェクトへ
のアクセス要求を含むＣ＋＋ソースコードの一部分であ
る；この例では、このクライアントコードはこのオブジ
ェクトの"count"フィールドを取り出そうとしている。
この図に示されるように、従来のＣ＋＋コンパイラ310
は、通常、部分コード300を部分コンパイルコード320の
ようなものに翻訳する。これは（当業者には明らかであ
るように）、コンパイルコードに、例えばそのクラスの
オブジェクトの中での"count"フィールドの内部的な配
置などの、オブジェクトのクラス構造に関するインプリ
メンテーション定義情報を組み込んだものである。これ
に対し、本発明のコンパイラ330は、部分コード300を部
分コンパイルコード340のようなものに翻訳する。これ
は外部プロシージャ−「アクセッサ」−を呼び出すもの
であり、このアクセッサの引数が、内部的なインプリメ
ンテーション定義情報にかわる標準化された呼出シーケ
ンス形式のインタフェース情報を含んでいる。

【００２４】コンパイルのステップ240の出力はクライ
アントコンパイルコード250となる。ステップ260では、
クライアントコンパイルコード250とクラス定義コンパ
イルコード220がリンクされて、実行可能コード270が生
成される。ステップ280は、図１の装置のような汎用の
デジタルコンピュータシステムにおける実行可能コード
270の実行を示す。

【００２５】ヘッダファイルのアクセサライジングの目
的および結果は、オブジェクトファイルをより強くする
ことである。アクセサライズされたヘッダファイルが変
更された場合には、前のコンパイルオブジェクトファイ
ルの内容は場合によっては再利用できる。ここで、ステ
ップ290に示されるように、ユーザが、前にステップ200
で定義したクラス定義を変更しようとしたとする。この
場合、ユーザはヘッダファイルのソースコードをステッ
プ295において好きなように編集する。変更されたヘッ
ダファイルは次にステップ210において再コンパイルさ
れ、そのコンパイルされたコードはステップ260におい
て、クライアントコンパイルコードと再度リンクされ、
最新の実行可能コードが生成される。ここで注目すべき
ことは、この処理の繰り返しにおいて、クライアントコ
ードの生成に関連するステップ（すなわち、ステップ23
0,240,242,244および250）は、いずれも繰り返される必
要がないということであり、したがって、従来技術より
も遙かに時間を節約できるということである。

【００２６】次に、アクセッサのインタフェース仕様に
ついて説明する。

【００２７】本発明によれば、アクセッサはクライアン
トプログラムに対してクラスオブジェクトのインタフェ
ースを提供するものであり、クラスに関する、クライア
ントコードからは見えない内部的なインプリメンテーシ
ョン情報を保持するものである。一般的には、できる限
り多くのインプリメンテーション情報をクライアントか
ら見えないようにし、これにより、クライアントコード
とヘッダファイルの依存関係を取り除くことが望まし
い。

【００２８】本発明の望ましい実施の形態において、あ
るクラスに対するアクセッサのインタフェースは、その
クラスとそのクラスの要素（すなわち、メンバデータと
メンバ関数）のシンボリックな名称を含んでおり、同様
に、アクセッサの各クラス要素へのリターン値の型も含
んでいる。アクセッサインタフェースは例えばオブジェ
クトのサイズや配置；与えられたメンバがローカルなも
のか継承されたものか；関数がinline、static、virtua
lおよび／または純粋な関数か；インラインの実体が定
数か；基本クラスが実および／または仮想か；与えられ
た名称の要素が存在するかといったインプリメンテーシ
ョン情報を含む必要はない。したがって、概して言え
ば、ヘッダファイルのソースコードを変更したことによ
って、クライアントプログラムソースコードを再コンパ
イルしなければならなくなるのは、その変更が、クライ
アントから参照されるアクセサライズされたクラスメン
バの名称または型を変更するものである場合に限られ
る。これが、望ましい結果であることはいうまでもな
い。特定のクラス要素を使用するクライアントコード
は、そのときのクラス定義においてそのクラス要素の型
あるいはシンボリック名称が変更された場合には、一般
的に、書き直され、再コンパイルされなければならな
い。

【００２９】コンパイルオブジェクトファイルの有効性
を維持するためには、クライアントプログラムが使用す
るアクセサライズされたクラス要素の名称または型が変
更された際にクライアントソースコードが再コンパイル
されたことを確認するだけでよい。アクセッサの名称お
よび型のそのような変更の検出には、コード生成ソフト
ウェア130によりアクセッサに対して"タイプセーフリン
ケージ"というよく知られた技術が適用される。特に、
コード生成ソフトウェア130は、アクセッサの名称、引
数、リターン値の型を組み込むように各アクセッサ名称
のローレベルのコード化（あるいは「マングリング（ma
ngling）」）を実行するコンパイラを含むことが望まし
い。これにより、ヘッダファイルとクライアントプログ
ラムの間で、アクセサライズされたヘッダファイルの名
称および型の変更に起因するコンパイルオブジェクトフ
ァイルの不整合が生じても、これらのコンパイルオブジ
ェクトファイルに関連付けられるシンボルテーブルの比
較によって容易に検出することができる。これについて
は後述する。

【００３０】当面の用途では、ヘッダファイルの要素の
名称は、それが適用するＣの識別子（あるいは演算子ト
ークンや変換の型）のみならず、それが現れるスコープ
をも含む。スコープは、封じ込めるオブジェクトの型に
よって（メンバ指定"x.m"のような構成の場合）、ある
いは明示的なプレフィックス（"C::x"のような）によっ
て決定される。スコープは継承によって関連づけられる
ため、あるメンバは、そのメンバを継承している派生ク
ラスに対応する全てのスコープにおいてアクセスされ得
ることになる。したがって、１つのメンバに対しては、
そのメンバが使用され得るスコープの数と同じ数分の別
個の名称を与えるものとする。メンバの名称を、そのメ
ンバが定義されるスコープによってのみ決めることは、
望ましくない。なぜなら、プログラムが組み直されてク
ラスメンバがクラス間で移動される度に、あるいは再定
義による追加や削除が行われた場合に、クライアントオ
ブジェクトファイルが使えなくなるからである。また、
もとのスコープのみに依存した名付け方をすると、プロ
グラミング環境が、スコープ間の相互関係を追跡しなけ
ればならなくなる。さらに、ヘッダファイル要素をアク
セスするために使用する名称も、その要素を使用する特
定のソースイディオムに依存することになる。例えば、
演算子のオーバーローディングのおかしなルールのため
に、下記の３つの表記は微妙に異なる意味を持ってお
り、それぞれの意味を独立して追跡するためには、それ
ぞれ別の名称が与えられなければならない： x << y x.operator<<(y) operator<<(x,y) 同様に、派生クラスのポインタから基本クラスのポイン
タへの暗黙的な変換は、異なるイディオムによって呼び
出すことができるが、そのそれぞれの持つ意味は別々に
変更することができ、したがって異なる名称をつけるこ
とができる： x? derived_ptr: base_ptr // common base Base* base_ptr = derived_ptr; // initialization (Base*) derived_ptr // cast この実施の形態の説明の末尾に示される表１および表２
は、単純なＣ＋＋ソースコードクラス定義と、本発明の
望ましい実施の形態による、そのクラス定義に対応する
アクセサライズされたバージョンの一例のリストを示す
ものである。これらのリストでは、アクセサライズされ
たコードは、理解を容易にするためにＣ言語の形式で書
かれているが、実際には上述の図２に示されるように、
コンパイルコードが生成される。

【００３１】次にアクセッサの具体例を、以下に示す。

【００３２】変更された宣言シンタックスを使用してい
る特定のアクセッサには、概して、コンパイラが診断結
果をレポートするときに使用する名称と同じ名称を与え
ることが望ましい。名称は全て限定され、引数の型もリ
ストされ、さらに必要に応じてリターン値の型も挙げら
れる。また、各アクセッサは、そのアクセッサを使用す
るソースの構成のシンタックスから生じる"種類(kind)"
によって特徴づけられる。この種類は、我々の表記にお
いては、名称の後にスラッシュと種類をつけることによ
って表される。この表記は他のＣ＋＋のパーサーでは受
け入れられないし、また受け入れられる必要もない。ア
クセッサ名称についてのマングリングは種類をコード化
するプレフィックスから始められるか、さもなくばその
ようなシンボルにおける通常のマングリングと同じよう
に行われる。アクセッサのリターン値の型は、関数ポイ
ンタのリターン値の型のようにコード化される。

【００３３】一般的には、アクセッサは、クライアント
コードによって参照されるクラスがソース互換である限
りクライアントコードを再コンパイルしなくてもよいよ
うに、指定された種類のオブジェクトへの指定された形
式のアクセスに使用されることが望ましい。以下に一例
を示す： グローバルデータオブジェクトの、アドレスを取り出すためのアクセッサ： T v; T& v/address() グローバル変数の型が変更されてしまうとオブジェクト
ファイルがリンクに失敗してしまうためにこのアクセッ
サが必要となる；これは通常はオブジェクトファイルの
プロパティではない。なぜなら変数名はそれらの型を含
まないからである。

【００３４】 グローバル定数のreadアクセッサ： const T v; enum T {v}; T v/read() データメンバ用の、read,write,addressアクセッサ： T C::m; T C::m/read() C::m/write(T) T& C::m/address() T m/read() const const T& m/address() const staticなデータメンバ用の、addressアクセッサもある： static T& C::m/address() staticなデータメンバは、ソースコード内でベースオブ
ジェクトとともに使用されている場合に、readおよびwr
iteアクセッサによってアクセスされる。これにより、
クライアントの"x.m"のような表記は、一旦コンパイル
されると、そのメンバのステータスがstaticに変更され
てもstatic以外に変更されても有効なままとなる。

【００３５】関数は（メンバ関数でもグローバル関数で
も）callアクセッサを持つ。メンバ関数はまた、"scope
d"callアクセッサも持ち、演算子はさらに"operator"ca
llアクセッサをもつ。以下にその例を示す： T C::F(A a, B b); T C::f/call(A a, B b) // c.f(a,b) T C::f/scoped(A a, B b) // c.C::f(a,b) T operator+(A a, B b); T operator+/call(A a, B b) //operator+(a,b) T operator+/operator(A a, B b) // a+b 望ましい実施の形態では、オーバローディングの解決
を、解決前の実際の引数の型を表す型のcallアクセッサ
を手段として用いることにより行う（注：この決定は、
定義のスコープではなくリファレンスのスコープを表す
名称のアクセッサを使用してスコープの解決を行うこと
と似ている）。

【００３６】好ましい実施の形態によれば、マネージア
ロケーション、コンストラクション、デストラクショ
ン、オブジェクトのレイアウト；仮想テーブルのレイア
ウト；型変換などを補助する、他の種類のアクセッサが
定義される。望ましくは、定数データメンバには、writ
eアクセッサはなく、"self const"バージョンも、read
アクセッサとaddressアクセッサにはあるがwriteアクセ
ッサにはない。参照データメンバは、そのリファレンス
が定数以外であって、かつ自身が定数か否かに無関係で
ある場合には、writeアクセッサを持つ。ビットフィー
ルドはadressアクセッサを持たない。配列はaddressア
クセッサしかもたない。

【００３７】次にアクセッサの選択的な使用について説
明する。

【００３８】クラスのアクセサライジングはクラスの形
式を変更しない。したがって、各クライアントオブジェ
クトファイルは、与えられたヘッダファイルをアクセサ
ライズするか否かに関して異なる決定をすることができ
る。これは、クラスのアクセサライジングは、ソースコ
ードファイルのＣ＋＋の構成要素の実際のインプリメン
テーションについては何の変更も加えないからであり、
原理的には作業をする者は、使用中の各特定のヘッダフ
ァイルの構成要素をアクセサライズするかしないかを別
個に決定することができる。しかし、望ましくは、ヘッ
ダファイル単位でアクセサライズするか否かを決定する
のがよい。なぜなら、与えられたヘッダファイルの中に
１つでもアクセサライズされないものがあると、実際に
は、そのヘッダファイルに依存する全てのクライアント
コードがタイムスタンプによる判定のために再コンパイ
ルされてしまうからである。

【００３９】Ｃ＋＋の構成要素の中には、アクセサライ
ズされない方がよいものもある。例えばＣ＋＋コードの
ある表記はコンパイル時に評価され、その結果は通常と
は異なる方法で使用される。例えば、switchでは、"cas
e"ラベルは定数表記でなければならない。配列境界、ビ
ットフィールドの幅、そしてテンプレートの真の引数も
また定数でなければならない。このようなコンテキスト
については、本発明によるコンパイラは、アクセサライ
ズされた定数を見つけた場合にその名称を逆アクセサラ
イズし、ユーザにこれを知らせる診断をプリントするこ
とが望ましい。続いて、その名称の値の変更が、その名
称を逆アクセサライズしたオブジェクトファイルの再コ
ンパイルを引き起こす。名称の値は、アクセッサの名称
と同様の方法で、その環境によって追跡される；それは
その名称、型、値を記録するマングルされたシンボルに
よってコード化される。コンパイル時の定数をもつread
アクセッサも、この方法で取り扱うことができる；アク
セッサのサイズを決めることもでき、これが"sizeof"の
値となる。"offsetof"マクロは構造体のレイアウトを問
い合わせるものであるが、特にアクセサライズはされな
い。"offsetof"の使用、あるいはそれに相当するコンパ
イル時の定数表記は、全てのクラス定義において粗い依
存性を生じさせる。同様のことは、ユーザがＣのスタイ
ルで、アクセサライズされた構造体の静的な初期化のコ
ードを作成した場合にも起きる。

【００４０】コンパイルの負荷を低減して性能を最適化
するためには、クラスのprivateメンバはアクセサライ
ズされないことが望ましい。その替わりに、クラスの全
てのメンバ関数はそのクラスに対し、直接、アクセサラ
イズでないアクセスを行う。メンバ関数を含むオブジェ
クトファイルは、関連するクラス定義に対して”粗い依
存関係”を持つ。定義に対する”粗い依存関係”がある
場合には、永続性を維持するためにその定義の全体構造
が必要となる。マクロとtypedefとテンプレートも、定
義に対して同様の粗い依存関係を持つ。そのような名称
を使うクライアントプログラムは、例えばそのような定
義のトークンを１つでも変えてしまうとそれらのクライ
アントを再コンパイルしなければならないというよう
に、定義に依存している。このコンパイル時の定数の依
存関係は、マングルされたシンボル内の定義の構造体
を、シグニチャ関数を使用してサイズ境界を維持してコ
ード化することにより対処することができる。また、従
来のタイムスタンプを使用して、含まれているヘッダフ
ァイルのチェックを行うこともできる。

【００４１】大まかには、ソースファイルがコンパイル
される際に、コンパイル環境における依存関係は、以下
の３つの方法のうちの１つによってそれぞれ記録され
る。

【００４２】１． アクセサライズされていないヘッダ
ファイルについては、そのことが記録される。

【００４３】２． 定数、クラス、マクロ、typedef、
およびテンプレートの特定の定義における依存関係が記
録される。

【００４４】３． クラス要素の名称と型に関する仮定
を与えるアクセッサコールが生成される。

【００４５】第１の依存関係は、今日の多くのプログラ
ミング環境のような、タイムスタンプベースである。他
の２つはマングルされたシンボルによって仲介されるも
のである。最後の依存関係が最も一般的で、ほとんどの
情報を隠蔽するものである。

【００４６】次に、正確かつ高速な再コンパイルについ
て説明する。

【００４７】クライアントプログラムが最初にコンパイ
ルされたときには、アクセサライズされたヘッダファイ
ルは、必要に応じてコンパイルされ、テンプレートと同
じシステムレポジトリに記憶される。図２について上述
したように、クライアントプログラムがリンクされる
と、コンパイルヘッダファイルがリンクラインに追加さ
れ、アクセッサに対してコンパイルコードを供給する。
ここで、プログラマがヘッダファイルを変更して、その
アプリケーションプログラムの最新のコンパイルコード
を生成しなおすよう要求したとする。本発明の好ましい
実施の形態によれば、クライアントを再コンパイルする
必要があるか否かは、タイムスタンプ、シンボルの使
用、および定義をシステマティックに調べることよって
わかる。図４に示すフローダイアグラムは、この選択的
な再コンパイルのプロセスについて説明する図である。

【００４８】ステップ400では、コンパイルコード生成
プロセスがクライアントプログラム用に初期化される。
望ましい実施の形態においては、このステップは、コー
ド生成ソフトウェア130の一部として提供される、改良
された"make"ユーティリティを呼び出すことにより実行
される。この改良された"make"ユーティリティは、ある
意味では、同名の有名なタイムスタンプ駆動のユーティ
リティに似ているが、本発明の目的のため、"make"は図
４に示される選択的な再コンパイルと組み合わせられる
ように改良されている。

【００４９】ステップ405では、クライアントプログラ
ムにおいて参照によってインクルードされている各ヘッ
ダファイルのコンパイルコードが更新される。このステ
ップの実行には、従来のタイムスタンプ駆動の再帰的ア
プローチを使用することができる。一般に、クライアン
トプログラムから直接参照されるヘッダファイルのソー
スコードが、それに対応するコンパイルヘッダファイル
よりも新しければ、そのヘッダファイルは再コンパイル
され、これにより更新されたアクセッサが生成される。
しかしながら、まず、このヘッダファイルがさらに他の
ヘッダファイルを参照によりインクルードしていたとす
ると、日付駆動の更新プロセスは、これらの各ヘッダフ
ァイルなどに対し、再帰的な方法で適用されることにな
る。望ましい実施の形態においては、ヘッダファイルが
処理されるシーケンスは、"make"がそうであるように、
ソースファイルのコンパイルの順番によって決まる。特
に、アクセッサは、そのアクセッサにソース情報を提供
する全てのヘッダファイルを参照しているソースファイ
ルが読み込まれると、すぐにコンパイルされる。

【００５０】判定ポイント410で、クライアントソース
ファイルが既存のオブジェクトファイルよりも新しい
と、ステップ420で、クライアントソースが再コンパイ
ルされる。判定ポイント410の判定が逆であって、判定
ポイント430でクライアントプログラムが１つあるいは
それ以上のアクセサライズされてないヘッダファイルを
参照することが決定された場合には、そのクライアント
プログラムは、従来のタイムスタンプ駆動の方式で扱わ
れることになる。言い換えれば、クライアントプログラ
ムが使用するアクセサライズされてないヘッダファイル
が、何らかの理由により既存のクライアントコンパイル
コードより新しい日付でタイムスタンプされると（判定
ポイント440）、そのクライアントは再コンパイルされ
る。アクセサライズされたヘッダファイルを使用するク
ライアントプログラムの場合には、判定ポイント450に
おいてクライアントのオブジェクトファイルのシンボル
テーブルが各コンパイルヘッダファイルのシンボルテー
ブルと比較される。この比較は先に述べた「タイプセー
フ」のマングリング技術によるものである。ここで不一
致が発生（つまり、クライアントがもう定義されてない
アクセッサ、あるいは値の依存関係がずれてるアクセッ
サを使用）すると、ソースファイルは再コンパイルされ
る。一致した場合には、既存のクライアントオブジェク
トファイルは再利用することができ、コード生成ソフト
ウェア130はコンパイルコードファイルのタイムスタン
プを460で単に「押し（bump）」て、更新されたという
印をつける。その結果、"make"ユーティリティ（あるい
は他の同様なタイムスタンプ駆動のツール）はオブジェ
クトファイルを、ゼロから完全に生成しなおされたもの
とみなすことになる。しかし、実際は、図４のプロセス
の方が、完全な再生成よりも、一般的には高速である。
なぜなら、タイムスタンプを押すという技術によって、
効果的に"make"をごまかし、新しいバージョンのオブジ
ェクトファイルが生成されたと信じ込ませているからで
ある。この技術は"make believe"再コンパイルと呼ばれ
ることがある。

【００５１】実際、コンパイルコードの再利用を考慮し
た多くの操作方法は、ヘッダファイルを調べ、有効化す
る処理を含み、それらの処理は、複数のソースファイル
からインクルードされている各ヘッダファイルに対して
それぞれ実行される。したがって、本発明の望ましい実
施の形態では、１つのシステムがビルドされる間、仮想
メモリの適当なテーブルにこのような処理の結果をキャ
ッシュする小さなコンパイラサーバを使用している。こ
れにより、もとの"make believe"コンパイルが、タイム
スタンプを有効にし、アクセッサを再生成するのに相当
の時間を費やしていたのに対し、新しいmake believeコ
ンパイルは、サーバとコネクションを張り、データベー
スに既にキャッシュされている情報を問い合わせればよ
い。このサーバは、アプリケーションがリンクされる
と、テンプレートのレポジトリを更新し、exitするよう
にプログラムされている；つまり、"make"の１回の実行
用である。

【００５２】次にアクセッサのオーバヘッドを最小化す
る方法について説明する。

【００５３】上述のアクセッサの方法論は、実際には、
かなり多くのアクセッサを生成することになる傾向があ
る。例えば、１０個の要素をもつenumeration型は、も
し基本クラスにおいて４つの直接あるいは間接の派生ク
ラスにネストされているとすると、(10)(1+4)(1+1) =10
0のアクセッサ名称を必要とする。最後の項は、enumera
tionはスコーピングによって、あるいは選択的な表示に
よってアクセスされうるということ、そして２つの表記
は微妙に異なる意味をもつということを表している。実
際、コンパイルヘッダファイルのシンボルテーブルがコ
ンパイルコードよりも大きくなることはめずらしくな
い。処理されるシンボルの大きさは、リンク時の処理速
度の低下につながりかねない。アクセサライズするアプ
リケーションのサイズもまた、コンパイルコードよりも
著しく大きい。もともと大きいアプリケーションの場合
には、この特別なオブジェクトファイルと依存関係操作
情報を合わせると、必要なディスク容量が数メガバイト
増えてしまうことになる。このアクセッサの望ましくな
いオーバヘッドの対策方法の１つは、最終的な、製品バ
ージョンのアプリケーションを作成する際に、アクセッ
サをしようせずに、従来のＣ＋＋コンパイルプロセスを
使用して全てのアプリケーションを再コンパイルするこ
とである。この方法でも、アクセッサの恩恵は少なくと
も初期の開発プロセスにおいて、クラス定義を修正、更
新するときに受けられる。

【００５４】本発明による他の方法は、コードジェネレ
ーションソフトウェア130を、参照されるオブジェクト
への非手続的なインラインアクセスと同様に、アクセッ
サへの手続呼出しを含むコンパイルアプリケーションプ
ログラムコードを生成するように変更することであ
る。"footnote"あるいは特別なコードが、コード生成ソ
フトウェア130のリンカに対して、２つの系統−アクセ
サライズかインラインか−のうちの１つを選択しなけれ
ばならないことを警告する。リンカは、該当するヘッダ
ファイルが変更されていないことをタイムスタンプが示
していれば、インラインバージョンを選択することが望
ましい。この方法では、クライアントアプリケーション
コードを全部再コンパイルする必要があるとき以外は、
アクセッサに関連して増加される処理はない。より積極
的には、ソフトウェア130のリンカをさらに改良し、ヘ
ッダファイルクラス定義に加えられた変更が小さな変更
である場合に、リンカが動的にfootnoteとして記録され
ているインラインコードを変更して使用するようにする
こともできる。例えば、シンボルテーブルを使うことに
より、リンカが、与えられたクラスのオブジェクトの中
の特定のフィールドのオフセットを簡単に計算し直し、
インラインコードに含まれるオフセット値を更新すると
ともにフィールドを正しくアドレス付けできることが望
ましい。

【００５５】当業者であれば気づくであろうが、ここに
説明される方法は場合によってアクセッサの性能オーバ
ヘッドを低減するものであるが、逆にリンカの性能に幾
分かのオーバヘッドを追加するものである。この性能の
見返りのため、実行性能対コード生成性能のバランス
は、作業する者が、上述のようなオーバヘッドの最小化
方法の追求をするかしないか、あるいはどのようにして
するかを決定する際に、直面している特定のコンテキス
トと照らし合わせて考慮しなければならない。

【００５６】次に、情報収集と情報操作のためのアクセ
ッサの使用について説明する。

【００５７】本発明の好ましい実施の形態においては、
アクセッサを、オブジェクトアクセスに関する内部操作
関数を実行する"フック（hooks）"として有効利用する
ことができる。これらの関数は、オブジェクトの詳細な
存続時間の操作、普遍性の照合や整合性のチェック、そ
して使用状況の統計や他の実行時の情報の収集を含むも
のである。例えば、表３に含まれるコードの引用は、関
連するオブジェクトフィールドに負の値がセットされる
たびにカウンタをインクリメントするアクセッサが示さ
れている。この類の使用頻度の統計値の収集は、プログ
ラム設計者がクラスフィールドにとって最適なデータの
型を決定する際の助けとなるものである。あるいは、プ
ログラミング設計における選択を行うための有意義な情
報として、この分野に関して通常レベルの技術を有する
人たちにとっても役立つものである。

【００５８】 表１：Ｃ＋＋クラス定義のサンプル class C { public: void reset(int new_count = 0) { count = new_count; } virtual int bump( int diff = 1) { return count += diff; } int count; }; 表２：サンプルＣ＋＋クラスのアクセサライズされたバージョン __0AaoBCszvT_Ui: ! static unsigned int C::/size() jmp %o7+8 mov 8,%o0 __0AcoBCdtv: ! C::〜C/call(void) jmp %o7+8 nop ... __0AcoBCctv: ! C::C/call(void) save %sp,-96,%sp set __0dBCG__vtbl,%l0 ! C::__vtbl st %l0,[%i0+0] jmp %i7+8 restore ... __0AcoBCasRC6BC_R6BC: ! C& C::operator=/call(const C&) save %sp,-96,%sp ld [%i1+4],%l0 st %l0,[%i0+4] jmp %i7+8 restore __0AcoBCasR6BC_R6BC = __0AcoBCasRC6BC_R6BC ! C& C::operator =/call(C&) __0AsoBCasRC6BC_R6BC = __0AcoBCasRC6BC_R6BC ! C& C::operator =/scoped(co nst C&) __0AsoBCasR6BC_R6BC = __0AcoBCasRC6BC_R6BC ! C& C::operator =/scoped(C& ) __0AvfBCFcountv_i: jmp %o7+8 ld [%o0+4],%o0 __0AvfBCFcountvK_i = __0AvfBCFcountv_i ! int C::count/read(void) const __0AafBCFcountv_Ri: ! int& C::count/address() jmp %o7+8 add %o0,4,%o0 __0AafBCFcountvK_RCi = __0AafBCFcountv_Ri ! const int& C::count/address (void) const __0AvfBCFcounti_v: ! C::count/write(int) jmp %o7+8 st %o1,[%o0+4] __0AcfBCFresetv_v: ! void C::reset/call(void) jmp %o7+8 st %g1,[%o0+4] __0AsfBCFresetv_v = __0AcfBCFresetv_v ! void C::reset/scoped(void) __0AcfBCFreseti_v: ! void C::reset/call(int) jmp %o7+8 st %o1,[%o0+4] __0AsfBCFreseti_v = __0AcfBCFreseti_v ! void C::reset/scoped(void) __0AcfBCEbumpv_i: ! int C::bump/call(int) save %sp,-96,%sp ... restore __0AcfBCEbumpi_i: ! int C::bump/call(void) save %sp,-96,%sp ... ! do virtual calling sequence restore __0AsfBCEbumpv_i: ! int C::bump/scoped() save %sp,-104,%sp ... ! do virtual calling sequence restore __0AsfBCEbumpi_i: ! int C::bump/scoped() save %sp,-112,%sp ... ! code for actual function body restore 表３：使用頻度の統計値を収集するアクセッサ void __0AvfBCFcounti_v(C* c,int v) /* void C**count/write(int) */ { assert(v >= 0); /* check invariant */ c->count = v; hist_collect("C::v", v); /* accumulate usage info */ } 以上、本発明をインプリメントするための考え得る技術
を、好ましい実施の形態に基づいて説明したが、これは
本発明の範囲を限定するものとしてではなく、当業者の
理解の助けとなるものとして示したものである。開示し
た望ましい技術の観点から、当業者が本発明の思想に基
づく多くの変更あるいは修正を行うことができることは
いうまでもない。そのような変更と、以下の請求項に示
される他の全てのシステム形態は、全て本発明の範囲に
含まれるものとする。

【図面の簡単な説明】

【図１】本発明を実施するために使用するための好まし
いデジタルコンピュータ装置を示す図

【図２】本発明によるＣ＋＋プログラムコードのコンパ
イルおよび更新の基本的概念を表すフローダイアグラム

【図３】本発明による好ましいアプローチと従来技術の
アプローチを対比するために、クライアントソースコー
ドとそれに対応するコンパイルコードの一例を示す図

【図４】本発明によるコンパイルコードを更新するため
の好ましいプロセスを表すフローダイアグラム

【符号の説明】

100 ＣＰＵ 110 記憶媒体 120 ＯＳ 130 コード生成ソフトウェア 140 モニタ 150 キーボード 160 マウス

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ウェイン シー グランリッチ アメリカ合衆国 カリフォルニア州 94086 サニーベイル ヘンリエッタ ア ベニュー 726

Claims (25)

【特許請求の範囲】
1. 【請求項１】 デジタルコンピュータを使用してアプリ
   ケーションプログラムの実行可能なコンピュータコード
   を生成する方法であって、前記アプリケーションプログ
   ラムが１つ以上のヘッダファイルに対する少なくとも１
   つの参照を含み、前記各ヘッダファイルが１つ以上のク
   ラス定義を含み、前記各クラス定義がオブジェクトイン
   スタンスのクラスを定義し、前記アプリケーションプロ
   グラムが複数のＣ＋＋ソースコード命令を含み、該ソー
   スコード命令が前記クラス定義の１つ以上のオブジェク
   トインスタンスに対する１つ以上の参照を含むような方
   法において：ヘッダファイルをコンパイルして、１つ以
   上のアクセッサを含むコンパイルヘッダファイルコード
   を生成するステップであって、前記各アクセッサが前記
   クラス定義のうち関連する１つのクラス定義のオブジェ
   クトインスタンスへのアクセスを実施するプロシージャ
   であるようなステップと；アプリケーションプログラム
   をコンパイルして、複数のＣ＋＋ソースコード命令に対
   応するコンパイルアプリケーションコードを生成するス
   テップであって、前記コンパイルアプリケーションコー
   ドが１つ以上のアクセッサに対する１つ以上のプロシー
   ジャコールを含み、該各プロシージャコールが、前記ソ
   ースコード命令中の、前記クラス定義の１つ以上のオブ
   ジェクトインスタンスに対する１つ以上の参照に対応す
   るようなステップと；前記コンパイルヘッダファイルコ
   ードと、前記コンパイルアプリケーションコードをリン
   クすることによって実行可能なコンピュータコードを生
   成するステップを含むことを特徴とする実行可能コード
   の生成方法。
2. 【請求項２】 １つ以上のヘッダファイルクラス定義を
   変更し；続いて、請求項１に記載されるステップのう
   ち、アプリケーションプログラムをコンパイルするステ
   ップを除く他のステップを繰り返し、これにより前記変
   更されたヘッダファイルクラス定義に関する変更された
   実行可能なコンピュータコードを生成する請求項１記載
   の実行可能コードの生成方法。
3. 【請求項３】 コンパイルアプリケーションプログラム
   コードがファイルに記憶され、該ファイルが該ファイル
   の最新の変更を表すタイムスタンプを有し、請求項１に
   記載されるステップの前記繰り返しのステップが、前記
   アプリケーションプログラムコードファイルに対して他
   の変更は加えずに、前記タイムスタンプをインクリメン
   トするステップをさらに含むことを特徴とする請求項２
   記載の実行可能コード生成方法。
4. 【請求項４】 前記クラス定義がシンボリック名称とデ
   ータの型の集まりを含み、前記アクセッサに対する前記
   各プロシージャコールが、該アクセッサに関連するクラ
   ス定義の１つ以上の前記シンボリック名称およびデータ
   の型を指定することを特徴とする請求項１記載の実行可
   能コードの生成方法。
5. 【請求項５】 前記アクセッサが、関連付けられたクラ
   ス定義のオブジェクトインスタンスの読み出し、書き込
   み、およびアドレス関連の操作を行う１つ以上のアクセ
   ッサを含むことを特徴とする請求項１記載の実行可能コ
   ードの生成方法。
6. 【請求項６】 前記アクセッサが、関連付けられたクラ
   ス定義のオブジェクトインスタンスのメンバ関数を呼び
   出す１つ以上のアクセッサを含むことを特徴とする請求
   項１記載の実行可能コードの生成方法。
7. 【請求項７】 前記アクセッサが、関連付けられたクラ
   ス定義のオブジェクトインスタンスの型変換を実行する
   １つ以上のアクセッサを含むことを特徴とする請求項１
   記載の実行可能コードの生成方法。
8. 【請求項８】 前記アクセッサが、関連付けられたクラ
   ス定義のオブジェクトインスタンスから１つ以上の定数
   値を取り出す１つ以上のアクセッサを含むことを特徴と
   する請求項１記載の実行可能コードの生成方法。
9. 【請求項９】 前記アクセッサが、関連付けられたクラ
   ス定義のオブジェクトインスタンスから１つ以上のサイ
   ズを取り出す１つ以上のアクセッサを含むことを特徴と
   する請求項１記載の実行可能コードの生成方法。
10. 【請求項１０】 前記アクセッサが、関連付けられたク
    ラス定義のオブジェクトインスタンスに関する使用頻度
    の統計値を記録する１つ以上のアクセッサを含むことを
    特徴とする請求項１記載の実行可能コードの生成方法。
11. 【請求項１１】 前記アクセッサが、関連付けられたク
    ラス定義のオブジェクトインスタンスに関して不変性の
    確認を行う１つ以上のアクセッサを含むことを特徴とす
    る請求項１記載の実行可能コードの生成方法。
12. 【請求項１２】 アプリケーションプログラムの実行可
    能なコンピュータのコードを生成する装置であって、前
    記アプリケーションプログラムが１つ以上のヘッダファ
    イルに対する少なくとも１つの参照を含み、前記各ヘッ
    ダファイルが１つ以上のクラス定義を含み、前記各クラ
    ス定義がオブジェクトインスタンスのクラスを定義し、
    前記アプリケーションプログラムが複数のＣ＋＋ソース
    コード命令を含み、該ソースコード命令が前記クラス定
    義の１つ以上のオブジェクトインスタンスに対する１つ
    以上の参照を含むような装置において、該装置が：コン
    パイルヘッダファイルコードの生成を実施するコンパイ
    ラであって、該コンパイルヘッダファイルコードが１つ
    以上のアクセッサを含み、該各アクセッサが前記クラス
    定義のうち関連する１つのクラス定義のオブジェクトイ
    ンスタンスへのアクセスを実施するプロシージャであ
    り、さらに前記コンパイラが、複数のＣ＋＋ソースコー
    ド命令に対応するコンパイルアプリケーションコードの
    生成を実施するコンパイラであって、該コンパイルアプ
    リケーションコードが、１つ以上の前記アクセッサに対
    する１つ以上のプロシージャコールを含み、該各プロシ
    ージャコールが、前記ソースコード命令中の、前記クラ
    ス定義の１つ以上のオブジェクトインスタンスに対する
    １つ以上の参照に対応するようなコンパイラと；前記コ
    ンパイラによって生成された、前記コンパイルヘッダフ
    ァイルコードと、前記コンパイルアプリケーションコー
    ドのリンクを実施し、これにより実行可能なコンピュー
    タコードを生成するリンカとからなることを特徴とする
    実行可能コードの生成装置。
13. 【請求項１３】 前記コンパイラおよび前記リンカの選
    択的な呼出しを実施するコード生成ユーティリティプロ
    グラムをさらに含み；該ユーティリティプログラムが、
    前記コンパイルアプリケーションコードが以前に生成さ
    れているか否かを判定し、該コンパイルアプリケーショ
    ンコードが以前に生成されている場合には、該コンパイ
    ルアプリケーションコードが最後に生成された後に１つ
    以上のヘッダファイルクラス定義が変更されたとして
    も、該コンパイルアプリケーションコードを生成するコ
    ンパイラを呼び出さないようなユーティリティプログラ
    ムであることを特徴とする請求項１２記載の実行可能コ
    ードの生成装置。
14. 【請求項１４】 コンパイルアプリケーションプログラ
    ムコードを受け取って記憶するストレージファイルをさ
    らに含み、該ストレージファイルが前記ファイルの最新
    の変更を表すタイムスタンプを有し、前記ユーティリテ
    ィプログラムが、さらに、該ユーティリティプログラム
    が前記コンパイルアプリケーションコードの生成のため
    のコンパイラ呼出を行わなかった際に前記タイムスタン
    プのインクリメントを実施することを特徴とする請求項
    １３記載の実行可能コード生成装置。
15. 【請求項１５】 前記クラス定義がシンボリック名称と
    データの型の集まりを含み、前記アクセッサに対する前
    記各プロシージャコールが、該アクセッサに関連するク
    ラス定義の１つ以上の前記シンボリック名称およびデー
    タの型を指定することを特徴とする請求項１２記載の実
    行可能コードの生成装置。
16. 【請求項１６】 前記アクセッサが、関連付けられたク
    ラス定義のオブジェクトインスタンスの読み出し、書き
    込み、およびアドレス関連の操作を行う１つ以上のアク
    セッサを含むことを特徴とする請求項１２記載の実行可
    能コードの生成装置。
17. 【請求項１７】 前記アクセッサが、関連付けられたク
    ラス定義のオブジェクトインスタンスのメンバ関数を呼
    び出す１つ以上のアクセッサを含むことを特徴とする請
    求項１２記載の実行可能コードの生成装置。
18. 【請求項１８】 前記アクセッサが、関連付けられたク
    ラス定義のオブジェクトインスタンスの型変換を実行す
    る１つ以上のアクセッサを含むことを特徴とする請求項
    １２記載の実行可能コードの生成装置。
19. 【請求項１９】 前記アクセッサが、関連付けられたク
    ラス定義のオブジェクトインスタンスから１つ以上の定
    数値を取り出す１つ以上のアクセッサを含むことを特徴
    とする請求項１２記載の実行可能コードの生成装置。
20. 【請求項２０】 前記アクセッサが、関連付けられたク
    ラス定義のオブジェクトインスタンスから１つ以上のサ
    イズを取り出す１つ以上のアクセッサを含むことを特徴
    とする請求項１２記載の実行可能コードの生成装置。
21. 【請求項２１】 前記アクセッサが、関連付けられたク
    ラス定義のオブジェクトインスタンスに関する使用頻度
    の統計値を記録する１つ以上のアクセッサを含むことを
    特徴とする請求項１２記載の実行可能コードの生成装
    置。
22. 【請求項２２】 前記アクセッサが、関連付けられたク
    ラス定義のオブジェクトインスタンスに関して不変性の
    確認を行う１つ以上のアクセッサを含むことを特徴とす
    る請求項１２記載の実行可能コードの生成装置。
23. 【請求項２３】 コンピュータで利用可能な媒体と、ア
    プリケーションプログラムの実行可能なコンピュータコ
    ードを生成するための、該媒体に組み入れられたコンピ
    ュータで読取可能なプログラムコードとからなるコンピ
    ュータプログラムプロダクトであって、前記アプリケー
    ションプログラムが、１つ以上のヘッダファイルに対す
    る少なくとも１つの参照を含み、前記各ヘッダファイル
    が１つ以上のクラス定義を含み、該各クラス定義がオブ
    ジェクトインスタンスのクラスを定義し、さらに前記ア
    プリケーションプログラムが複数のＣ＋＋ソースコード
    命令を含み、該ソースコード命令が前記クラス定義の１
    つ以上のオブジェクトインスタンスに対する１つ以上の
    参照を含むようなコンピュータプロダクトにおいて、前
    記コンピュータで読取可能なプログラムコードが：コン
    ピュータに、１つ以上のアクセッサを含むコンパイルヘ
    ッダファイルコードを生成させるように形成され、前記
    各アクセッサが前記クラス定義のうち関連する１つのク
    ラス定義のオブジェクトインスタンスへのアクセスを実
    施するプロシージャであるような、コンピュータで読取
    可能なヘッダファイルコンパイラコードと；コンピュー
    タに、複数のＣ＋＋ソースコード命令に対応するコンパ
    イルアプリケーションコードを生成させるように形成さ
    れたコンピュータで読取可能なアプリケーションコンパ
    イラコードであって、該コンパイルアプリケーションコ
    ードが、１つ以上のアクセッサに対する１つ以上のプロ
    シージャコールを含み、該各プロシージャコールが、前
    記ソースコード命令中の、前記クラス定義の１つ以上の
    オブジェクトインスタンスに対する１つ以上の参照に対
    応するような、コンピュータで読取可能なアプリケーシ
    ョンコンパイラコードと；コンピュータに、前記コンパ
    イルヘッダファイルと前記コンパイルアプリケーション
    コードのリンクを行わせて、実行可能なコンピュータコ
    ードを生成するように形成されたコンピュータで読取可
    能なリンカコードとからなることを特徴とするコンピュ
    ータプログラムプロダクト。
24. 【請求項２４】 コンピュータに、前記コンピュータで
    読取可能なヘッダファイルコンパイラコード、前記コン
    ピュータで読取可能なアプリケーションコンパイラコー
    ド、および前記コンピュータで読取可能なリンカコード
    を選択的に実行させるように構成されたコンピュータで
    読取可能なユーティリティコードをさらに含み、該コン
    ピュータで読取可能なユーティリティコードが、コンピ
    ュータに、前記コンパイルアプリケーションコードが以
    前に生成されたものであれば、該コンパイルアプリケー
    ションコードが最後に生成された後に１つ以上のヘッダ
    ファイルクラス定義が変更されたとしても、該コンパイ
    ルアプリケーションコードを再生成しないような処理を
    行わせるように構成されたものであることを特徴とする
    請求項２３記載のコンピュータプログラムプロダクト。
25. 【請求項２５】 アプリケーションプログラムの実行可
    能なコンピュータコードを生成するメカニズムを提供す
    る方法であって、前記アプリケーションプログラムが１
    つ以上のヘッダファイルの少なくとも１つの参照を含
    み、前記各ヘッダファイルが１つ以上のクラス定義を含
    み、該各クラス定義がオブジェクトインスタンスのクラ
    スを定義し、前記アプリケーションプログラムがさら
    に、複数のＣ＋＋ソースコード命令を含み、該ソースコ
    ード命令が前記クラス定義の１つ以上のオブジェクトイ
    ンスタンスに対する１つ以上の参照を含むような方法に
    おいて：ヘッダファイルをコンパイルするメカニズムで
    あって、１つ以上のアクセッサを含むコンパイルヘッダ
    ファイルコードの生成を実施することができ、前記各ア
    クセッサが、前記クラス定義のうち関連する１つのクラ
    ス定義のオブジェクトインスタンスへのアクセスを実施
    するプロシージャであるような第１のメカニズムを提供
    し、 アプリケーションプログラムをコンパイルするメカニズ
    ムであって、複数のＣ＋＋ソースコード命令に対応する
    コンパイルアプリケーションコードの生成を実施するこ
    とができ、該コンパイルアプリケーションコードが１つ
    以上のアクセッサに対する１つ以上のプロシージャコー
    ルを含み、該各プロシージャコールが、ソースコード命
    令中の、前記クラス定義の１つ以上のオブジェクトリフ
    ァレンスに対する１つ以上の参照に対応するものである
    ような第２のメカニズムを提供し、 前記コンパイルヘッダファイルコードと前記コンパイル
    アプリケーションコードをリンクするメカニズムであっ
    て、該メカニズムにより実行可能なコンピュータコード
    の生成を実施することができる第３のメカニズムを提供
    することを特徴とするアプリケーションプログラムの実
    行可能なコンピュータコードを生成するメカニズムの提
    供方法。