JP2013506171A - 意味論的値を利用するオブジェクト・レベルの互換性及びクラスのサイズ変更 - Google Patents

Abstract

【課題】 コンピュータ・システムのための実行可能プログラムを作成する方法を提供すること。
【解決手段】 高水準言語で記述されたソフトウェア・コードを計算装置上でバイナリ・オブジェクトに変換する方法は、高水準言語で記述されたソフトウェア・コードを計算装置において受け取ることと、計算装置においてソフトウェア・コードをバイナリ・オブジェクトのファイルに翻訳することとを含む。翻訳することは、値がバイナリ・オブジェクトにハードコード化されることを必要とする対象項目をソフトウェア・コードが含むこと、及びクラスがサイズ変更可能であることを判定することと、ハードコード化された値を表す意味変数を作成し、意味変数及びハードコード化された値をバイナリ・オブジェクト内のテーブルに格納することとを含む。
【選択図】 図３

Description

本発明は、コンピュータ・システムのための実行可能プログラムを作成することに関し、より具体的には、意味論的値を使用してソフトウェア・コードを翻訳することに関する。

コンピュータ・プログラムは、典型的には、バイナリ・オブジェクトと呼ばれる１つ又は複数のコンポーネントから構成される。各バイナリ・オブジェクトは、プログラムをそのコンポーネントとして構成する実行可能コード又はモジュールの一部を表す。バイナリ・オブジェクトは、典型的には、より高水準の言語で記述されたソフトウェア・コードをバイナリ・オブジェクトに変換するコンパイラ（トランスレータとも呼ばれる）によって作成される。

バイナリ・オブジェクトは次に、互いにリンクされて、完全な実行可能プログラムを構成する。このタスクを実行するソフトウェア・ツールは、リンカと呼ばれる。

プログラムを実行する前に、そのプログラムをコンピュータのメモリ内にロードしなければならない。このタスクを実行するオペレーティング・システムのコンポーネントは、プログラム・ローダと呼ばれる。種々の理由のために、プログラムのいくつかのコンポーネントは、リンカによってプログラムにリンクされないことがある。その代わり、これらのコンポーネントは、ローダによって実行可能プログラム（executable）に加えられる。このようなコンポーネントは、典型的には、共有オブジェクト、共有ライブラリ、又は動的にロードされたライブラリと呼ばれる。

プログラムを多数のバイナリ・オブジェクトに分割することの利点の１つは、モジュール性である。１つのバイナリ・オブジェクトに対応するソース・コードを、その他のすべてのバイナリ・オブジェクトに対する変更を必要とすることなく、変更することができるようにすることが可能である。特に、コンパイラを用いて再び翻訳する必要があるのは、そのソース・コードが変更されたバイナリ・オブジェクトのみである。共有ライブラリを含めて、影響を受けないモジュールは、再翻訳される必要はない。

ＡＩＸ、Ｌｉｎｕｘ、Ｗｉｎｄｏｗｓ及びＺ／ＯＳを含むがこれらに限定されない現代のオペレーティング・システムにおいて広く用いられているリンカ／ローダ技術は、普及しているオブジェクト指向プログラミング言語の登場の前に考案された。そのため、これらの言語は、今日利用可能な種類のモジュール性によっては上手く対処できない新たな複雑さを生じさせる。具体的には、オブジェクト指向プログラマの日常の仕事中に一般に生じるいくつかのアクティビティは、直接影響を受けるバイナリ・オブジェクトだけでなく、プログラム全体を再翻訳することを必要とする。これらのアクティビティとしては、仮想関数をクラス・インターフェースに加えること、仮想関数をクラス・インターフェースから取り除くこと、仮想関数を因数分解して基底クラスのインターフェースにすること、データメンバをクラス・インターフェースに加えること、及び、新しい基底クラスを既存のクラスに加えることが挙げられるが、これらに限定されない。

プログラムの構成要素のバイナリ・オブジェクトのすべてをその共有ライブラリも含めて再コンパイルすることなく、これらのアクティビティを実行することができないことは、多大な制限である。単一の共有ライブラリが、多くの別々のアプリケーション・プログラムによって用いられている場合がある。結果として、これらの変更のいずれかが共有ライブラリ内でなされた場合、その共有ライブラリをコンポーネントとするすべてのアプリケーション・プログラムも再翻訳（再コンパイル）しなければならないことになる。アプリケーションのユーザは、熟練したプログラマではなく、適切なソフトウェア・ツールを所有せず、又はプログラムのソース・コードへのアクセス手段を持たないので、これは不可能である場合が多い。そのうえ、ユーザは、将来的にリンクするモジュール又は過去の開発に由来するモジュールを制御することができないかもしれない。結果として、共有ライブラリの作者は、自身のソフトウェアに対して行うことができる変更の種類に関して著しく制約される。場合によっては、これらの制約は単純なバグの修復さえ不可能にする。これは、リリース間バイナリ互換性（ＲＲＢＣ）問題として文献公知である。

本発明の目的は、上記の問題を解決する、コンピュータ・システムのための実行可能プログラムを作成する方法を提供することである

本発明の１つの実施形態によれば、高水準言語で記述されたソフトウェア・コードを計算装置上でバイナリ・オブジェクトに変換する方法が開示される。この実施形態は、高水準言語で記述されたソフトウェア・コードを計算装置において受け取ることと、計算装置においてソフトウェア・コードをバイナリ・オブジェクト・ファイルに翻訳することとを含む。翻訳することは、値がバイナリ・オブジェクトにハードコード化されることを必要とする対象項目をソフトウェア・コードが含むことと、そのクラスがサイズ変更可能であることとを判定することを含む。この実施形態における翻訳することは、ハードコード化された値を表す意味変数を作成することと、意味変数及びハードコード化された値をバイナリ・オブジェクト内のテーブルに格納することも含む。

本発明の別の実施形態は、複数のバイナリ・オブジェクトから実行可能プログラムを作成するための方法に向けられる。この実施形態の方法は、計算装置において、ハードコード化された値を必要とする少なくとも１つの値についてのハードコード化された値を表す意味変数のテーブルをすくなくとも１つが含む、第１の複数のバイナリ・オブジェクトを受け取ることと、第１の複数のバイナリ・オブジェクトを互いにリンクし、少なくとも１つのバイナリ・オブジェクト内の意味変数を少なくとも１つのテーブル内のハードコード化された値で置換することと、を含む。本方法は、第１の複数のバイナリ・オブジェクトを１つ又は複数の追加のバイナリ・オブジェクトと組み合わせて、動作のために計算装置へとロードすることも含む。

さらなる特徴及び利点は、本発明の技術を通じて理解される。本発明のその他の実施形態及び態様は、本明細書において詳細が説明され、特許請求される発明の一部と見なされる。本発明を利点及び特徴と共により良く理解するために、説明及び図面を参照されたい。

本発明と見なされる主題は、本明細書の結論部分の特許請求の範囲において具体的に指示され、明確に特許請求される。本発明の前述及びその他の特徴及び利点は、添付の図面と併せて解釈される以下の詳細な説明から明らかである。

本発明の実施形態に従う計算装置についてのシステム図である。 本発明の実施形態によって実行される処理の例を示すデータフロー図である。 本発明の実施形態に従う翻訳の方法を示す。 本発明の実施形態に従うバイナリ・オブジェクトをリンクする方法を示す。

本発明の実施形態は、典型的にはコンパイラによってバイナリ・オブジェクトに記述される特定の値が、その代わりに、変数と、後でリンカ又はローダのいずれかによって記述される値とで置き換えられる、コンパイラ−リンカ−ローダ・システムに向けられる。このようなシステムは、Ｃ又はＣ＋＋といった高水準プログラミング言語で記述されたプログラムでの使用に特に有用であり得る。当然のことながら、本発明は、Ｃ又はＣ＋＋で記述されたプログラムでの使用のみに限定されず、他の言語で記述されたプログラムで使用することもできる。

従来のＣ＋＋実装は、トランスレータの実行中に（すなわち、コンパイル時に）、以下の項目、すなわち、いずれかのクラス型のサイズ、いずれかのデータメンバのクラス内でのオフセット、及びいずれかの仮想関数ポインタのクラスの仮想テーブル（ｖテーブル又は均等物）内でのオフセット、を計算する。これらの値は、トランスレータによってオブジェクト・ファイルに記述される。本発明においては、トランスレータは、その代わりに、値にリンクされた変数を含むテーブルを作成する。値ではなく変数がオブジェクトに記述され、この変数をリンカ又はローダが用いて、テーブルにアクセスして値を置換する。したがって、再コンパイルされる必要があるのは、プログラムのすべての部分ではなく、上記の項目の定義を変更するオブジェクト・ファイルのみである。

図１は、本発明の実施形態を実装することができるコンピュータ・システムの例を示す。システムは分散型とすることもでき、後述のシステムの部分が、互いに異なる物理的位置に存在することができることを理解すべきである。

この実施形態において、システム１００は、１つ又は複数の中央処理装置（プロセッサ）１０１ａ、１０１ｂ、１０１ｃ等（集合的又は総称的にプロセッサ１０１と呼ばれる）を有する。１つの実施形態において、各プロセッサ１０１は、縮小命令セットコンピュータ（ＲＩＳＣ）マイクロプロセッサを含むことができる。プロセッサ１０１は、システム・バス１１３を介してシステム・メモリ１１４及び種々の他のコンポーネントに結合される。読み出し専用メモリ（ＲＯＭ）１０２は、システム・バス１１３に結合され、システム１００の特定の基本機能を制御する基本入力／出力システム（ＢＩＯＳ）を含むことができる。

図１は、さらに、システム・バス１１３に結合された入力／出力（Ｉ／Ｏ）アダプタ１０７及びネットワーク・アダプタ１０６を示す。Ｉ／Ｏアダプタ１０７は、ハードディスク１０３及び／又はテープ記憶ドライブ１０５又はその他のいずれかの同様のコンポーネントと通信する、小型コンピュータ・システム・インターフェース（ＳＣＳＩ）アダプタとすることができる。Ｉ／Ｏアダプタ１０７、ハードディスク１０３及びテープ記憶装置１０５は、ここでは集合的に大容量記憶装置１０４と呼ばれる。ネットワーク・アダプタ１０６は、バス１１３を、データ処理システム１００が他のこのようなシステムと通信するのを可能にする外部ネットワーク１１６と相互接続させる。スクリーン（例えば、ディスプレイ・モニタ）１１５は、グラフィックを多用するアプリケーションの性能を向上させるためのグラフィック・アダプタとビデオ・コントローラとを含むことができるディスプレイ・アダプタ１１２によって、システム・バス１１３に接続される。１つの実施形態において、アダプタ１０７、１０６及び１１２は、中間バス・ブリッジ（図示せず）を介してシステム・バス１１３に接続される１つ又は複数のＩ／Ｏバスに接続することができる。ハードディスク・コントローラ、ネットワーク・アダプタ及びグラフィック・アダプタといった周辺機器を接続するための好適なＩ／Ｏバスは、典型的には、周辺コンポーネント・インターフェース（ＰＣＩ）のような共通のプロトコルを含む。付加的な入力／出力装置は、ユーザ・インターフェース・アダプタ１０８及びディスプレイ・アダプタ１１２を介してシステム・バス１１３に接続されるものとして描かれている。キーボード１０９、マウス１１０及びスピーカ１１１はすべて、例えば、多数のデバイス・アダプタが単一の集積回路に組み込まれたスーパーＩ／Ｏチップを含むことができるユーザ・インターフェース・アダプタ１０８を介して、バス１１３に相互接続される。

このように、図１において構成されるように、システム１００は、プロセッサ１０１の形態の処理手段と、システム・メモリ１１４及び大容量記憶装置１０４を含む記憶手段と、キーボード１０９及びマウス１１０といった入力手段と、スピーカ１１１及びディスプレイ１１５を含む出力手段とを含む。１つの実施形態において、システム・メモリ１１４及び大容量記憶装置１０４の一部は、図１に示される種々のコンポーネントの機能を連係させるために、ＩＢＭ（登録商標）コーポレーションのＡＩＸ（登録商標）オペレーティング・システムのようなオペレーティング・システムを集合的に格納する。

システム１００は、任意の好適なコンピュータ又は計算プラットフォームとすることができ、端末、無線装置、情報家電、デバイス、ワークステーション、ミニコンピュータ、メインフレーム・コンピュータ、携帯情報端末（ＰＤＡ）又はその他の計算装置を含むことができることが理解されよう。システム１００は、通信ネットワークによって互いにリンクされる多数の計算装置を含むことができることを理解されたい。例えば、２つのシステム間にクライアント−サーバ関係が存在してもよく、その２つの間で処理を分割することができる。

システム１００がサポートできるオペレーティング・システムの例は、Ｗｉｎｄｏｗｓ（登録商標）９５、Ｗｉｎｄｏｗｓ（登録商標）９８、Ｗｉｎｄｏｗｓ ＮＴ（登録商標）４．０、Ｗｉｎｄｏｗｓ ＸＰ（登録商標）、Ｗｉｎｄｏｗｓ（登録商標）２０００、Ｗｉｎｄｏｗｓ（登録商標）ＣＥ、Ｗｉｎｄｏｗｓ Ｖｉｓｔａ（登録商標）、Ｍａｃ ＯＳ、Ｊａｖａ（登録商標）、ＡＩＸ（登録商標）、ＬＩＮＵＸ及びＵＮＩＸ（登録商標）、又はその他のいずれかの好適なオペレーティング・システムを含む。システム１００は、ネットワーク１１６上での通信のためのネットワーク・インターフェース１０６も含む。ネットワーク１１６は、ローカル・エリア・ネットワーク（ＬＡＮ）、都市域ネットワーク（ＭＡＮ）、又はインターネット若しくはワールド・ワイド・ウェブといった広域ネットワーク（ＷＡＮ）とすることができる。

システム１００のユーザは、標準的な電話回線、デジタル加入者回線、ＬＡＮ又はＷＡＮリンク（例えば、Ｔ１、Ｔ３）、ブロードバンド接続（フレーム・リレー、ＡＴＭ）及び無線接続（例えば、８０２．１１（ａ）、８０２．１１（ｂ）、８０２．１１（ｇ））
といった任意の好適なネットワーク・インターフェース１１６接続を通じてネットワークに接続することができる。

本明細書で開示されるように、システム１００は、ユーザのスクリーン１１５上に示される情報の取り込み及び対話式表示のための、機械可読媒体（例えば、ハードディスク１０４）上に格納される機械可読命令を含む。ここで論じられるように、命令は、「ソフトウェア」１２０と呼ばれる。ソフトウェア１２０は、当該技術分野で公知のソフトウェア開発ツールを用いて生成することができる。ソフトウェア１２０は、当該技術分野で公知のユーザ対話能力を提供するための種々のツール及び特徴を含むことができる。

いくつかの実施形態において、ソフトウェア１２０は、別のプログラムへのオーバーレイとして提供される。例えば、ソフトウェア１２０は、アプリケーション（又はオペレーティング・システム）に「アドイン」として提供することができる。「アドイン」という用語は、当該技術分野で公知のように補足的なプログラム・コードのことを一般に指すことに留意されたい。このような実施形態において、ソフトウェア１２０は、そのソフトウェアが協働するアプリケーション又はオペレーティング・システムの構造又はオブジェクトを置換することができる。

図２は、１つの実施形態によるシステム内のデータ移動を示すデータフロー図である。システムは、トランスレータ２０２を含む。トランスレータ２０２は、いずれかの既知のコンパイラに基づくものとすることができる。トランスレータ２０２は、１つ又は複数のソース・コード・ファイル２０４を受け取り、各ソース・コード・ファイルをオブジェクト・ファイル２０６に変換する。当然のことながら、ソース・コード・ファイルの正確な数は様々であり得、例えば、多くのアプリケーションによって用いられる共有ライブライリ又は他のソース・コード・ファイルを含んでいてもよい。

しかしながら、トランスレータ２０２は、ソース・コードからオブジェクト・ファイルを作成する方式が典型的なトランスレータとは異なり得る。特に、トランスレータ２０２は、従来のコンパイラでは典型的にはハードコード化されてオブジェクト・ファイルにされていた特定の値にリンクする変数を含むテーブル２０８を、各オブジェクト・ファイル内に作成することができる。値ではなく変数がオブジェクトに記述され、その変数をリンカ２１０又はローダ２１２が用いてテーブルにアクセスし、そのときに変数が値で置換される。

システムは、リンカ２１０も含む。リンカ２１０は、従来のリンカと類似したものとすることができる。リンカ又はリンク・エディタは、コンパイラ２０２によって生成された１つ又は複数のオブジェクト２０６を取得し、それらを組み合わせて単一の実行可能プログラム２１２にするプログラムである。しかしながら、本発明の１つの実施形態によるリンカ２１０は、各オブジェクト・ファイル２０６のテーブル２０８を調べて、従来技術のコンパイラの場合には典型的にはオブジェクト・ファイル２０６に記述されていた静的値を変数に代入するように構成することができる。これらの値は、実行可能プログラム内でハードコード化される。ハードコード化された値は、変化しない値である。ハードコード化された値の例は、変数が特定の整数に割り当てられる場合である。当然のことながら、テーブルに含まれた値のすべてがハード値に変換されるわけではなく、実行可能プログラムは、実行可能変数テーブル２１４を含むことができる。

システムは、ローダ２１６を含むこともできる。ローダは、プログラムを実行可能プログラム（すなわち、実行可能ファイル）からメモリへとロードし、実行のためにそれらを準備し、次いでそれらを実行することを担当する、オペレーティング・システムの一部である。従来技術において、ローダは、通常はオペレーティング・システムのカーネルの一部であり、通常は、システムの起動時にロードされ、そして、システムが再起動され、シャットダウンされ又は電源が切られるまでメモリ内にとどまる。ページ可能カーネルを有するいくつかのオペレーティング・システムは、ローダをメモリのページ可能部分に有する場合があり、したがって、ローダはときにはメモリからスワップアウトすることがある。プログラムのローディングをサポートするすべてのオペレーティング・システムが、ローダを有する。

本発明の実施形態によるローダ２１６は、従来技術のローダと類似した動作を行う。しかしながら、ローダ２１６もまた、各実行可能プログラム２１２の実行可能変数テーブル２１４を調べて、従来技術のコンパイラの場合には典型的にはオブジェクト・ファイル２０６に記述されていたハード値を変数に代入する。

図３は、本発明の１つの実施形態によるトランスレータ２０２（図２）の動作の方法を示す。ブロック３０２において、翻訳される１つの部分又はすべての部分がトランスレータで受け取られる。トランスレータ（又はコンパイラ）は、コンピュータ言語（ソース言語）で記述されたソース・コードを別のコンピュータ言語（オブジェクト・コードとして知られるバイナリ形式を有する場合が多い目的言語）に変形するコンピュータ・プログラム（又はプログラムの集合）である。ソース・コードを変形することが所望される最も一般的な理由は、実行可能プログラムを作成するためである。

ブロック３０４において、翻訳されるべきさらなるセクション（ソース・コード・ファイル全体又はそのセクションのどちらか）が存在するかどうかが判定される。存在しなければ、方法は終了し、翻訳は完了する。

行われるべきさらなる翻訳が存在する場合には、ブロック３０６において、次のセクション又はファイルが翻訳される。ブロック３０６（翻訳）の一部として、ブロック３０８において、セグメントが対象項目を含むかどうかが判定される。本明細書において用いられる「対象項目」という用語は、従来技術のトランスレータならば翻訳中に静的値を作成したであろうコード・セグメントを指すものとする。対象項目の例としては、クラス型のサイズ、クラス・オブジェクト内の非静的データメンバにアクセスするために用いられるオフセット、及び仮想関数テーブル・オフセットを挙げることができるが、これらに限定されない。従来のＣ＋＋実装は、トランスレータの実行中に（すなわち、コンパイル時に）、以下の項目、すなわち、いずれかのクラス型のサイズ、いずれかのデータメンバのクラス内でのオフセット、及びいずれかの仮想関数のポインタのクラスのｖテーブル（仮想テーブル又は均等物）内でのオフセット、を計算することが理解されよう。これらの計算値は、今まではトランスレータによってオブジェクト・ファイルに記述されていた、上記の「静的な」又はハードコード化された値である。

説明として、Ｃ＋＋プログラミング言語は、クラスの使用を通じて、プログラマがプログラム特有のデータ型を定義することを可能にする。これらのデータ型のインスタンスはオブジェクトとして知られており、メンバ変数、定数、メンバ関数、及びプログラマによって定義される多重定義演算子を含むことができる。構文的には、クラスは、関数又は多重定義演算子を含むことができないＣ構造の拡張である。以下の説明は、Ｃ＋＋言語についての例を説明するが、他の言語も想定されており、それらは本発明の範囲内であることを理解されたい。

ブロック３１０において、変数名を有する翻訳が作成される。これは、非限定的な以下の例によって示されるように、従来技術とは異なる。

コンパイル時に、Ｃ＋＋言語トランスレータによって「ｓｉｚｅｏｆ」式の値が計算される。ｓｉｚｅｏｆ演算子は、ｃｈａｒ型のサイズに関してそのオペランドのサイズを与える。従来のＣ＋＋実装は、ｓｉｚｅｏｆ式を、オクテットで数えたそのオペランドのサイズに等しいて定数値で置き換える。例えば、
ｓｔｒｕｃｔ Ｓ｛
ｉｎｔ ｄａｔｕｍ；
｝；
ｃｏｎｓｔ ｓｉｚｅ＿ｔ ｃｈａｒ＿ｓｉｚｅ＝ｓｉｚｅｏｆ（Ｓ）；
というステートメントは、以下のように翻訳され、
ｃｏｎｓｔ ｓｉｚｅ＿ｔ ｃｈａｒ＿ｓｉｚｅ＝４
ここで、値「４」が、バイナリ・オブジェクトへとハードコード化されることになる。

本発明の実施形態は、ｓｉｚｅｏｆ演算子に対するオペランドがクラス型であるか又はクラス型を有する場合に、変形された式が、ｓｉｚｅｏｆ式を序数値ではなく記号定数で置き換えるという点で、従来の実装とは異なり得る。例えば、本発明のトランスレータは、上記のステートメントを、
ｃｏｎｓｔ ｓｉｚｅ＿ｔ ｃｈａｒ＿ｓｉｚｅ＝＿ＳＹＭＢＯＬ＿ｓｉｚｅｏｆ＿Ｓ
と翻訳することができる。

ブロック３１２において、＿ＳＹＭＢＯＬ＿ｓｉｚｅｏｆ＿Ｓのハード値（この例では４）が、テーブルに格納される。このテーブルを次にリンカ又はローダが用いて、後で式＿ＳＹＭＢＯＬ＿ｓｉｚｅｏｆ＿Ｓに値４が挿入される。このことにより、プログラム全体を再コンパイルする必要なく、１つのセクションにおいて変更がなされ、変更を有するセクション（例えば、変更されたオブジェクト・ファイル）のみを再コンパイルすることが可能になる。このことは、上述の問題のいくつか又はすべてを軽減する。

以下の項は、コンパイラに対して行うことができるその他の変更と、それらをどのように理解することができるかを説明する。例えば、従来技術において動的にメモリを割り当てる（例えば「ｎｅｗ」式）の場合、
ｓｔｒｕｃｔ Ｓ｛
ｉｎｔ ｄａｔｕｍ；
｝；
Ｓ＊ｓｐｔｒ＝ｎｅｗ Ｓ
のようなステートメントは、
ｓｔｒｕｃｔ Ｓ｛
ｉｎｔ ｄａｔｕｍ；
｝；
Ｓ＊ｓｐｔｒ＝：：ｏｐｅｒａｔｏｒ ｎｅｗ（４）
というステートメントに変形することができる。

上述のように、値「４」は、バイナリ・オブジェクトにハードコード化されるものであり、メモリ・アロケータから要求される記憶域（ｓｔｏｒａｇｅ）の量を表す。この値は、メモリ・アロケータを呼び出す関数：：ｏｐｅｒａｔｏｒ ｎｅｗに対する引数として渡される。本発明の実施形態は、ｎｅｗ式に対するオペランドがクラス型である場合に、変形されたｎｅｗ式が、：：ｏｐｅｒａｔｏｒ ｎｅｗに対する引数として序数値ではなく記号定数を渡すという点で、この従来の実装とは異なり得る。例えば、上記のステートメントは、本発明の実施形態によれば、
ｓｔｒｕｃｔ Ｓ｛
ｉｎｔ ｄａｔｕｍ；
｝；
Ｓ＊ｓｐｔｒ＝：：ｏｐｅｒａｔｏｒ ｎｅｗ（＿ＳＹＭＢＯＬ＿ｓｉｚｅｏｆ＿Ｓ）
に変形することができる。

別の例として、自動スコープ指定(ａｕｔｏｍａｔｉｃａｌｌｙ−ｓｃｏｐｅｄ）オブジェクトの割当ては、本発明においては異なり得る。従来技術においては、値関数パラメータを含む自動スコープ指定オブジェクトは、プログラム・スタック上で割り当てられる。所与のクラス・オブジェクトのためにスタック上に確保される記憶域の量は、バイナリ・オブジェクトにハードコード化される。本発明の実施形態は、割り当てられるオブジェクトがクラス型を有する場合に、確保される記憶域の量が、上述の方式と同じような方式で、序数値ではなく記号定数によって決定されるという点で、従来の実装とは異なり得る。

さらに別の例として、静的スコープ指定オブジェクトの割当ての場合を考える。典型的には、静的割当てを伴うクラス・オブジェクトは、プログラムがロードされるときにそれらのために確保されたメモリ内に格納される。この目的のために確保されるべき記憶域の量は、この目的のために存在するバイナリ・オブジェクト・ファイルのセクションにおいて指定される。例えば、共通オブジェクト・ファイル形式（ＣＯＦＦ）において、各静的クラス・オブジェクトのために確保される記憶域の量は、オブジェクト・ファイルの．ｂｓｓセクションにおいて指定される。本発明の実施形態においては、トランスレータは、従来のプラクティスに従ってオブジェクト・ファイルの．ｂｓｓセクション（又は均等物）をコード化するが、ただし、．ｂｓｓセクション（又は均等物）内の各エントリは、その静的割当てが表されているクラス・オブジェクトの型を示す追加情報を含むことになる。この追加情報を、プログラム・ローダが用いることができる。

別の例として、多重継承の存在下でのサブオブジェクトのオフセットの場合を考える。多重継承の存在下では、クラス・オブジェクトの型を大部分の派生型から基底型へ、又は基底型間で変換する場合に、「ｔｈｉｓ」ポインタをオフセットを用いて調整することが必要である。例えば、以下の式を考える。
ｓｔｒｕｃｔ Ｌｅｆｔ｛
ｉｎｔ ｄａｔｕｍ１；
｝；
ｓｔｒｕｃｔ Ｒｉｇｈｔ｛
ｉｎｔ ｄａｔｕｍ２；
｝；
ｓｔｒｕｃｔ Ｄｅｒｉｖｅｄ：Ｌｅｆｔ，Ｒｉｇｈｔ｛
ｉｎｔ ｄａｔｕｍ３；
｝；
ｖｏｉｄ ｆｎ（Ｒｉｇｈｔ＊ａｒｇ）；
ｉｎｔ ｍａｉｎ（）｛
Ｄｅｒｉｖｅｄ ｄｏｂｊ；
ｆｎ（＆ｄｏｂｊ）；
｝

この例のクラス・オブジェクトｄｏｂｊは、Ｌｅｆｔ型のサブオブジェクトと、別のＲｉｇｈｔ型のサブオブジェクトとを含む。従来のＣ＋＋のコンパイラならば、Ｌｅｆｔ型のサブオブジェクトをｄｏｂｊ内にオフセット０で配置する。Ｒｉｇｈｔ型のサブオブジェクトは、＿ＳＹＭＢＯＬ＿ｓｉｚｅｏｆ＿ＬｅｆｔをクラスＬｅｆｔ型のサイズを表す記号定数とすることで計算されるオフセットで、ｄｏｂｊ内に配置される。ＤｅｒｉｖｅｄＭｅｍｂｅｒｓを、その基底クラスから継承されたメンバを除く、クラスＤｅｒｉｖｅｄ型の非静的データメンバのすべての総計サイズを表す記号定数とする。ＤｅｒｉｖｅｄＭｅｍｂｅｒｓは、必要とされるあらゆるアラインメント・パディングのサイズも含む。ｄｏｂｊ内のＲｉｇｈｔ型のサブオブジェクトのオフセットは、＿ＳＹＭＢＯＬ＿ｓｉｚｅｏｆ＿ＬｅｆｔとＤｅｒｉｖｅｄＭｅｍｂｅｒｓとの合計である。従来のＣ＋＋トランスレータにおいては、このオフセットは、必要に応じて計算され、オブジェクト・ファイルに直接コード化される。例えば、ｆｎ（）という名前の関数に対するコールにおいて、式＆ｄｏｂｊの型は、Ｄｅｒｉｖｅｄ＊型からＲｉｇｈｔ＊型に変換されなければならない。これを達成するためには、式＆ｄｏｂｊによって表されるポインタは、オブジェクトｄｏｂｊのアドレスではなく、ｄｏｂｊが含むＲｉｇｈｔ型のサブオブジェクトのアドレスを示すように調整されなければならない。この調整は、ｄｏｂｊのアドレスに、ｄｏｂｊに対するＲｉｇｈｔサブオブジェクトのオフセットを加えることによって達成される。ｉｎｔのｓｉｚｅｏｆが４であり、ｉｎｔのアラインメントが４であると仮定すると、ｄｏｂｊ内のＲｉｇｈｔのオフセットは８である。したがって、従来のＣ＋＋コンパイラは、上記の関数ｍａｉｎ（）を、
ｉｎｔ ｍａｉｎ（）｛
Ｄｅｒｉｖｅｄ ｄｏｂｊ；
ｆｎ（ｓｔａｔｉｃ＿ｃａｓｔ＜Ｒｉｇｈｔ＊＞（＆ｄｏｂｊ＋８））；
｝
に変形することになる。

オフセットは、生成されたコードにおいて数値として直接的に表現される。本発明においては、そのようなオフセットは、序数値としてではなく記号定数として表される。
ｉｎｔ ｍａｉｎ（）｛
Ｄｅｒｉｖｅｄ ｄｏｂｊ；
ｆｎ（ｓｔａｔｉｃ＿ｃａｓｔ＜Ｒｉｇｈｔ＊＞（＆ｄｏｂｊ＋
＿ＳＹＭＢＯＬ＿ｏｆｆｓｅｔｏｆ＿Ｒｉｇｈｔ＿ｗｉｔｈｉｎ＿Ｄｅｒｉｖｅｄ））；
｝

これらの同じオフセットが、仮想関数が呼び出されるときに用いられる。しかしながら、オフセットの値は仮想関数をディスパッチするために用いられるオブジェクトの動的な型に依存するので、プログラムが実行されるまでオフセットの動的な型を知ることができないという理由で、オフセットを関数コール位置内にコード化することができない。この理由のため、オフセットは、ｖテーブル内に「ｔｈｉｓ ａｄｊｕｓｔｍｅｎｔ」としてコード化される。これを達成するための２つの一般的な技術が存在し、すなわち（１）ｖテーブルの各エントリは、仮想関数及び適切なオフセットに対するポインタから構成されるペアである、又は（２）ｖテーブルは、実行可能コードに対するポインタからのみ構成され、このポインタによって参照されるコードは、仮想関数、又はオフセットがゼロ以外である場合には「アジャスタ・サンク」のいずれかとすることができ、アジャスタ・サンクは、正しいオフセットを呼出し元オブジェクトのｔｈｉｓポインタに加え、次に仮想関数へと分岐する。いずれの場合でも、従来のＣ＋＋トランスレータは、数値を用いてオフセットを表す。本発明においては、上述のように、オフセットは記号定数を用いて表される。

別の例は、動的キャスト・テーブルに関係するものであり得る。Ｃ＋＋実装は、プログラム実行中にクラス型の相互変換が計算されることを可能にするために、動的キャスト・テーブルを生成する。動的キャスト・テーブルは、上で説明されたものと類似した、サブオブジェクトのオフセットを含む。本発明においては、これらのオフセットは、上述のように、記号定数を用いて表される。

クラスのサイズに加えて、従来のＣ＋＋実装は、クラス・オブジェクト内の非静的データメンバにアクセスするために用いられるオフセットをハードコード化する。本発明において、オフセットは、記号定数を用いて表される。この技術は、直接メンバ・アクセス、及び非静的データメンバに対するポインタの両方に適用される。

さらに、本発明の実施形態は、上記の技術を、仮想関数テーブル・オフセットの場合に適用することができる。あるクラスのｖテーブル内の個々のエントリは、そのｖテーブル内へのオフセットを用いてアクセスされる。従来のＣ＋＋実装は、これらのオフセットを関数コール位置にハードコード化する。例えば、
ｓｔｒｕｃｔ Ｂａｓｅ｛
ｖｉｒｔｕａｌ ｖｏｉｄ ｆｏｏ（）ｃｏｎｓｔ｛｝
ｖｉｒｔｕａｌ ｖｏｉｄ ｂａｒ（）ｃｏｎｓｔ｛｝
｝；
ｓｔｒｕｃｔ Ｄｅｒｉｖｅｄ：Ｂａｓｅ｛
ｖｉｒｔｕａｌ ｖｏｉｄ ｂａｒ（）ｃｏｎｓｔ｛｝
｝；
ｉｎｔ ｍａｉｎ（）｛
ｃｏｎｓｔ Ｂａｓｅ＆ｒｅｆ＝Ｄｅｒｉｖｅｄ（）；
ｒｅｆ．ｂａｒ（）；
｝

各ｖテーブル・エントリが４バイトを占有し、ｖテーブルに対するポインタが、クラス型がＢａｓｅ又はＤｅｒｉｖｅｄのオブジェクトの開始からオフセット０で配置される場合には、ｍａｉｎ（）内の関数ｂａｒ（）に対するコールは、以下のように変形される。
（＊＊（（ｖｏｉｄ（＊＊）（）ｃｏｎｓｔ）（ｒｅｆ−＞０＋４）））（ｒｅｆ）

部分式ｒｅｆ−＞０は、ｖテーブルの開始のアドレスを表し、数字４は、仮想メンバ関数ｂａｒ（）を表すエントリのｖテーブル内でのオフセットである。本発明においては、この数字は、記号定数によって置き換えられる。

クラスのｖテーブルは、仮想基底ポインタ（ＶＢＰ）を含むこともできる。これらは、親クラス（ｃｏｎｔａｉｎｉｎｇ ｃｌａｓｓ）オブジェクト内部での基底クラス・サブオブジェクトのオフセットに等しく、上で説明したのと同様に扱われる。

上述の説明は、ブロック３１０で行うことができる置換の例を詳述する。それらを表すのに用いられる値及び記号定数は、ブロック３１２においてオブジェクト・ファイルのテーブル内に格納されることを理解されたい。

上記において識別した記号定数の各々は、ブロック３１２において作成されたオブジェクト・ファイル形式の随意的なヘッダ又はフッタ・セクション内に配置される４つのテーブルのうちの１つにおいて定義することができる。プログラム・リンカ及びローダを本発明に従って拡張して、プログラム・リンカ及びローダがこのセクションを読み取ることを可能にすることができる。１つの実施形態において、４つのテーブルは、以下のテーブルを含む。すなわち、１）クラス型ごとに単一の列を充てる、クラス型サイズのテーブル。このテーブルにおいて、所与の列は、情報の３つの項目、すなわち、クラス型のサイズを表す記号定数の名前と、通常の方法を用いて言語トランスレータによって判定されたクラス型のサイズと、そのクラス型がリンカ／ローダによってサイズ変更することができるかどうかを示すフラグとを含む。２）上述のような、親クラス内でのサブオブジェクト・オフセットのテーブル。所与の列は、情報の２つの項目、すなわち、記号定数の名前と、オフセットの値とを含む。３）非静的データメンバ・オフセットのテーブル。所与の列は、情報の２つの項目、すなわち、記号定数の名前と、オフセットの値及び値とを含む。４）ｖテーブル・オフセットのテーブル。

１つの実施形態において、目的の実行可能プログラムが動的ライブラリ又は共有ライブラリにリンクしていない場合には、上述の記号定数のすべてをリンカによって解決することができる。実行可能コード内に現れる各記号定数は、適切なテーブルによって判定されように、対応する値で置換される。これらのテーブルを含むヘッダ又はフッタ・セクションは随意的であるので、本発明を具体化するリンカは、これらのファイルを含むバイナリ・オブジェクトを、これらを含まないバイナリ・オブジェクトと同様に消費することができる。この理由から、既存のＣ＋＋のコンパイラを拡張して本発明を具体化することが可能であり、より以前のバージョンのコンパイラによって作成されたバイナリ・オブジェクトを、そのテーブルを生成した新しいバージョンのコンパイラによって作成されたバイナリ・オブジェクトにリンクすることができる。

図４は、本発明の実施形態に従ってリンカ又はローダがどのように動作し得るかのフローチャートを示す。ブロック４０２において、トランスレータによって作成されたバイナリ・オブジェクトが、リンカで受け取られる。受け取りは、リンカと同じ位置又は異なる位置のコンパイラからであり得る。リンカは、ブロック４０４において、オブジェクト・ファイルを調査して、本発明に従ういずれかテーブルをオブジェクト・ファイルが含むかどうか判定する。テーブルが存在する場合には、ブロック４０６において、リンカによって、記号定数が静的値で置換される。このプロセスは、以下で詳述する。ブロック４０８において、リンカは、従来技術と同様にオブジェクトをリンクし続ける。

上述のように、ブロック４０６において記号定数が置換される。通常、クラス型は、それを用いるあらゆるプログラム・モジュール内で定義されている。あるクラス型が何らかの方法で修正される場合には、そのクラス型を定義するプログラム・モジュールに対応するあらゆるバイナリ・オブジェクトを再コンパイルしなければならない。従来のＣ＋＋トランスレータ／リンカ環境において、あるクラスがなんらかの方法で修正された後の、そのクラス定義を含むあらゆるモジュールの再翻訳の失敗は、実行中のリンク時間エラー又はプログラム誤動作を生じさせることになる。本発明の実施形態によるリンカは、この問題に対処することができる。クラス定義がそのサイズが変更されるような方法で修正される場合、又はいずれかの非静的データメンバ若しくは基底クラス・サブオブジェクトのその中での位置が変更される場合を考える。上述のテーブルは、リンカが、所与のクラス型の定義に関するバイナリ・オブジェクト間の不一致を検出することを可能にするのに十分な情報を含む。これらの不一致の調整は、以下の方法のいずれかで行うことができる。すなわち、１）時刻及び日付スタンプ：最新に作成されたバイナリ・オブジェクトからの情報を使用する。２）クラス・バージョン管理：プログラマがプラグマ・ダイレクティブ（ｐｒｏｇｒａｍａ ｄｉｒｅｃｔｉｖｅ）によってバージョン番号をそのクラスに関連付けることを可能にし、クラスの最新のバージョンに関連付けられた情報を使用する。３）プログラマの対話：プログラマが、リンカを呼び出すときに、不一致をどのように解決するかを直接指定することを可能にする。４）最も大きいクラスを作り出す結果となるクラス定義のバージョンをもたらす。５）不一致の原因となるクラスに対応するｖテーブルを含むバイナリ・オブジェクトからの情報をもたらす。

ローダは、１つ又は複数の共有ライブラリが利用される場合には、リンカに関して上で説明した方式と同じように動作することができることに留意されたい。

当然のことながら、当業者であれば認識するように、本発明の実施形態は、いくつかの個別の状況においては困難に遭遇するかもしれない。これらの困難としては、例えば、多相的クラスへの項目の付加及びそこから項目の削除、関数のインライン展開、及びテンプレートの取り扱いを挙げることができる。それゆえ、これらの型のクラスをサイズ変更不可としてマークすることができ、コンパイラは、これらに対しては、従来技術の場合と同様に動作する。

本発明書で用いられる用語は、特定の実施形態を説明することのみを目的とし、本発明を限定することを意図しない。本明細書で使用される場合、単数形「１つの（ａ）、（ａｎ）」及び「その（ｔｈｅ）」は、文脈がそうでないことを明らかに示さない限り、複数形も同様に含むことが意図される。「含む（ｃｏｍｐｒｉｓｅｓ）」及び／又は「含んでいる（ｃｏｍｐｒｉｓｉｎｇ）」という用語は、本明細書で使用される場合には、言及された特徴、整数、ステップ、動作、要素及び／又はコンポーネントの存在を特定するが、１つ又は複数の他の特徴、整数、ステップ、動作、要素、コンポーネント及び／又はそれらの群の存在又は付加を排除するものではないことがさらに理解されるであろう。

以下の特許請求の範囲内のすべての「手段又はステップと機能との組合せ（ミーンズ又はステップ・プラス・ファンクション）」要素の対応する構造、材料、動作及び均等物は、明確に特許請求されている他の特許請求された要素と組み合わせてその機能を実行するための、いかなる構造、材料又は動作をも含むことが意図される。本発明の説明は、例証及び説明の目的で提示されたものであるが、網羅的であることを意図するものでもなく、開示された形態の発明に限定することを意図するものでもない。本発明の範囲及び真意から逸脱することのない多くの修正及び変形が、当業者には明らかであろう。実施形態は、本発明の原理及び実際の適用を最も良く説明するように、及び、当業者が、企図される特定の使用に適するように種々の修正を伴う種々の実施形態について本発明を理解することを可能にするように、選択され、説明されている。

本明細書で示されるフロー図は、単に１つの例である。本発明の真意から逸脱することなく、この図及びその中に記載されたステップ（又は動作）に対して多くの変形が存在し得る。例えば、ステップを異なる順序で実行することもでき、又はステップを追加し、削除し又は修正することもできる。これらの変形のすべては、特許請求される発明の一部と見なされる。

本発明の好適な実施形態を説明してきたが、現在及び将来の両方において、当業者が、以下の特許請求の範囲内に入る種々の改善及び強化を行うことができることが理解されよう。これらの特許請求の範囲は、最初に記載される発明の適正な保護を維持するよう解釈されるべきである。

１０４：大容量記憶装置
２０８、２１４：テーブル

Claims (20)

1. 高水準言語で記述されたソフトウェア・コードを計算装置上でバイナリ・オブジェクトに変換する方法であって、
   前記高水準言語で記述された前記ソフトウェア・コードを前記計算装置において受け取ることと、
   前記計算装置において前記ソフトウェア・コードをバイナリ・オブジェクト・ファイルに翻訳することと、
   を含み、前記翻訳することが、
   値が前記バイナリ・オブジェクトにハードコード化されることを必要とする対象項目を前記ソフトウェア・コードが含むこと、及びそのクラスがサイズ変更可能であることを判定することと、
   前記ハードコード化された値を表す意味変数を作成し、前記意味変数及び前記ハードコード化された値を前記バイナリ・オブジェクト内のテーブルに格納することと、
   を含む方法。
2. 前記高水準言語が、Ｃ＋＋である、請求項１に記載の方法。
3. 前記対象項目が、クラス型サイズ、非静的データメンバに対するオフセット、及び仮想関数テーブル・オフセットのうちの１つである、請求項１に記載の方法。
4. 前記テーブルが、ｖテーブル・オフセットのテーブルである、請求項１に記載の方法。
5. 前記テーブルが、クラス型サイズのテーブルである、請求項１に記載の方法。
6. 前記テーブルが、親クラス内でのサブオブジェクト・オフセットのテーブルである、請求項１に記載の方法。
7. 前記テーブルが、非静的データメンバ・オフセットのテーブルである、請求項１に記載の方法。
8. 前記テーブルが、前記バイナリ・オブジェクトのヘッダ部分に格納される、請求項１に記載の方法。
9. 前記計算装置上のリンカにおいて複数のバイナリ・オブジェクトを受け取るステップと、
   前記複数のバイナリ・オブジェクトを互いにリンクするステップと、
   事前定義された優先度に基づいて、テーブルを有する各オブジェクト内の前記テーブル間の不一致を解決するステップと
   をさらに含む、請求項８に記載の方法。
10. バイナリ・オブジェクトごとに、少なくとも１つのテーブルを含む、請求項９に記載の方法。
11. 少なくとも１つのバイナリ・オブジェクトが、テーブルを含まない、請求項１０に記載の方法。
12. 前記事前定義された優先度が、より新しいテーブルがより古いテーブルに優先して選択されるようにさせる、請求項９に記載の方法。
13. 前記事前定義された優先度が、より高いバージョン番号を有するテーブルがより低いバージョン番号を有するテーブルに優先して選択されるようにさせる、請求項９に記載の方法。
14. 前記事前定義された優先度が、前記バイナリ・オブジェクト間の不一致の原因となる仮想テーブルを含むオブジェクトが、それを含まないオブジェクトに優先して選択されるようにさせる、請求項９に記載の方法。
15. 複数のバイナリ・オブジェクトから実行可能プログラムを作成するための方法であって、
    計算装置において、ハードコード化された値を必要とする少なくとも１つの値についてのハードコード化された値を表す意味変数のテーブルを少なくとも１つが含む、第１の複数のバイナリ・オブジェクトを受け取ることと、
    前記第１の複数のバイナリ・オブジェクトを互いにリンクし、少なくとも１つのバイナリ・オブジェクト内の意味変数を前記少なくとも１つのテーブル内の前記ハードコード化された値で置換することと、
    前記第１の複数のバイナリ・オブジェクトを１つ又は複数の追加のバイナリ・オブジェクトと組み合わせて、動作のために前記計算装置へとロードすることと
    を含む方法。
16. ハードコード化された値を要求する前記値が、クラス型サイズ、非静的データメンバに対するオフセット、及び仮想関数テーブル・オフセットのうちの１つである、請求項１５に記載の方法。
17. 前記少なくとも１つのテーブルが、ｖテーブル・オフセットのテーブルであることを特徴とする、請求項１５に記載の方法。
18. 前記少なくとも１つのテーブルが、クラス型サイズのテーブルである、請求項１５に記載の方法。
19. 前記少なくとも１つのテーブルが、親クラス内でのサブオブジェクト・オフセットのテーブルである、請求項１５に記載の方法。
20. 前記少なくとも１つのテーブルが、前記バイナリ・オブジェクトのヘッダ部分に格納される、請求項１５に記載の方法。

Images