JPH07262011A - 持続的共用型オブジェクトの多重継承管理方法 - Google Patents
持続的共用型オブジェクトの多重継承管理方法Info
- Publication number
- JPH07262011A JPH07262011A JP7051463A JP5146395A JPH07262011A JP H07262011 A JPH07262011 A JP H07262011A JP 7051463 A JP7051463 A JP 7051463A JP 5146395 A JP5146395 A JP 5146395A JP H07262011 A JPH07262011 A JP H07262011A
- Authority
- JP
- Japan
- Prior art keywords
- class
- pointer
- address
- inheritance
- offset
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
- G06F9/4488—Object-oriented
- G06F9/4493—Object persistence
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
- G06F9/4488—Object-oriented
- G06F9/449—Object-oriented method invocation or resolution
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99941—Database schema or data structure
- Y10S707/99944—Object-oriented database structure
- Y10S707/99945—Object-oriented database structure processing
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99941—Database schema or data structure
- Y10S707/99948—Application of database or data structure, e.g. distributed, multimedia, or image
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Devices For Executing Special Programs (AREA)
- Stored Programmes (AREA)
Abstract
(57)【要約】
【目的】持続的でかつ共用されるオブジェクトを用いる
システム又は言語における多重継承管理方法を提供す
る。 【構成】オブジェクトＯｂｊ Ｃｉのフォーマットは、
該オブジェクトが持続空間から仮想空間（仮想メモリＶ
Ｔｉ．）へロードされる間に変化せずに維持され、各ク
ラスＣｉは、該クラスを使用しまたすべての再コンパイ
ルを介するすべてのアプリケーション内のクラス定数の
識別子に関連するオブジェクトを生じる。よって、オブ
ジェクトの構造は、メモリでのアドレス位置とこのオブ
ジェクトを生じるクラスのコードとは独立である。ま
た、継承の管理を可能にするアドレッシング経路は、異
なるテーブルを介してインポーズされる。
システム又は言語における多重継承管理方法を提供す
る。 【構成】オブジェクトＯｂｊ Ｃｉのフォーマットは、
該オブジェクトが持続空間から仮想空間（仮想メモリＶ
Ｔｉ．）へロードされる間に変化せずに維持され、各ク
ラスＣｉは、該クラスを使用しまたすべての再コンパイ
ルを介するすべてのアプリケーション内のクラス定数の
識別子に関連するオブジェクトを生じる。よって、オブ
ジェクトの構造は、メモリでのアドレス位置とこのオブ
ジェクトを生じるクラスのコードとは独立である。ま
た、継承の管理を可能にするアドレッシング経路は、異
なるテーブルを介してインポーズされる。
Description
【０００１】
【産業上の利用分野】本発明は、持続的で共用された
（ｐｅｒｓｉｓｔｅｎｔ ａｎｄ ｓｈａｒｅｄ）オブ
ジェクトを用いるシステム又は言語における多重継承
（ｍｕｌｔｉｐｌｅ ｉｎｈｅｒｉｔａｎｃｅ）を管理
する方法に関する。
（ｐｅｒｓｉｓｔｅｎｔ ａｎｄ ｓｈａｒｅｄ）オブ
ジェクトを用いるシステム又は言語における多重継承
（ｍｕｌｔｉｐｌｅ ｉｎｈｅｒｉｔａｎｃｅ）を管理
する方法に関する。
【０００２】
【従来技術】オブジェクト指向言語又はシステムは、一
般に、オブジェクトの発生と操作とを許容するエンティ
ティ（ｅｎｔｉｔｙ）であるクラスの概念に基づいてい
る。クラスは、一方では、属性（ａｔｔｒｉｂｕｔｅ
ｓ）の定義を介して発生するオブジェクトの構造を定義
し、他方では、方法の定義によってこれらのオブジェク
トの振る舞いを定義する。更に、種々のクラスの間の継
承関係を定義する可能性は、このタイプの言語の本質的
な特性であり、この関係は、多重継承の関係でありるこ
とができ、実際にもそうである。
般に、オブジェクトの発生と操作とを許容するエンティ
ティ（ｅｎｔｉｔｙ）であるクラスの概念に基づいてい
る。クラスは、一方では、属性（ａｔｔｒｉｂｕｔｅ
ｓ）の定義を介して発生するオブジェクトの構造を定義
し、他方では、方法の定義によってこれらのオブジェク
トの振る舞いを定義する。更に、種々のクラスの間の継
承関係を定義する可能性は、このタイプの言語の本質的
な特性であり、この関係は、多重継承の関係でありるこ
とができ、実際にもそうである。
【０００３】多重継承とは、同一のクラスが、複数の他
のクラスからの継承によって定義されることを意味す
る。他のクラスから継承するクラスは、通常、「導かれ
たクラス（ｄｅｒｉｖｅｄ ｃｌａｓｓ）」と呼ばれ、
継承された方のクラス、すなわち被継承クラスは、該導
かれたクラスの「ベース・クラス（ｂａｓｅ ｃｌａｓ
ｓ）」と考えられる。同様に、クラスの概念に関する継
承関係において、２つの成分が現在区別されている。第
１の成分は、構造的（ｓｔｒｕｃｔｕｒａｌ）継承であ
る。すなわち、ある与えられたクラスのオブジェクトの
構造は、このクラスの中で定義された属性と、直接又は
間接に継承された（被継承）クラスの属性の全体のグル
ープとから構成される。第２の成分は行動的（ｂｅｈａ
ｖｉｏｒａｌ）継承である。すなわち、１つのオブジェ
クトの操作を許容する方法は、そのクラス内で定義され
たものと、直接に又は間接に継承されたクラス内で定義
されたすべてのものとである。このような形態に加えら
れるのは、一般に、導かれたクラスに、ベース・クラス
内で定義された方法のコードをオーバーロードする可能
性である。この機能を実行するためには、当業者によっ
て「レイト・バインディング（ｌａｔｅ ｂｉｎｄｉｎ
ｇ）」と呼ばれる、ダイナミック連鎖のメカニズムを必
要とする。
のクラスからの継承によって定義されることを意味す
る。他のクラスから継承するクラスは、通常、「導かれ
たクラス（ｄｅｒｉｖｅｄ ｃｌａｓｓ）」と呼ばれ、
継承された方のクラス、すなわち被継承クラスは、該導
かれたクラスの「ベース・クラス（ｂａｓｅ ｃｌａｓ
ｓ）」と考えられる。同様に、クラスの概念に関する継
承関係において、２つの成分が現在区別されている。第
１の成分は、構造的（ｓｔｒｕｃｔｕｒａｌ）継承であ
る。すなわち、ある与えられたクラスのオブジェクトの
構造は、このクラスの中で定義された属性と、直接又は
間接に継承された（被継承）クラスの属性の全体のグル
ープとから構成される。第２の成分は行動的（ｂｅｈａ
ｖｉｏｒａｌ）継承である。すなわち、１つのオブジェ
クトの操作を許容する方法は、そのクラス内で定義され
たものと、直接に又は間接に継承されたクラス内で定義
されたすべてのものとである。このような形態に加えら
れるのは、一般に、導かれたクラスに、ベース・クラス
内で定義された方法のコードをオーバーロードする可能
性である。この機能を実行するためには、当業者によっ
て「レイト・バインディング（ｌａｔｅ ｂｉｎｄｉｎ
ｇ）」と呼ばれる、ダイナミック連鎖のメカニズムを必
要とする。
【０００４】このようなオブジェクト指向言語、たとえ
ば、Ｃ＋＋言語がコンパイルされる場合には、コンパイ
ラは、メモリにおけるオブジェクトの記憶位置と、属性
のアドレスシングと、関連する方法とを、定義しなけれ
ばならない。オブジェクトの多重継承の管理は、かなり
急速に複雑化し問題を呈するが、非持続的（ｎｏｎ−ｐ
ｅｒｓｉｓｔｅｎｔ）なオブジェクトの場合には、Ｃ＋
＋言語と共に実現される効果的な技法があり、それによ
れば、多重継承によって生じる問題の解消が可能にな
る。この技法に関しては、”Ｔｈｅ Ａｎｎｏｔａｔｅ
ｄ Ｃ＋＋ Ｒｅｆｅｒｅｎｃｅ Ｍａｎｕａｌ”（Ａ
ｄｄｉｓｏｎ−Ｗｅｓｌｅｙ、１９９０年）において、
Ｍ．Ａ．Ｅｌｌｉｓらが説明している。不幸なことに、
この技法は、オブジェクトが、持続的なオブジェクト
（それらのオブジェクトを生じさせたプログラムの実行
が終了したときに生き残るオブジェクト）である場合、
及び共用されるオブジェクト（複数のプログラムが１つ
のオブジェクトに同時にアクセスした場合のオブジェク
ト）である場合に、この技法を適用する必要がある際に
有効でなく、したがって役に立たなくなる。
ば、Ｃ＋＋言語がコンパイルされる場合には、コンパイ
ラは、メモリにおけるオブジェクトの記憶位置と、属性
のアドレスシングと、関連する方法とを、定義しなけれ
ばならない。オブジェクトの多重継承の管理は、かなり
急速に複雑化し問題を呈するが、非持続的（ｎｏｎ−ｐ
ｅｒｓｉｓｔｅｎｔ）なオブジェクトの場合には、Ｃ＋
＋言語と共に実現される効果的な技法があり、それによ
れば、多重継承によって生じる問題の解消が可能にな
る。この技法に関しては、”Ｔｈｅ Ａｎｎｏｔａｔｅ
ｄ Ｃ＋＋ Ｒｅｆｅｒｅｎｃｅ Ｍａｎｕａｌ”（Ａ
ｄｄｉｓｏｎ−Ｗｅｓｌｅｙ、１９９０年）において、
Ｍ．Ａ．Ｅｌｌｉｓらが説明している。不幸なことに、
この技法は、オブジェクトが、持続的なオブジェクト
（それらのオブジェクトを生じさせたプログラムの実行
が終了したときに生き残るオブジェクト）である場合、
及び共用されるオブジェクト（複数のプログラムが１つ
のオブジェクトに同時にアクセスした場合のオブジェク
ト）である場合に、この技法を適用する必要がある際に
有効でなく、したがって役に立たなくなる。
【０００５】
【発明の概要】本発明の目的は、この問題を解決して、
あるシステムにおいて、又は、持続的でかつ共用される
オブジェクトを使用する言語のコード発生器によって容
易に効果的に使用される多重継承の管理方法を提供する
ことである。この目的を達成するために、導入部で述べ
た多重継承の管理のための方法（プロセス）は、オブジ
ェクトのフォーマットがオブジェクトが持続空間から仮
想空間へロードされる間に変化せずに維持され、各クラ
スが該クラスを使用しまたすべての再コンパイルを介す
るすべてのアプリケーション内のクラス定数の識別子に
関連するオブジェクトを生じ、該オブジェクトの構造が
メモリでのアドレス位置とこのオブジェクトを生じるク
ラスのコードとは独立であり、継承の管理を可能にする
ためのアドレッシング（アクセス）経路が異なるテーブ
ルを介して借用される、という特徴を有する。
あるシステムにおいて、又は、持続的でかつ共用される
オブジェクトを使用する言語のコード発生器によって容
易に効果的に使用される多重継承の管理方法を提供する
ことである。この目的を達成するために、導入部で述べ
た多重継承の管理のための方法（プロセス）は、オブジ
ェクトのフォーマットがオブジェクトが持続空間から仮
想空間へロードされる間に変化せずに維持され、各クラ
スが該クラスを使用しまたすべての再コンパイルを介す
るすべてのアプリケーション内のクラス定数の識別子に
関連するオブジェクトを生じ、該オブジェクトの構造が
メモリでのアドレス位置とこのオブジェクトを生じるク
ラスのコードとは独立であり、継承の管理を可能にする
ためのアドレッシング（アクセス）経路が異なるテーブ
ルを介して借用される、という特徴を有する。
【０００６】更に、本発明による多重継承の管理のため
の方法は、メモリへのオブジェクトの記憶に対しては、
各クラスがこのクラスに属するすべてのオブジェクトに
ついて同一であるパート（部分）と関連し、各パートが
２つのサブパートから成り、その第１のサブパートがオ
ブジェクトを生じた実際のクラスの識別子を含み、該識
別子が継承の管理を可能にするアドレッシング経路の入
力点を生じるクラスのテーブルでのインデックスとして
用いられ、第２のサブパートがオブジェクトを生じたク
ラスによって定義された状態を含み、このクラスによっ
て定義された属性の全体がこの状態において再度グルー
プ化されることを特徴としている。このように、本発明
の技術思想によれば、処理のより大きな部分が静的にす
なわちコンパイルの際に行われ、アドレッシング経路
は、実行の時点で適切な方法を呼び出す（ｃａｌｌ）こ
とが確実となるように作られる。この技法によれば、予
備的な操作なしで、この方法をロードされている最中の
オブジェクトにこの方法を再び適用することが可能にな
ることが保証される。オブジェクトの構造はそのメモリ
位置とは独立であり、よって、記憶されようとしている
アドレスとも独立であり、また、そのオブジェクトを生
じたクラスのコードとも独立である。
の方法は、メモリへのオブジェクトの記憶に対しては、
各クラスがこのクラスに属するすべてのオブジェクトに
ついて同一であるパート（部分）と関連し、各パートが
２つのサブパートから成り、その第１のサブパートがオ
ブジェクトを生じた実際のクラスの識別子を含み、該識
別子が継承の管理を可能にするアドレッシング経路の入
力点を生じるクラスのテーブルでのインデックスとして
用いられ、第２のサブパートがオブジェクトを生じたク
ラスによって定義された状態を含み、このクラスによっ
て定義された属性の全体がこの状態において再度グルー
プ化されることを特徴としている。このように、本発明
の技術思想によれば、処理のより大きな部分が静的にす
なわちコンパイルの際に行われ、アドレッシング経路
は、実行の時点で適切な方法を呼び出す（ｃａｌｌ）こ
とが確実となるように作られる。この技法によれば、予
備的な操作なしで、この方法をロードされている最中の
オブジェクトにこの方法を再び適用することが可能にな
ることが保証される。オブジェクトの構造はそのメモリ
位置とは独立であり、よって、記憶されようとしている
アドレスとも独立であり、また、そのオブジェクトを生
じたクラスのコードとも独立である。
【０００７】
【実施例】以下に本発明の実施例を説明するが、この説
明により、いかにして本発明が現実化されるかがより容
易に理解されるであろう。本発明の概念をより理解しや
すくするために、出発点として図１及び図２に示した多
重継承の例について説明するが、まず、多重継承の管理
に伴ういくつかの問題について述べる。特に、この説明
から、あるオブジェクトの属性に対するアドレスの静的
（ｓｔａｔｉｃ）なすなわちコンパイルの時点での割り
振り（ａｌｌｏｃａｔｉｏｎ）を許容するオブジェクト
に対してメモリ位置を定義することが不可能であること
が、明らかになるであろう。同じような結論は、オーバ
ーロードされた方法への呼び出しの検討からも生じるも
のである。
明により、いかにして本発明が現実化されるかがより容
易に理解されるであろう。本発明の概念をより理解しや
すくするために、出発点として図１及び図２に示した多
重継承の例について説明するが、まず、多重継承の管理
に伴ういくつかの問題について述べる。特に、この説明
から、あるオブジェクトの属性に対するアドレスの静的
（ｓｔａｔｉｃ）なすなわちコンパイルの時点での割り
振り（ａｌｌｏｃａｔｉｏｎ）を許容するオブジェクト
に対してメモリ位置を定義することが不可能であること
が、明らかになるであろう。同じような結論は、オーバ
ーロードされた方法への呼び出しの検討からも生じるも
のである。
【０００８】図１（ａ）及び図２（ａ）で示された単純
な例では、４つのクラスＣ１、Ｃ２、Ｃ３、Ｃ４が示さ
れている。クラスＣ２、Ｃ３は、クラスＣ１に対しては
直接継承の関係にある。クラスＣ４は、クラスＣ２、Ｃ
３に対しては直接多重継承であり、クラスＣ１に対して
はクラスＣ２、Ｃ３とを介して間接多重継承の関係にあ
る。各クラスＣｉ（ｉは正の整数）は、状態Ｅｉにおい
て再度グループ化されているそれ自身の属性を定義す
る。したがって、図１（ａ）及び図２（ａ）では、クラ
スＣ１、Ｃ２、Ｃ３、Ｃ４の属性は、それぞれ、状態Ｅ
１、Ｅ２、Ｅ３、Ｅ４内に集められている。この例の各
クラスに関連する方法ｍｉは、そのクラスによって記憶
される方法であって、したがってこの例では、方法ｍ
１、ｍ２、ｍ３、ｍ４はクラスＣ１によって、方法ｍ
１、ｍ５はクラスＣ２によって、方法ｍ２、ｍ６はクラ
スＣ３によって、そして方法ｍ１、ｍ３、ｍ６、ｍ７は
クラスＣ４によって記憶される。
な例では、４つのクラスＣ１、Ｃ２、Ｃ３、Ｃ４が示さ
れている。クラスＣ２、Ｃ３は、クラスＣ１に対しては
直接継承の関係にある。クラスＣ４は、クラスＣ２、Ｃ
３に対しては直接多重継承であり、クラスＣ１に対して
はクラスＣ２、Ｃ３とを介して間接多重継承の関係にあ
る。各クラスＣｉ（ｉは正の整数）は、状態Ｅｉにおい
て再度グループ化されているそれ自身の属性を定義す
る。したがって、図１（ａ）及び図２（ａ）では、クラ
スＣ１、Ｃ２、Ｃ３、Ｃ４の属性は、それぞれ、状態Ｅ
１、Ｅ２、Ｅ３、Ｅ４内に集められている。この例の各
クラスに関連する方法ｍｉは、そのクラスによって記憶
される方法であって、したがってこの例では、方法ｍ
１、ｍ２、ｍ３、ｍ４はクラスＣ１によって、方法ｍ
１、ｍ５はクラスＣ２によって、方法ｍ２、ｍ６はクラ
スＣ３によって、そして方法ｍ１、ｍ３、ｍ６、ｍ７は
クラスＣ４によって記憶される。
【０００９】第１に遭遇する問題点は、状態Ｅｉのアド
レッシングに関係している。実際に、あるオブジェクト
のメモリ位置は、そのオブジェクトを構成する属性が見
いだされるメモリ領域に対応している。したがってこの
メモリ領域は、このオブジェクトが属するクラスのすべ
ての状態Ｅｉを含んでおり、よって、この例では、クラ
スＣ１の１つのオブジェクトがＥ１を含むゾーン内に、
クラスＣ２の１つのオブジェクトがＥ１、Ｅ２を含むゾ
ーン内に、クラスＣ３の１つのオブジェクトがＥ１、Ｅ
３と含むゾーン内に、クラスＣ４の１つのオブジェクト
がＥ１、Ｅ２、Ｅ３、Ｅ４を含むゾーン内に見いだされ
る（ｓｉｔｅｄ）。この場合に、プログラム内のクラス
Ｃ３の変数は、クラスＣ３から１つのオブジェクトを、
そしてクラスＣ４から１つのオブジェクトを指定するこ
とができる。しかし、状態Ｅ３がこの変数を介してアク
セスされる場合には、このオブジェクト内に静的にその
相対アドレスを定義することができないことは明らかで
ある。これを解決する１つの方法は、クラスＣ３のこれ
らのオブジェクト内にも、状態Ｅ２を含むゾーンを予約
しておくことである。ただし、クラスＣ３では用いられ
ない状態Ｅ２、すなわちクラスＣ３からの１つのオブジ
ェクトを、Ｅ１、Ｅ２、Ｅ３を含むゾーンにおいて定義
するものである。しかし、この解決法は、メモリ内にか
なりの空間の損失を生じさせるので効果的ではない。こ
のことは、持続的なオブジェクトの場合には更に効果的
ではなく、これは、この解決法が、デリバティブ・クラ
ス（導かれたクラス）へ何らかの付加を行う時点で存在
しているオブジェクトの再構成を必要とするからであ
る。提案された第１の割り振りは、メモリ利用の観点か
らは好ましいのであるが、状態Ｅｉのアドレスを動的に
計算する必要が生じてしまうことが問題点である。
レッシングに関係している。実際に、あるオブジェクト
のメモリ位置は、そのオブジェクトを構成する属性が見
いだされるメモリ領域に対応している。したがってこの
メモリ領域は、このオブジェクトが属するクラスのすべ
ての状態Ｅｉを含んでおり、よって、この例では、クラ
スＣ１の１つのオブジェクトがＥ１を含むゾーン内に、
クラスＣ２の１つのオブジェクトがＥ１、Ｅ２を含むゾ
ーン内に、クラスＣ３の１つのオブジェクトがＥ１、Ｅ
３と含むゾーン内に、クラスＣ４の１つのオブジェクト
がＥ１、Ｅ２、Ｅ３、Ｅ４を含むゾーン内に見いだされ
る（ｓｉｔｅｄ）。この場合に、プログラム内のクラス
Ｃ３の変数は、クラスＣ３から１つのオブジェクトを、
そしてクラスＣ４から１つのオブジェクトを指定するこ
とができる。しかし、状態Ｅ３がこの変数を介してアク
セスされる場合には、このオブジェクト内に静的にその
相対アドレスを定義することができないことは明らかで
ある。これを解決する１つの方法は、クラスＣ３のこれ
らのオブジェクト内にも、状態Ｅ２を含むゾーンを予約
しておくことである。ただし、クラスＣ３では用いられ
ない状態Ｅ２、すなわちクラスＣ３からの１つのオブジ
ェクトを、Ｅ１、Ｅ２、Ｅ３を含むゾーンにおいて定義
するものである。しかし、この解決法は、メモリ内にか
なりの空間の損失を生じさせるので効果的ではない。こ
のことは、持続的なオブジェクトの場合には更に効果的
ではなく、これは、この解決法が、デリバティブ・クラ
ス（導かれたクラス）へ何らかの付加を行う時点で存在
しているオブジェクトの再構成を必要とするからであ
る。提案された第１の割り振りは、メモリ利用の観点か
らは好ましいのであるが、状態Ｅｉのアドレスを動的に
計算する必要が生じてしまうことが問題点である。
【００１０】第２の問題点は、方法ｍｉの呼び出しに関
係するものである。この方法ｍｉを呼び出すことは、実
際には呼び出されるコードの動的な決定を意味してい
る。よって、この例での方法ｍ１を選択し、この方法ｍ
１をタイプＣ１の変数Ｖによって指定され操作されるオ
ブジェクトに適用すると（”Ｖ→ｍ１”タイプのＣ＋＋
言語の呼び出し）、このオブジェクトが無差別的に（ｉ
ｎｄｉｆｆｅｒｅｎｔｌｙ）クラスＣ１、Ｃ２、Ｃ３又
はＣ４に属することができることは明らかである。実行
の際にだけ知ることができるこの実際のタイプによれ
ば、適用されるべき方法は、このように、同じではな
い。この例は以下のように示すことができる。 C1 *v, *v1; C2 *v2; C3 *v3; C4 *v4; v1 = newC1(); v2 = newC2(); v3=newC3(); v4 = newC4
(); v = v1; v → m1(); /* call to m1 defined in C1 */ v = v2; v → m1(); /* call to m1 defined in C2 */ v = v3; v → m1(); /* call to m1 defined in C3 */ v = v4; v → m1(); /* call to m1 defined in C4 */
係するものである。この方法ｍｉを呼び出すことは、実
際には呼び出されるコードの動的な決定を意味してい
る。よって、この例での方法ｍ１を選択し、この方法ｍ
１をタイプＣ１の変数Ｖによって指定され操作されるオ
ブジェクトに適用すると（”Ｖ→ｍ１”タイプのＣ＋＋
言語の呼び出し）、このオブジェクトが無差別的に（ｉ
ｎｄｉｆｆｅｒｅｎｔｌｙ）クラスＣ１、Ｃ２、Ｃ３又
はＣ４に属することができることは明らかである。実行
の際にだけ知ることができるこの実際のタイプによれ
ば、適用されるべき方法は、このように、同じではな
い。この例は以下のように示すことができる。 C1 *v, *v1; C2 *v2; C3 *v3; C4 *v4; v1 = newC1(); v2 = newC2(); v3=newC3(); v4 = newC4
(); v = v1; v → m1(); /* call to m1 defined in C1 */ v = v2; v → m1(); /* call to m1 defined in C2 */ v = v3; v → m1(); /* call to m1 defined in C3 */ v = v4; v → m1(); /* call to m1 defined in C4 */
【００１１】このように、この例によって明らかにな
り、４つの可能な”ｖ→ｍ１（）;”の呼び出しの中に
３つの異なる実行ケースがある。ただし、コンパイラ
は、この状況をただ１つのケースとして解釈することが
できる。この場合に、Ｃ＋＋言語は、満足のできる解答
を与えることができる。よって、上述の問題の解決のた
めには、Ｃ＋＋言語が、一方では、継承された状態への
アクセスのためにそのオブジェクトのメモリ・アドレス
を保持するポインタを用い、他方では、方法呼び出しの
解決のための「仮想テーブル」と当業者によって呼ばれ
ている、インディレクション（ｉｎｄｉｒｅｃｔｉｏ
ｎ）テーブルを用いる。
り、４つの可能な”ｖ→ｍ１（）;”の呼び出しの中に
３つの異なる実行ケースがある。ただし、コンパイラ
は、この状況をただ１つのケースとして解釈することが
できる。この場合に、Ｃ＋＋言語は、満足のできる解答
を与えることができる。よって、上述の問題の解決のた
めには、Ｃ＋＋言語が、一方では、継承された状態への
アクセスのためにそのオブジェクトのメモリ・アドレス
を保持するポインタを用い、他方では、方法呼び出しの
解決のための「仮想テーブル」と当業者によって呼ばれ
ている、インディレクション（ｉｎｄｉｒｅｃｔｉｏ
ｎ）テーブルを用いる。
【００１２】既に述べたように、この技法は、”Ｔｈｅ
Ａｎｎｏｔａｔｅｄ Ｃ＋＋ Ｒｅｆｅｒｅｎｃｅ
Ｍａｎｕａｌ”（Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ、１９
９０年）において、Ｍ．Ａ．Ｅｌｌｉｓらが明らかにし
ている。図１（ｂ）に関連して説明する例によれば、継
承の管理のための、クラスＣ２のＣ＋＋オブジェクト
（Ｏｂｊ Ｃ２）と、クラスＣ４のオブジェクト（Ｏｂ
ｊ Ｃ４）とのメモリ割り振りを図式化することが可能に
なり、各クラスＣｉが状態Ｅｉと、いくつかはオーバー
ロードしている（図１（ａ）参照）ある数の方法とを定
義する。メモリ割り振りのために、コンパイラが、各ク
ラスＣｉ（Ｃ１、Ｃ２、Ｃ３、Ｃ４）に対して、このク
ラスＣｉに属するすべてのオブジェクトに関して同一で
あるパートＰｉ（Ｐ１、Ｐ２、Ｐ３、Ｐ４）を、クラス
Ｃｉの１つのオブジェクトの直接継承か、またはＣｉか
ら導かれたクラスからの１つのオブジェクトの継承かに
よって、指定する。すべてのパートＰｉは、３つの別個
のサブパートを含んでいる。
Ａｎｎｏｔａｔｅｄ Ｃ＋＋ Ｒｅｆｅｒｅｎｃｅ
Ｍａｎｕａｌ”（Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ、１９
９０年）において、Ｍ．Ａ．Ｅｌｌｉｓらが明らかにし
ている。図１（ｂ）に関連して説明する例によれば、継
承の管理のための、クラスＣ２のＣ＋＋オブジェクト
（Ｏｂｊ Ｃ２）と、クラスＣ４のオブジェクト（Ｏｂ
ｊ Ｃ４）とのメモリ割り振りを図式化することが可能に
なり、各クラスＣｉが状態Ｅｉと、いくつかはオーバー
ロードしている（図１（ａ）参照）ある数の方法とを定
義する。メモリ割り振りのために、コンパイラが、各ク
ラスＣｉ（Ｃ１、Ｃ２、Ｃ３、Ｃ４）に対して、このク
ラスＣｉに属するすべてのオブジェクトに関して同一で
あるパートＰｉ（Ｐ１、Ｐ２、Ｐ３、Ｐ４）を、クラス
Ｃｉの１つのオブジェクトの直接継承か、またはＣｉか
ら導かれたクラスからの１つのオブジェクトの継承かに
よって、指定する。すべてのパートＰｉは、３つの別個
のサブパートを含んでいる。
【００１３】この３つのサブパート中の第１のサブパー
トは、クラスのコードに含まれる仮想テーブル（ＶＴ
２．１、ＶＴ２．２、ＶＴ４．１、ＶＴ４．２、ＶＴ
４．３、ＶＴ４．４）へのポインタに対応し、該クラス
のコードは、クラスＣｉ（Ｃ２、Ｃ４）のオブジェクト
に適用可能な方法（ｍ１、ｍ２、・・・、ｍ７）の任意
のものの呼び出しを管理することを可能にするものであ
る。このフィールドは、すべてのパートについて同一で
あり、”ｖｔｂｌ”プランと呼ばれる。仮想テーブルの
各要素は、２つのフィールドを含み、第１のフィールド
は、Ｃ＋＋方法を記憶するＣ関数へのポインタであり、
第２のフィールドは、このＣ関数の第１のパラメータと
して扱われるオブジェクトのパートへのポインタの計算
のためのオフセットであり、この第１のパラメータは、
Ｃ＋＋方法の本体（ボディ）で用いられる「これ（ｔｈ
ｉｓ）」に対応する。よって、たとえば、クラスＣ２の
１つのオブジェクト（Ｏｂｊ Ｃ２）のクラスＣ１に関
連するパートＰ１の”ｖｔｂｌ”フィールドによって示
される仮想テーブルＶＴ２．１は、それぞれがクラスＣ
１によって記憶される方法ｍ１、ｍ２、ｍ３、ｍ４に関
係する４つの要素を含んでいる。第１の要素の第１のフ
ィールドｍ１ ２は、このケースでは、クラスＣ２に方
法ｍ１を記憶する関数へのポインタであり、第２のフィ
ールドｄ１ ２は、クラスＣ２のパートＰ２へのポイン
タの計算を可能にするオフセットに対応する。同様にし
て、クラスＣ４の１つのオブジェクト（Ｏｂｊ Ｃ４）
のクラスＣ３に関連するパートＰ３の”ｖｔｂｌ”フィ
ールドによって示される仮想テーブルＶＴ４．３は、５
つの要素を有しており、該要素のそれぞれが、クラスＣ
３によって記憶される方法ｍ２、ｍ６か、又は、クラス
Ｃ１から継承されるオーバーロードされた方法ｍ１、ｍ
３、ｍ４か、のどちらかに関係している。第１の要素の
第１のフィールドｍ１ ４は、このケースでは、クラス
Ｃ４に方法ｍ１を記憶する関数へのポインタであり、第
２のフィールドｄ３ ４は、クラスＣ４のオブジェクト
のパートＰ４へのポインタの計算を可能にするオフセッ
トに対応する。第２のサブパートは、Ｃｉがそこから直
接に継承するすべてのクラスＣｊに対するパートＰｊへ
のポインタに対応する。これらのポインタは、”Ｐｊ
ａｄｄｒ”と呼ばれ、＠（Ｐｊ）で示される。たとえ
ば、パートＰ２については、”Ｐ１ ａｄｄｒ”（＠
（Ｐ１））であり、パートＰ４については、”Ｐ２ ａ
ｄｄｒ”（＠（Ｐ２））と”Ｐ３ ａｄｄｒ”（＠（Ｐ
３））とである。第３のサブパートは、クラスＣｉによ
って定義される状態Ｅｉに対応し、このＰｉフィールド
は、”ｓｔ”として呼ばれかつ示される。
トは、クラスのコードに含まれる仮想テーブル（ＶＴ
２．１、ＶＴ２．２、ＶＴ４．１、ＶＴ４．２、ＶＴ
４．３、ＶＴ４．４）へのポインタに対応し、該クラス
のコードは、クラスＣｉ（Ｃ２、Ｃ４）のオブジェクト
に適用可能な方法（ｍ１、ｍ２、・・・、ｍ７）の任意
のものの呼び出しを管理することを可能にするものであ
る。このフィールドは、すべてのパートについて同一で
あり、”ｖｔｂｌ”プランと呼ばれる。仮想テーブルの
各要素は、２つのフィールドを含み、第１のフィールド
は、Ｃ＋＋方法を記憶するＣ関数へのポインタであり、
第２のフィールドは、このＣ関数の第１のパラメータと
して扱われるオブジェクトのパートへのポインタの計算
のためのオフセットであり、この第１のパラメータは、
Ｃ＋＋方法の本体（ボディ）で用いられる「これ（ｔｈ
ｉｓ）」に対応する。よって、たとえば、クラスＣ２の
１つのオブジェクト（Ｏｂｊ Ｃ２）のクラスＣ１に関
連するパートＰ１の”ｖｔｂｌ”フィールドによって示
される仮想テーブルＶＴ２．１は、それぞれがクラスＣ
１によって記憶される方法ｍ１、ｍ２、ｍ３、ｍ４に関
係する４つの要素を含んでいる。第１の要素の第１のフ
ィールドｍ１ ２は、このケースでは、クラスＣ２に方
法ｍ１を記憶する関数へのポインタであり、第２のフィ
ールドｄ１ ２は、クラスＣ２のパートＰ２へのポイン
タの計算を可能にするオフセットに対応する。同様にし
て、クラスＣ４の１つのオブジェクト（Ｏｂｊ Ｃ４）
のクラスＣ３に関連するパートＰ３の”ｖｔｂｌ”フィ
ールドによって示される仮想テーブルＶＴ４．３は、５
つの要素を有しており、該要素のそれぞれが、クラスＣ
３によって記憶される方法ｍ２、ｍ６か、又は、クラス
Ｃ１から継承されるオーバーロードされた方法ｍ１、ｍ
３、ｍ４か、のどちらかに関係している。第１の要素の
第１のフィールドｍ１ ４は、このケースでは、クラス
Ｃ４に方法ｍ１を記憶する関数へのポインタであり、第
２のフィールドｄ３ ４は、クラスＣ４のオブジェクト
のパートＰ４へのポインタの計算を可能にするオフセッ
トに対応する。第２のサブパートは、Ｃｉがそこから直
接に継承するすべてのクラスＣｊに対するパートＰｊへ
のポインタに対応する。これらのポインタは、”Ｐｊ
ａｄｄｒ”と呼ばれ、＠（Ｐｊ）で示される。たとえ
ば、パートＰ２については、”Ｐ１ ａｄｄｒ”（＠
（Ｐ１））であり、パートＰ４については、”Ｐ２ ａ
ｄｄｒ”（＠（Ｐ２））と”Ｐ３ ａｄｄｒ”（＠（Ｐ
３））とである。第３のサブパートは、クラスＣｉによ
って定義される状態Ｅｉに対応し、このＰｉフィールド
は、”ｓｔ”として呼ばれかつ示される。
【００１４】タイプＣｉの変数たとえば”Ｃｉ＊Ｖ”
は、そのオブジェクトの実際のクラスが何を指していて
も常にパートＰｉを指すことを認識しておくことは、更
に重要である。よって、変数”Ｃ２＊Ｖ”（図１
（ｂ））を定義するには、Ｖは、そのオブジェクトの開
始アドレス（パートＰ２の開始アドレス）を指している
変数であるＯｂｊ Ｃ２を指定し、またＶがＯｂｊ Ｃ
４を指定する場合には、変数Ｖが、そのオブジェクトの
中間であるパートＰ２の開始アドレスを指している。Ｃ
＋＋のオブジェクト及びそれらの外部において実現され
るすべてのデータを記述し、仮想継承のセマンティック
ス（ｓｅｍａｎｔｉｃｓ）を管理した後で、これらのデ
ータがどのようにオブジェクトの状態Ｅｉの種々のパー
トへのアクセスを計算するのに用いられるか、又は、方
法ｍｉを呼び出すのに用いられるかの検討が行われる。
次に挙げる例では、オブジェクトＯｂｊ Ｃ２、Ｏｂｊ
Ｃ４が、変数Ｖに含まれているＣ２タイプのポインタ
によって指定されていると、仮定する。
は、そのオブジェクトの実際のクラスが何を指していて
も常にパートＰｉを指すことを認識しておくことは、更
に重要である。よって、変数”Ｃ２＊Ｖ”（図１
（ｂ））を定義するには、Ｖは、そのオブジェクトの開
始アドレス（パートＰ２の開始アドレス）を指している
変数であるＯｂｊ Ｃ２を指定し、またＶがＯｂｊ Ｃ
４を指定する場合には、変数Ｖが、そのオブジェクトの
中間であるパートＰ２の開始アドレスを指している。Ｃ
＋＋のオブジェクト及びそれらの外部において実現され
るすべてのデータを記述し、仮想継承のセマンティック
ス（ｓｅｍａｎｔｉｃｓ）を管理した後で、これらのデ
ータがどのようにオブジェクトの状態Ｅｉの種々のパー
トへのアクセスを計算するのに用いられるか、又は、方
法ｍｉを呼び出すのに用いられるかの検討が行われる。
次に挙げる例では、オブジェクトＯｂｊ Ｃ２、Ｏｂｊ
Ｃ４が、変数Ｖに含まれているＣ２タイプのポインタ
によって指定されていると、仮定する。
【００１５】オブジェクトの状態Ｅｉにアクセスする場
合のコストは、そのオブジェクトへのポインタのタイプ
とアクセスされる状態のパートに応じて変化する。パー
トがポインタのタイプに対応する場合には、このケース
でのアクセスのコストは、単にインディレクションであ
る。これは、オブジェクトＯｂｊ Ｃ２とオブジェクト
Ｏｂｊ Ｃ４とに対して、”Ｖ→ｓｔ”によって翻訳さ
れる状態Ｅ２へのアクセスのケースである。他方で、状
態Ｅ１へのアクセスが望まれる場合には、これは、”Ｖ
→Ｐ１ ａｄｄｒ→ｓｔ”によって表現される。すなわ
ち、このアクセスは、二重のインディレクションのコス
トによるものである。実際に、示されるパートをアクセ
スされる状態のパートから分離する継承レベルの数より
も１だけ多い数のインディレクションがある。たとえ
ば、パートＰ４から状態Ｅ１へのアクセスを得るに
は、”Ｐ４→Ｐ２ ａｄｄｒ→Ｐ１ ａｄｄｒ→ｓｔ”
又は”Ｐ４→Ｐ３ ａｄｄｒ→Ｐ１ ａｄｄｒ→ｓｔ”
である。方法ｍ１を呼び出すには、呼び出される方法が
どのクラスの中に実現されていてもコストは一定であ
る。従前の例（変数Ｖに含まれるタイプＣ２のポインタ
によってアクセスされる、Ｏｂｊ Ｃ２及びＯｂｊ Ｃ
４）に戻ると、Ｃ＋＋での”Ｖ→ｍ２（）”の呼び出し
のためのコードは、オブジェクトＯｂｊ Ｃ２又はオブ
ジェクトＯｂｊ Ｃ４に対してなされる呼び出しと明ら
かに同じである。よって、この特定の例では、呼び出し
は、 "(*(V→vtbl[index(m2)].m)(V+V→vtbl[index(m2)].
d,...)" によって翻訳される。
合のコストは、そのオブジェクトへのポインタのタイプ
とアクセスされる状態のパートに応じて変化する。パー
トがポインタのタイプに対応する場合には、このケース
でのアクセスのコストは、単にインディレクションであ
る。これは、オブジェクトＯｂｊ Ｃ２とオブジェクト
Ｏｂｊ Ｃ４とに対して、”Ｖ→ｓｔ”によって翻訳さ
れる状態Ｅ２へのアクセスのケースである。他方で、状
態Ｅ１へのアクセスが望まれる場合には、これは、”Ｖ
→Ｐ１ ａｄｄｒ→ｓｔ”によって表現される。すなわ
ち、このアクセスは、二重のインディレクションのコス
トによるものである。実際に、示されるパートをアクセ
スされる状態のパートから分離する継承レベルの数より
も１だけ多い数のインディレクションがある。たとえ
ば、パートＰ４から状態Ｅ１へのアクセスを得るに
は、”Ｐ４→Ｐ２ ａｄｄｒ→Ｐ１ ａｄｄｒ→ｓｔ”
又は”Ｐ４→Ｐ３ ａｄｄｒ→Ｐ１ ａｄｄｒ→ｓｔ”
である。方法ｍ１を呼び出すには、呼び出される方法が
どのクラスの中に実現されていてもコストは一定であ
る。従前の例（変数Ｖに含まれるタイプＣ２のポインタ
によってアクセスされる、Ｏｂｊ Ｃ２及びＯｂｊ Ｃ
４）に戻ると、Ｃ＋＋での”Ｖ→ｍ２（）”の呼び出し
のためのコードは、オブジェクトＯｂｊ Ｃ２又はオブ
ジェクトＯｂｊ Ｃ４に対してなされる呼び出しと明ら
かに同じである。よって、この特定の例では、呼び出し
は、 "(*(V→vtbl[index(m2)].m)(V+V→vtbl[index(m2)].
d,...)" によって翻訳される。
【００１６】括弧の中の第１の表現によって、オブジェ
クトに関連する仮想テーブルにおける方法ｍ２の持続的
なコードのアドレスの回復が可能になる。これは、オブ
ジェクトＯｂｊ Ｃ２に対してテーブルＶＴ２．２、ｍ
２ １であり、またオブジェクトＯｂｊ Ｃ４に対して
仮想テーブルＶＴ４．２、ｍ２ ３である。このテーブ
ルのインデックスは、静的に計算される。それは、方法
がその中で可視的である各クラスに対して、異なってい
る。第２の表現によって、呼び出された方法が常にその
上で機能するパートを指定するポインタＶの計算が可能
になる。すなわち、呼び出された方法ｍ２を定義するク
ラスＣｊ（この場合はＣ２）のパートＰｊこの場合はＰ
２へのポインタである。この計算は、呼び出しポインタ
に対するオフセットを回復することによって実行され、
このオフセットは、仮想テーブル内に、呼び出された方
法ｍ２に対応するアドレスに記憶される。すなわち、オ
ブジェクトＯｂｊ Ｃ２に対しては仮想テーブルＶＴ
２．２、ｄ２ １であり、オブジェクトＯｂｊ Ｃ４に
対しては仮想テーブルＶＴ４．２、ｄ２ ３である。
クトに関連する仮想テーブルにおける方法ｍ２の持続的
なコードのアドレスの回復が可能になる。これは、オブ
ジェクトＯｂｊ Ｃ２に対してテーブルＶＴ２．２、ｍ
２ １であり、またオブジェクトＯｂｊ Ｃ４に対して
仮想テーブルＶＴ４．２、ｍ２ ３である。このテーブ
ルのインデックスは、静的に計算される。それは、方法
がその中で可視的である各クラスに対して、異なってい
る。第２の表現によって、呼び出された方法が常にその
上で機能するパートを指定するポインタＶの計算が可能
になる。すなわち、呼び出された方法ｍ２を定義するク
ラスＣｊ（この場合はＣ２）のパートＰｊこの場合はＰ
２へのポインタである。この計算は、呼び出しポインタ
に対するオフセットを回復することによって実行され、
このオフセットは、仮想テーブル内に、呼び出された方
法ｍ２に対応するアドレスに記憶される。すなわち、オ
ブジェクトＯｂｊ Ｃ２に対しては仮想テーブルＶＴ
２．２、ｄ２ １であり、オブジェクトＯｂｊ Ｃ４に
対しては仮想テーブルＶＴ４．２、ｄ２ ３である。
【００１７】主メモリにおいて作業することによってコ
ンパイルされたオブジェクト指向言語においては、この
方法において実現された技法が信頼性を有して効果的で
あることがわかった。他方で、この技法は、持続的で、
実行の際に複数のアプリケーションによって共用される
オブジェクトを操作する言語に応用することを望む場合
には、複数の問題に直面する。よって、本発明が向けら
れているこの新たな場合には、２つの主な困難に遭遇す
るのであるが、第１の困難はクラスのコードに含まれる
仮想テーブルへのすべてのポインタの最初のものに関
し、この技法は、一方で持続性に、他方で共用に関す
る、以下に述べる問題に効果をそうすることができる。
持続性に関しては、あるクラスのコードが変化すること
ができなければならない、というだけであるならば、あ
るクラスのコードが同じアドレスに常にロードされるこ
との保証を求めることは、非現実的である。これを解決
するために、アプリケーションが実行される際にオブジ
ェクトが新たなセッションにロードされるたびに”ｖｔ
ｂｌ”ポインタを変化させることによって、解決するこ
とができる。
ンパイルされたオブジェクト指向言語においては、この
方法において実現された技法が信頼性を有して効果的で
あることがわかった。他方で、この技法は、持続的で、
実行の際に複数のアプリケーションによって共用される
オブジェクトを操作する言語に応用することを望む場合
には、複数の問題に直面する。よって、本発明が向けら
れているこの新たな場合には、２つの主な困難に遭遇す
るのであるが、第１の困難はクラスのコードに含まれる
仮想テーブルへのすべてのポインタの最初のものに関
し、この技法は、一方で持続性に、他方で共用に関す
る、以下に述べる問題に効果をそうすることができる。
持続性に関しては、あるクラスのコードが変化すること
ができなければならない、というだけであるならば、あ
るクラスのコードが同じアドレスに常にロードされるこ
との保証を求めることは、非現実的である。これを解決
するために、アプリケーションが実行される際にオブジ
ェクトが新たなセッションにロードされるたびに”ｖｔ
ｂｌ”ポインタを変化させることによって、解決するこ
とができる。
【００１８】更に、共用に関しては、あるクラスのコー
ドがそれを用いるすべてのアプリケーションにおいて同
一のアドレスに接続されていることを保証することが必
要になるであろう。この場合の解決策は、共用されるラ
イブラリにおけるクラスに対するコードの固定した記憶
から成り、しかし、この技法は、そのコードが正確に規
則的に変化することができなければならないライブラリ
にはうまく応用できないので、真剣に考慮するわけには
いかず、実行の途中でのアプリケーションによるこのラ
イブラリの使用と同時の共用されたライブラリの修正
は、不可能である。やはりこの場合において、第２の困
難に遭遇し、これは、主に持続性に関連し、ベース・ク
ラスのパートＰｊへのポインタに関係する。実際に、あ
るオブジェクトが、あるセッションから別のセッション
にかけて、同じ仮想アドレスに常に結合されていること
を保証できることが本質的である。上述の技法は、「マ
ッッピングされた」と称するタイプの、すなわち、対応
が課せられたＵＮＩＸファイル（ＵＮＩＸシステム・ラ
ボラトリーズの商標）の助けによってのみ、実現するこ
とが可能であるが、これは、このファイルが同じ仮想ア
ドレスにおいて常に見いだされることを保証できる場合
には、非常に蓋然性が低い。オブジェクトのローディン
グの間にこれらのポインタをリフレッシュことから成る
別の技法である第２の解決策もあるが、この第２の解決
策は、更にコストがかかるし実現するには複雑である。
ドがそれを用いるすべてのアプリケーションにおいて同
一のアドレスに接続されていることを保証することが必
要になるであろう。この場合の解決策は、共用されるラ
イブラリにおけるクラスに対するコードの固定した記憶
から成り、しかし、この技法は、そのコードが正確に規
則的に変化することができなければならないライブラリ
にはうまく応用できないので、真剣に考慮するわけには
いかず、実行の途中でのアプリケーションによるこのラ
イブラリの使用と同時の共用されたライブラリの修正
は、不可能である。やはりこの場合において、第２の困
難に遭遇し、これは、主に持続性に関連し、ベース・ク
ラスのパートＰｊへのポインタに関係する。実際に、あ
るオブジェクトが、あるセッションから別のセッション
にかけて、同じ仮想アドレスに常に結合されていること
を保証できることが本質的である。上述の技法は、「マ
ッッピングされた」と称するタイプの、すなわち、対応
が課せられたＵＮＩＸファイル（ＵＮＩＸシステム・ラ
ボラトリーズの商標）の助けによってのみ、実現するこ
とが可能であるが、これは、このファイルが同じ仮想ア
ドレスにおいて常に見いだされることを保証できる場合
には、非常に蓋然性が低い。オブジェクトのローディン
グの間にこれらのポインタをリフレッシュことから成る
別の技法である第２の解決策もあるが、この第２の解決
策は、更にコストがかかるし実現するには複雑である。
【００１９】本発明の概念によれば、持続的でかつ共用
されるオブジェクトを用いるシステム又は言語が使用さ
れる場合には、オブジェクトのフォーマットがオブジェ
クトが持続空間から仮想空間へロードされる間に変化せ
ずに維持され、各クラスは該クラスを使用しまたすべて
の再コンパイルを介するすべてのアプリケーション内の
クラス定数の識別子に関連するオブジェクトを生じ、オ
ブジェクトの構造がメモリでのアドレス位置とこのオブ
ジェクトを生じるクラスのコードとは独立であり、ただ
し、継承の管理を可能にするアドレッシング経路が異な
るテーブルを介して借用されることを特徴とする多重継
承の管理方法が提供される。よって、この特許請求の範
囲に記載されている解決策によれば、持続的なＣ＋＋オ
ブジェクトに対してあるフォーマットが提案され、上述
の後者の問題に典型的な問題への解答を与えることを可
能にする継承管理の技法が提供される。その応用の範囲
は、持続的なオブジェクトを用いるすべての言語と、Ｃ
＋＋言語のもの（仮想継承及び仮想方法）に類似した多
重継承機能を許容するオブジェクト・データに基づく管
理システムとを含んでいる。
されるオブジェクトを用いるシステム又は言語が使用さ
れる場合には、オブジェクトのフォーマットがオブジェ
クトが持続空間から仮想空間へロードされる間に変化せ
ずに維持され、各クラスは該クラスを使用しまたすべて
の再コンパイルを介するすべてのアプリケーション内の
クラス定数の識別子に関連するオブジェクトを生じ、オ
ブジェクトの構造がメモリでのアドレス位置とこのオブ
ジェクトを生じるクラスのコードとは独立であり、ただ
し、継承の管理を可能にするアドレッシング経路が異な
るテーブルを介して借用されることを特徴とする多重継
承の管理方法が提供される。よって、この特許請求の範
囲に記載されている解決策によれば、持続的なＣ＋＋オ
ブジェクトに対してあるフォーマットが提案され、上述
の後者の問題に典型的な問題への解答を与えることを可
能にする継承管理の技法が提供される。その応用の範囲
は、持続的なオブジェクトを用いるすべての言語と、Ｃ
＋＋言語のもの（仮想継承及び仮想方法）に類似した多
重継承機能を許容するオブジェクト・データに基づく管
理システムとを含んでいる。
【００２０】ここでは、このメカニズムに必要なデータ
構造の構築を可能にするアルゴリズムは与えていない
し、この構造を用いてソース・コードをオブジェクト・
コードに翻訳するアルゴリズムも与えていない。これら
のアルゴリズムは、以下で特に図２の説明の後に示す翻
訳の例を参照することによって、当業者が明らかである
と考えるであろう共通の特徴は有してはいるものの、実
際には、この技法を利用する言語のそれぞれに特有のも
のである。この提案されたオブジェクト・フォーマット
の直接的な効果は、このフォーマットが持続空間及び仮
想空間において同一に保たれ、フォーマットの翻訳が、
たとえばハードディスクなどの持続空間からたとえば主
メモリなどの仮想空間へのオブジェクトのローディング
の間に、不要であることである。本発明によれば、すべ
ての再コンパイルを介するものとそのクラスを用いるす
べてのオブジェクトとに対するクラス定数の識別子が、
持続的なオブジェクトを生じる各クラスに指定されてい
るという最小限の仮定がなされる。この最小限の仮定
は、持続的で共用されるオブジェクトの場合の本発明の
実現には不可欠である。クラスの識別子は、好ましく
は、整数である。よって、クラスＣｉに関して言えば、
ｉがこのクラスの識別子である。
構造の構築を可能にするアルゴリズムは与えていない
し、この構造を用いてソース・コードをオブジェクト・
コードに翻訳するアルゴリズムも与えていない。これら
のアルゴリズムは、以下で特に図２の説明の後に示す翻
訳の例を参照することによって、当業者が明らかである
と考えるであろう共通の特徴は有してはいるものの、実
際には、この技法を利用する言語のそれぞれに特有のも
のである。この提案されたオブジェクト・フォーマット
の直接的な効果は、このフォーマットが持続空間及び仮
想空間において同一に保たれ、フォーマットの翻訳が、
たとえばハードディスクなどの持続空間からたとえば主
メモリなどの仮想空間へのオブジェクトのローディング
の間に、不要であることである。本発明によれば、すべ
ての再コンパイルを介するものとそのクラスを用いるす
べてのオブジェクトとに対するクラス定数の識別子が、
持続的なオブジェクトを生じる各クラスに指定されてい
るという最小限の仮定がなされる。この最小限の仮定
は、持続的で共用されるオブジェクトの場合の本発明の
実現には不可欠である。クラスの識別子は、好ましく
は、整数である。よって、クラスＣｉに関して言えば、
ｉがこのクラスの識別子である。
【００２１】同じことが、メモリ内へのオブジェクトの
記憶に関しても言える。各クラスには、このクラスに属
するすべてのオブジェクトに対して同一であるパート
（部分）が伴っており、各パートは２つのサブパートか
ら成り、第１のサブパートはオブジェクトを生じた実際
のクラスの識別子を含み、該識別子は継承の管理を可能
にする経路の入力点を生じるクラスのテーブルでのイン
デックスとして用いられ、第２のサブパートはオブジェ
クトを生じたクラスによって定義された状態を含み、該
クラスによって定義された属性の全体がこの状態におい
て再度グループ化される。このようにして、メモリ内へ
のオブジェクトの記憶に関しては、コンパイラが、各ク
ラスに、このクラスに属するすべてのオブジェクトに対
して同一であるパートＰｉを関連付ける。図２（ｂ）で
は、たとえば、パートＰ１は、クラスＣ２のオブジェク
ト（Ｏｂｊ Ｃ２）又はクラスＣ４のオブジェクト（Ｏ
ｂｊ Ｃ４）に関する場合のどちらでも同じである。図
２（ｂ）では、各パートＰｉは、従来技術の説明に関す
る例のように３つ（図１（ｂ）参照）ではなく、２つの
サブパートを含んでいるように見える。
記憶に関しても言える。各クラスには、このクラスに属
するすべてのオブジェクトに対して同一であるパート
（部分）が伴っており、各パートは２つのサブパートか
ら成り、第１のサブパートはオブジェクトを生じた実際
のクラスの識別子を含み、該識別子は継承の管理を可能
にする経路の入力点を生じるクラスのテーブルでのイン
デックスとして用いられ、第２のサブパートはオブジェ
クトを生じたクラスによって定義された状態を含み、該
クラスによって定義された属性の全体がこの状態におい
て再度グループ化される。このようにして、メモリ内へ
のオブジェクトの記憶に関しては、コンパイラが、各ク
ラスに、このクラスに属するすべてのオブジェクトに対
して同一であるパートＰｉを関連付ける。図２（ｂ）で
は、たとえば、パートＰ１は、クラスＣ２のオブジェク
ト（Ｏｂｊ Ｃ２）又はクラスＣ４のオブジェクト（Ｏ
ｂｊ Ｃ４）に関する場合のどちらでも同じである。図
２（ｂ）では、各パートＰｉは、従来技術の説明に関す
る例のように３つ（図１（ｂ）参照）ではなく、２つの
サブパートを含んでいるように見える。
【００２２】第１のサブパートは、オブジェクトの実際
のクラスすなわちそのオブジェクトを生じたクラスの識
別子に対応する。この識別子は、クラスのテーブルにお
けるインデックスとして用いられ、図面ではタブクラス
（Ｔａｂｃｌａｓｓ）と称されており、継承の管理を可
能にする経路の入力点を生じる。複数のパートＰｉから
成るオブジェクトに対して、この識別子は、よって、各
パートＰｉにおいて複製される。オブジェクトＯｂｊ
Ｃ２に対する識別子は、したがって、パートＰ１、Ｐ２
に対して同一であり、オブジェクトＯｂｊ Ｃ４に対す
る識別子は、したがって、パートＰ１、Ｐ２、Ｐ３、Ｐ
４に対して同一である。そのパートの任意の１つによっ
てオブジェクトを参照することができることが望まれる
ので、この選択は必要であり、そのオブジェクトを参照
する変数のタイプにしたがって、タイプＣｉの変数は常
にパートＰｉを指している。このＰｉフィールドは、”
ｃｉｄ”と呼ばれる。第２のサブパートは、クラスＣｉ
によって定義された状態Ｅｉに対応する。このフィール
ドは、図１（ｂ）でのように”ｓｔ”と呼ばれる。仮想
テーブルへのポインタに等しいデータのみが要求され
て、あるクラスの直接のベース・クラスのパートへのポ
インタに対するデータは必要ではないので、オブジェク
トにおけるメモリ空間の増加という利点を有すること
が、以上によって理解できる。従来技術の解決策に関連
して示したのと同じ例を用いて、従来技術において実現
されていた管理プロセスに関する態様を、Ｃ＋＋を用い
た態様で、インディレクションのテーブル又は仮想テー
ブルからの多重継承を、いかにして管理するかを説明す
る。
のクラスすなわちそのオブジェクトを生じたクラスの識
別子に対応する。この識別子は、クラスのテーブルにお
けるインデックスとして用いられ、図面ではタブクラス
（Ｔａｂｃｌａｓｓ）と称されており、継承の管理を可
能にする経路の入力点を生じる。複数のパートＰｉから
成るオブジェクトに対して、この識別子は、よって、各
パートＰｉにおいて複製される。オブジェクトＯｂｊ
Ｃ２に対する識別子は、したがって、パートＰ１、Ｐ２
に対して同一であり、オブジェクトＯｂｊ Ｃ４に対す
る識別子は、したがって、パートＰ１、Ｐ２、Ｐ３、Ｐ
４に対して同一である。そのパートの任意の１つによっ
てオブジェクトを参照することができることが望まれる
ので、この選択は必要であり、そのオブジェクトを参照
する変数のタイプにしたがって、タイプＣｉの変数は常
にパートＰｉを指している。このＰｉフィールドは、”
ｃｉｄ”と呼ばれる。第２のサブパートは、クラスＣｉ
によって定義された状態Ｅｉに対応する。このフィール
ドは、図１（ｂ）でのように”ｓｔ”と呼ばれる。仮想
テーブルへのポインタに等しいデータのみが要求され
て、あるクラスの直接のベース・クラスのパートへのポ
インタに対するデータは必要ではないので、オブジェク
トにおけるメモリ空間の増加という利点を有すること
が、以上によって理解できる。従来技術の解決策に関連
して示したのと同じ例を用いて、従来技術において実現
されていた管理プロセスに関する態様を、Ｃ＋＋を用い
た態様で、インディレクションのテーブル又は仮想テー
ブルからの多重継承を、いかにして管理するかを説明す
る。
【００２３】既に述べた例と同様に、変数ＶはタイプＣ
ｊのオブジェクトＯｂｊ Ｃｊを指定するタイプＣｉで
あり、ＣｊはクラスＣｉ自体かＣｉから導かれたクラス
かのどちらかである、と仮定する。変数のタイプＣｉ
が、実際にオブジェクトＯｂｊ Ｃｊに応用可能な方法の
グループの中のサブグループであるオブジェクトに応用
可能である方法のグループを決定し、この後者のグルー
プは、オブジェクトの実際のタイプであるＣｊによって
定義される。各ベース・クラスＣｊが、これらのベース
・クラスに対応するパートと実際のＣｊタイプのオブジ
ェクトとに同時に応用可能な方法へのアクセス・マスク
を定義する。これが、図２（ｂ）に示されており、そこ
では、タブクラスと呼ばれるテーブルが、各クラスＣｊ
に対するＴａｂｍａｓｋ Ｃｊと呼ばれるマスクのテー
ブルにポインタを供給し、異なるマスクを含むテーブル
でのＴａｂｍａｓｋ Ｃ２、Ｔａｂｍａｓｋ Ｃ４が、
ＣｊタイプのオブジェクトであるＯｂｊ Ｃ２又はＯｂ
ｊ Ｃ４が操作されることを可能にする。実際には、マ
スクによって、与えられたクラスのオブジェクトがそれ
を介して操作され得る変数の異なるタイプを記述するこ
とが可能になる。
ｊのオブジェクトＯｂｊ Ｃｊを指定するタイプＣｉで
あり、ＣｊはクラスＣｉ自体かＣｉから導かれたクラス
かのどちらかである、と仮定する。変数のタイプＣｉ
が、実際にオブジェクトＯｂｊ Ｃｊに応用可能な方法の
グループの中のサブグループであるオブジェクトに応用
可能である方法のグループを決定し、この後者のグルー
プは、オブジェクトの実際のタイプであるＣｊによって
定義される。各ベース・クラスＣｊが、これらのベース
・クラスに対応するパートと実際のＣｊタイプのオブジ
ェクトとに同時に応用可能な方法へのアクセス・マスク
を定義する。これが、図２（ｂ）に示されており、そこ
では、タブクラスと呼ばれるテーブルが、各クラスＣｊ
に対するＴａｂｍａｓｋ Ｃｊと呼ばれるマスクのテー
ブルにポインタを供給し、異なるマスクを含むテーブル
でのＴａｂｍａｓｋ Ｃ２、Ｔａｂｍａｓｋ Ｃ４が、
ＣｊタイプのオブジェクトであるＯｂｊ Ｃ２又はＯｂ
ｊ Ｃ４が操作されることを可能にする。実際には、マ
スクによって、与えられたクラスのオブジェクトがそれ
を介して操作され得る変数の異なるタイプを記述するこ
とが可能になる。
【００２４】本発明によれば、マスク・テーブルは、継
承されたクラスに前記オブジェクトを生じたクラスであ
る１つを加えた数のマスクを含み、各マスク（テーブル
の各ライン）は３つのフィールドを含んでいる。第１の
フィールドは、”ｆｄｅｂ”と呼ばれオフセットｄｄ
１に対応し（Ｔａｂｍａｓｋ Ｃ２に対してｄｄ １か
らｄｄ ２であり、Ｔａｂｍａｓｋ Ｃ４に対してｄｄ
１からｄｄ ４）、これによって、前記のオブジェク
トの最初のアドレスへのポインタからパートＰｉへのポ
インタ、及びその逆の計算を許容する。第２のフィール
ドは、”ｔａｂｄｅｂ”と呼ばれてオフセット・テーブ
ルへのポインタに対応し、よって、Ｔａｂｍａｓｋ Ｃ
２に対するオフセット・テーブルＳＴ２．２（オフセッ
トｄ２ １）、又は、Ｔａｂｍａｓｋ Ｃ４に対するオフ
セット・テーブルＳＴ４．２（オフセットｄ２ １）、
オフセット・テーブルＳＴ４．３（オフセットｄ３
１）、オフセット・テーブルＳＴ４．４（オフセットｄ
４ １、ｄ４ ２、ｄ４ ３）に対応する。各テーブルは
実際には、可能なオフセット、又は、クラスの変数から
のオブジェクトの操作と、このクラスからそれが継承す
る１つ又は複数のクラスへの操作とを可能にするオフセ
ットを含んでいる。最後に、第３のフィールドは、”ｖ
ｔｂｌ”と呼ばれ仮想テーブル（Ｔａｂｍａｓｋ Ｃ２
に対しては仮想テーブルＶＴ２．１及びＶＴ２．２であ
り、Ｔａｂｍａｓｋ Ｃ４に対しては仮想テーブルＶＴ
４．１、ＶＴ４．２、ＶＴ４．３、ＶＴ４．４である）
へのポインタに対応するが、その構造は、Ｃ＋＋と共に
用いられ、図１（ｂ）と共に説明した技法と同様であ
る。
承されたクラスに前記オブジェクトを生じたクラスであ
る１つを加えた数のマスクを含み、各マスク（テーブル
の各ライン）は３つのフィールドを含んでいる。第１の
フィールドは、”ｆｄｅｂ”と呼ばれオフセットｄｄ
１に対応し（Ｔａｂｍａｓｋ Ｃ２に対してｄｄ １か
らｄｄ ２であり、Ｔａｂｍａｓｋ Ｃ４に対してｄｄ
１からｄｄ ４）、これによって、前記のオブジェク
トの最初のアドレスへのポインタからパートＰｉへのポ
インタ、及びその逆の計算を許容する。第２のフィール
ドは、”ｔａｂｄｅｂ”と呼ばれてオフセット・テーブ
ルへのポインタに対応し、よって、Ｔａｂｍａｓｋ Ｃ
２に対するオフセット・テーブルＳＴ２．２（オフセッ
トｄ２ １）、又は、Ｔａｂｍａｓｋ Ｃ４に対するオフ
セット・テーブルＳＴ４．２（オフセットｄ２ １）、
オフセット・テーブルＳＴ４．３（オフセットｄ３
１）、オフセット・テーブルＳＴ４．４（オフセットｄ
４ １、ｄ４ ２、ｄ４ ３）に対応する。各テーブルは
実際には、可能なオフセット、又は、クラスの変数から
のオブジェクトの操作と、このクラスからそれが継承す
る１つ又は複数のクラスへの操作とを可能にするオフセ
ットを含んでいる。最後に、第３のフィールドは、”ｖ
ｔｂｌ”と呼ばれ仮想テーブル（Ｔａｂｍａｓｋ Ｃ２
に対しては仮想テーブルＶＴ２．１及びＶＴ２．２であ
り、Ｔａｂｍａｓｋ Ｃ４に対しては仮想テーブルＶＴ
４．１、ＶＴ４．２、ＶＴ４．３、ＶＴ４．４である）
へのポインタに対応するが、その構造は、Ｃ＋＋と共に
用いられ、図１（ｂ）と共に説明した技法と同様であ
る。
【００２５】”ｆｄｅｂ”フィールドに対応するオフセ
ットは、オブジェクトと二次メモリとの間の明確なロー
ディング又は非ローディングの間に有用である。実際、
ローディングの間には、開始アドレスであり、これは一
般的に返送される。同様に、非ローディングに関して
も、ポインタをオブジェクトの開始アドレスの位置にお
くことが必要になる。図２（ｂ）に示した構造を介して
継承の実現を一般化して研究するために、実際のタイプ
Ｃｊのオブジェクトを指定する”Ｃｉ”＊Ｖ”によって
定義される変数Ｖからのオブジェクトの操作が仮定され
る。よって、オブジェクトのローディングのためには、 "V=load object (address disk)" によって表現される明確なローディングの指示の存在を
仮定する。なお、”ｌｏａｄ ｏｂｊｅｃｔ”とは、ハ
ードディスクから主メモリへオブジェクトをローディン
グし、そのディスク・アドレスからスタートして次いで
その仮想アドレスに戻ることも含むが、この動作を次の
Ｃ言語の表現に変換することが必要である。すなわち、 (V=load object(address disk), V=V+Tabclass[V→cid]
[i].fdeb);
ットは、オブジェクトと二次メモリとの間の明確なロー
ディング又は非ローディングの間に有用である。実際、
ローディングの間には、開始アドレスであり、これは一
般的に返送される。同様に、非ローディングに関して
も、ポインタをオブジェクトの開始アドレスの位置にお
くことが必要になる。図２（ｂ）に示した構造を介して
継承の実現を一般化して研究するために、実際のタイプ
Ｃｊのオブジェクトを指定する”Ｃｉ”＊Ｖ”によって
定義される変数Ｖからのオブジェクトの操作が仮定され
る。よって、オブジェクトのローディングのためには、 "V=load object (address disk)" によって表現される明確なローディングの指示の存在を
仮定する。なお、”ｌｏａｄ ｏｂｊｅｃｔ”とは、ハ
ードディスクから主メモリへオブジェクトをローディン
グし、そのディスク・アドレスからスタートして次いで
その仮想アドレスに戻ることも含むが、この動作を次の
Ｃ言語の表現に変換することが必要である。すなわち、 (V=load object(address disk), V=V+Tabclass[V→cid]
[i].fdeb);
【００２６】同様にして、オブジェクトの非ローディン
グのためには、 "unload+object(V,address disk,size)" の形式の明確な非ローディングの指示の存在を仮定する
が、これにより、主メモリ内の変数Ｖによって示される
アドレス”ａｄｄｒｅｓｓ ｄｉｓｋ”においてディス
ク上でオブジェクトを非ローディングする。また、”ｓ
ｉｚｅ”はオブジェクトのサイズを意味し、この指示を
次のように変換することが必要である。すなわち、 unload object(V-Tabclass[V→cid][i]. fdeb,address
disk, size);
グのためには、 "unload+object(V,address disk,size)" の形式の明確な非ローディングの指示の存在を仮定する
が、これにより、主メモリ内の変数Ｖによって示される
アドレス”ａｄｄｒｅｓｓ ｄｉｓｋ”においてディス
ク上でオブジェクトを非ローディングする。また、”ｓ
ｉｚｅ”はオブジェクトのサイズを意味し、この指示を
次のように変換することが必要である。すなわち、 unload object(V-Tabclass[V→cid][i]. fdeb,address
disk, size);
【００２７】オブジェクトのサイズは、必要であれば、
たとえば”Ｓｉｚｅ−ｃｌａｓｓ”と命名された補助的
なテーブル内に容易に記憶することができ、このサイズ
へのアクセスは、”Ｓｉｚｅ−ｃｌａｓｓ［Ｖ→ｃｉ
ｄ］”介してなされる。現在では、あるオブジェクトの
状態Ｅｉへのアクセスに関しては、図面から２つのケー
スがわかる。第１の場合は、状態Ｅｉがアクセスされ変
数が常にパートＰｉを指していることがわかっている場
合であるが、このときアクセスは、単純に”Ｖ→ｓｔ”
により達成される。この場合のコストは、上述のＣ＋＋
の技法の場合と同じである。第２のケースは、状態Ｅｊ
がアクセスされクラスＣｊがＣｉの直接又は間接のベー
ス・クラスである場合であるが、この場合には、アクセ
スは、 (V+Tabclass[V→cid][i].tabdep[index(j)])→st" によって、達成される。
たとえば”Ｓｉｚｅ−ｃｌａｓｓ”と命名された補助的
なテーブル内に容易に記憶することができ、このサイズ
へのアクセスは、”Ｓｉｚｅ−ｃｌａｓｓ［Ｖ→ｃｉ
ｄ］”介してなされる。現在では、あるオブジェクトの
状態Ｅｉへのアクセスに関しては、図面から２つのケー
スがわかる。第１の場合は、状態Ｅｉがアクセスされ変
数が常にパートＰｉを指していることがわかっている場
合であるが、このときアクセスは、単純に”Ｖ→ｓｔ”
により達成される。この場合のコストは、上述のＣ＋＋
の技法の場合と同じである。第２のケースは、状態Ｅｊ
がアクセスされクラスＣｊがＣｉの直接又は間接のベー
ス・クラスである場合であるが、この場合には、アクセ
スは、 (V+Tabclass[V→cid][i].tabdep[index(j)])→st" によって、達成される。
【００２８】この指示においては、ｉｎｄｅｘ（ｊ）
は、コード発生器によって静的に決定されたＣｉのベー
ス・クラスのテーブルにおけるインデックスであり、こ
のインデックスは、与えられたクラスに関連するすべて
のマスクに対して同一である。オフセット・テーブル
（ＳＴ２．２、ＳＴ４．２、ＳＴ４．３、ＳＴ４．４）
の入り口は、パートＰｉのアドレスから開始するパート
Ｐｊのアドレスの計算を可能にするオフセットを提供す
る。第１の場合に対しては、コストは、約３回のインデ
ィレクションと３回の算術操作とであり、２つの加算と
１つの乗算である。この場合のコストは、したがって、
Ｃ＋＋の技法の場合の、２回のインディレクションと３
回の操作よりも大きい。他方で、継承の階層に関わりな
く、このコストは一定であり、Ｃ＋＋技法の場合の各レ
ベルに、１回のインディレクションを加えることが必要
である。方法ｍｉを呼び出すことに関しては、後者が同
様に行われ、その際のコストは、Ｃ＋＋の技法のように
一定である。
は、コード発生器によって静的に決定されたＣｉのベー
ス・クラスのテーブルにおけるインデックスであり、こ
のインデックスは、与えられたクラスに関連するすべて
のマスクに対して同一である。オフセット・テーブル
（ＳＴ２．２、ＳＴ４．２、ＳＴ４．３、ＳＴ４．４）
の入り口は、パートＰｉのアドレスから開始するパート
Ｐｊのアドレスの計算を可能にするオフセットを提供す
る。第１の場合に対しては、コストは、約３回のインデ
ィレクションと３回の算術操作とであり、２つの加算と
１つの乗算である。この場合のコストは、したがって、
Ｃ＋＋の技法の場合の、２回のインディレクションと３
回の操作よりも大きい。他方で、継承の階層に関わりな
く、このコストは一定であり、Ｃ＋＋技法の場合の各レ
ベルに、１回のインディレクションを加えることが必要
である。方法ｍｉを呼び出すことに関しては、後者が同
様に行われ、その際のコストは、Ｃ＋＋の技法のように
一定である。
【００２９】よって、この方法ｍｉは、 "(*(Tabclass[V→cid][i].vtbl[index(mi).m)) (V+Tabclass[V→cid][i].vtbl[index(mi).d..." 括弧の中の第１の表現によって、方法ｍｉに対応する呼
び出されるべき関数を計算することが可能になり、”ｉ
ｎｄｅｘ（ｍｉ）”は、各クラスに対して、それに応用
可能な方法を含む仮想テーブルを関連させるコード発生
器によって、静的に定義される。第２の表現によって、
パートＰｉのアドレスが、インデックス”ｉｎｄｅｘ
（ｍｉ）”での仮想テーブルにおいて定義されたオフセ
ットを用いることによって、関数の第１のパラメータと
して扱われることが可能になり、この仮想テーブルから
の出力は、一方では、対応する方法を記憶する関数への
ポインタを、他方では、そのオフセットを効果的に含ん
でいる。この仮想テーブルは、導かれたクラスにおいて
用いられるすべてのマスクについて同じ構造を有してい
る。しかし、オフセットと入力とに関連する関数は、マ
スクごとに異なることがある。これは、方法を導かれた
クラスにおいて再度定義できるからである。たとえば、
方法ｍ６を記憶する関数ｍ６ ４は、オフセットｄ３
４（仮想テーブルＶＴ４．３）かオフセットｄ４ ４
（仮想テーブルＶＴ４．４）かのどちらかに関連するこ
とができる。
び出されるべき関数を計算することが可能になり、”ｉ
ｎｄｅｘ（ｍｉ）”は、各クラスに対して、それに応用
可能な方法を含む仮想テーブルを関連させるコード発生
器によって、静的に定義される。第２の表現によって、
パートＰｉのアドレスが、インデックス”ｉｎｄｅｘ
（ｍｉ）”での仮想テーブルにおいて定義されたオフセ
ットを用いることによって、関数の第１のパラメータと
して扱われることが可能になり、この仮想テーブルから
の出力は、一方では、対応する方法を記憶する関数への
ポインタを、他方では、そのオフセットを効果的に含ん
でいる。この仮想テーブルは、導かれたクラスにおいて
用いられるすべてのマスクについて同じ構造を有してい
る。しかし、オフセットと入力とに関連する関数は、マ
スクごとに異なることがある。これは、方法を導かれた
クラスにおいて再度定義できるからである。たとえば、
方法ｍ６を記憶する関数ｍ６ ４は、オフセットｄ３
４（仮想テーブルＶＴ４．３）かオフセットｄ４ ４
（仮想テーブルＶＴ４．４）かのどちらかに関連するこ
とができる。
【００３０】ここまでの所、翻訳の例は、提案された解
決策をより良く理解させるためのものであった。この翻
訳の例は、Ｃ＋＋言語で定義されており、それにより、
多重継承リンクを導入する３つのクラスが実現されてい
る。 class Person { public: char Name[40] char FirstName[30]; long BirthDate; virtual short Age(); }; class Taxable { protected: double TaxableIncome; public: virtual void AffectTaxableIncome(); virtual double CalculTax(); }; class Salary: public virtual Person, public virtua
l Taxable { public: double GrossMonthlySalary; virtual void AffectTaxableIncome(); virtual double CalculTax(); };
決策をより良く理解させるためのものであった。この翻
訳の例は、Ｃ＋＋言語で定義されており、それにより、
多重継承リンクを導入する３つのクラスが実現されてい
る。 class Person { public: char Name[40] char FirstName[30]; long BirthDate; virtual short Age(); }; class Taxable { protected: double TaxableIncome; public: virtual void AffectTaxableIncome(); virtual double CalculTax(); }; class Salary: public virtual Person, public virtua
l Taxable { public: double GrossMonthlySalary; virtual void AffectTaxableIncome(); virtual double CalculTax(); };
【００３１】上で提案されたメカニズムを実現する、こ
の例のＣ言語への翻訳は、次の通りである。 .General data linked to the example: typedef int (*T_meth)(char *obj); typedef struct { T_meth m; long d; } s_vtbl; typedef struct { long cid; long st; } s_Part; typedef struct { long fdeb; long *tabdep; s_vtbl *vtbl; } s_tabmask; s_tabmask *TabClass[]= { Tabmask_Person, Tabmask_Taxable, Tabmask_Salary }; long SizeClass[]= { sizeof(Person), sizeof(Taxable), sizeof(Salary) }; .Data relative to the class Person #define CID_PERSON(long)0) typedef struct { long cid; struct { char Name [40]; char FirstName [30]; long BirthDate; } st; } s_PPersonｔｙｐｅｄｅｆ ｓｔｒｕｃｔ ｛ s_PPerson PPerson; } Person; s_tabmask Tabmask_Person[]= { {0, NULL, vtbl_Person_Person} }; #define INDEX_PERSON_AGE 0 s_vtbl vtbl_Person_Person[]= { {(T_meth)Person_Age,0} }. .Data relative to the Taxable class #define CID_TAXABLE ((long)1) typedef struct { long cid; struct { double TaxableIncome; } st; } s_PTaxable; typedef struct { s_PTaxable PTaxable; } Taxable; s_tabmask Tabmask_Taxable[]= { {0, NULL, NULL}; {0, NULL, vtbl_Taxable_Taxable} }; #define INDEX_TAXABLE_AFFECTINCOMETAX 0 #define INDEX_TAXABLE_CALCULTAX 1 s_vtbl vtbl_Taxable_Taxable[]= { {(T_meth)Taxable_AffectIncomeTax,0} {(T_meth)Taxable_CalculTax,0} }; .Data relative to the Salary class #define CID_SALARY ((long)2) typedef struct { long cid; struct { double GrossMonthlySalary; } st; } s_PSalary; typedef struct { s_PSalary PSalary; s_PPerson PPerson; s_PTaxable PTaxable; } Salary; s_tabmask Tabmask_Salary[]= { {sizeof(s_PSalary), NULL, vtbl Salary Person], {sizeof(s_PSalary) + sizeof(s_PPerson), NULL, vtbl_Salary_Taxable, {0, tabdep_Salary_Salary, vtbl_Salary_Salary} }; #define INDEX_SALARY AGE ((long)0) #define INDEX_SALARY_AFFECTINCOMETAX ((long) 1) #define INDEX_SALARY_CALCULTAX((long)2) s_vtbl vtbl_Salary_Person[]= { {(T_meth)Person_Age,0) }; s_vtbl vtbl_Salary_Taxable[]= { {T_meth)Salary_AffectIncomTax, -sizeof (s_PPerso
n) sizeof (s_PSalary)}, {T_meth)Salary_CalculTax, -sizeof(s_PPerson) sizeof (s_PSalary)} }; s_vtbl vtbl_Salary_Salary[]= { {(T_meth)Person_Age, sizeof(s_PSalary)} {(T_meth)Salary_AffectIncomeTax,0}, {(T_meth)salary_CalculTax,0} };
の例のＣ言語への翻訳は、次の通りである。 .General data linked to the example: typedef int (*T_meth)(char *obj); typedef struct { T_meth m; long d; } s_vtbl; typedef struct { long cid; long st; } s_Part; typedef struct { long fdeb; long *tabdep; s_vtbl *vtbl; } s_tabmask; s_tabmask *TabClass[]= { Tabmask_Person, Tabmask_Taxable, Tabmask_Salary }; long SizeClass[]= { sizeof(Person), sizeof(Taxable), sizeof(Salary) }; .Data relative to the class Person #define CID_PERSON(long)0) typedef struct { long cid; struct { char Name [40]; char FirstName [30]; long BirthDate; } st; } s_PPersonｔｙｐｅｄｅｆ ｓｔｒｕｃｔ ｛ s_PPerson PPerson; } Person; s_tabmask Tabmask_Person[]= { {0, NULL, vtbl_Person_Person} }; #define INDEX_PERSON_AGE 0 s_vtbl vtbl_Person_Person[]= { {(T_meth)Person_Age,0} }. .Data relative to the Taxable class #define CID_TAXABLE ((long)1) typedef struct { long cid; struct { double TaxableIncome; } st; } s_PTaxable; typedef struct { s_PTaxable PTaxable; } Taxable; s_tabmask Tabmask_Taxable[]= { {0, NULL, NULL}; {0, NULL, vtbl_Taxable_Taxable} }; #define INDEX_TAXABLE_AFFECTINCOMETAX 0 #define INDEX_TAXABLE_CALCULTAX 1 s_vtbl vtbl_Taxable_Taxable[]= { {(T_meth)Taxable_AffectIncomeTax,0} {(T_meth)Taxable_CalculTax,0} }; .Data relative to the Salary class #define CID_SALARY ((long)2) typedef struct { long cid; struct { double GrossMonthlySalary; } st; } s_PSalary; typedef struct { s_PSalary PSalary; s_PPerson PPerson; s_PTaxable PTaxable; } Salary; s_tabmask Tabmask_Salary[]= { {sizeof(s_PSalary), NULL, vtbl Salary Person], {sizeof(s_PSalary) + sizeof(s_PPerson), NULL, vtbl_Salary_Taxable, {0, tabdep_Salary_Salary, vtbl_Salary_Salary} }; #define INDEX_SALARY AGE ((long)0) #define INDEX_SALARY_AFFECTINCOMETAX ((long) 1) #define INDEX_SALARY_CALCULTAX((long)2) s_vtbl vtbl_Salary_Person[]= { {(T_meth)Person_Age,0) }; s_vtbl vtbl_Salary_Taxable[]= { {T_meth)Salary_AffectIncomTax, -sizeof (s_PPerso
n) sizeof (s_PSalary)}, {T_meth)Salary_CalculTax, -sizeof(s_PPerson) sizeof (s_PSalary)} }; s_vtbl vtbl_Salary_Salary[]= { {(T_meth)Person_Age, sizeof(s_PSalary)} {(T_meth)Salary_AffectIncomeTax,0}, {(T_meth)salary_CalculTax,0} };
【００３２】各関数は、それを定義するクラスの名称と
共に予め固定されていることに注意すべきである。実際
に、方法がＣ関数の形式に翻訳されて１つの方法が導か
れたクラス内にオーバーロードされることがあり得るで
の、１つの方法によって実現された２つの異なるものを
区別するために、関数の名称を予め固定しておくことが
必要である。上の翻訳を出発点として用いると、そのよ
うに定義された構造の利用の例を示すことができる。以
下のコードの断片は翻訳すべきものと仮定する。 person *p; salary *s; short a;・・・ p = s a = s → Age() + p → Age(); strcpy (s → Name,"toto"); s → GrossMonthlySalary = 10000;
共に予め固定されていることに注意すべきである。実際
に、方法がＣ関数の形式に翻訳されて１つの方法が導か
れたクラス内にオーバーロードされることがあり得るで
の、１つの方法によって実現された２つの異なるものを
区別するために、関数の名称を予め固定しておくことが
必要である。上の翻訳を出発点として用いると、そのよ
うに定義された構造の利用の例を示すことができる。以
下のコードの断片は翻訳すべきものと仮定する。 person *p; salary *s; short a;・・・ p = s a = s → Age() + p → Age(); strcpy (s → Name,"toto"); s → GrossMonthlySalary = 10000;
【００３３】この翻訳は、以下の通りである。 char *p; char *s; short a;・・・ p = (s + Tabclass[((s_Part *)s) → cid] [CID_SA
LARY] . tabdep {CID_PERSON]); a = ((Tabclass[((s_Part*)s) → cid] [CID_SALARY] .
vtbl [INDEX_SALARY_AGE].m(s + Tabclass[s_Part *)s) → c
id] [CID_SALARY] . vtbl [INDEX_SALARY_AGE].D)) + Tabclass[((s_Part *)s)→cid] [CID_PERSON] . vtbl [INDEX_PERSON_AGE].m(s + Tabclass[(s_Part *)s) →
cid] CID_PERSON] . vtbl [INDEX_PERSON_AGE].d)); strcpy ((s_PPerson *) (s + Tabclass[((s_Part *)s) → cid] [CID_SALARY] . tabdep [CID_PERSON]))
→ st.Name, "toto"); ((s_PSalary *)s) → st. GrossMonthlySalary = 1000
0;
LARY] . tabdep {CID_PERSON]); a = ((Tabclass[((s_Part*)s) → cid] [CID_SALARY] .
vtbl [INDEX_SALARY_AGE].m(s + Tabclass[s_Part *)s) → c
id] [CID_SALARY] . vtbl [INDEX_SALARY_AGE].D)) + Tabclass[((s_Part *)s)→cid] [CID_PERSON] . vtbl [INDEX_PERSON_AGE].m(s + Tabclass[(s_Part *)s) →
cid] CID_PERSON] . vtbl [INDEX_PERSON_AGE].d)); strcpy ((s_PPerson *) (s + Tabclass[((s_Part *)s) → cid] [CID_SALARY] . tabdep [CID_PERSON]))
→ st.Name, "toto"); ((s_PSalary *)s) → st. GrossMonthlySalary = 1000
0;
【００３４】本発明によって提案される解決策は、この
ように、たとえば共用されるＵＮＩＸメモリ・セグメン
トにおけるオブジェクトのリンケージなどの、持続的で
共用されるオブジェクトの場合での多重継承に関係する
問題点すべてを解決する。これは、Ｃ＋＋言語が持続的
となる場合に、このＣ＋＋言語に効果的に適用できる
が、同様に、継承の同じ概念を支持する持続性のオブジ
ェクトの任意の他の言語又はシステムにも応用できる。
この解決策は、実現が容易かつ効果的であって、処理の
より大きな部分が、コンパイルの際に静的に実現され
る。課されるアドレッシング経路は、従前の操作なく、
ロードされているプロセス内のオブジェクトに新たに適
用できる。本発明の概念によれば、オブジェクトの構造
は、一方では、クラスのコードと、したがって、記憶さ
れることになるアドレス位置とは独立であり、他方で、
このオブジェクトを生じたクラスのコードとも独立であ
る。
ように、たとえば共用されるＵＮＩＸメモリ・セグメン
トにおけるオブジェクトのリンケージなどの、持続的で
共用されるオブジェクトの場合での多重継承に関係する
問題点すべてを解決する。これは、Ｃ＋＋言語が持続的
となる場合に、このＣ＋＋言語に効果的に適用できる
が、同様に、継承の同じ概念を支持する持続性のオブジ
ェクトの任意の他の言語又はシステムにも応用できる。
この解決策は、実現が容易かつ効果的であって、処理の
より大きな部分が、コンパイルの際に静的に実現され
る。課されるアドレッシング経路は、従前の操作なく、
ロードされているプロセス内のオブジェクトに新たに適
用できる。本発明の概念によれば、オブジェクトの構造
は、一方では、クラスのコードと、したがって、記憶さ
れることになるアドレス位置とは独立であり、他方で、
このオブジェクトを生じたクラスのコードとも独立であ
る。
【図１】多重継承の与えられた例に対する、非持続的で
共用されないオブジェクトに対する従来型の解決策を説
明するための説明図である。
共用されないオブジェクトに対する従来型の解決策を説
明するための説明図である。
【図２】同じ多重継承の例に対する、持続的で共用され
るオブジェクトの場合の本発明による解決策を説明する
ための説明図である。
るオブジェクトの場合の本発明による解決策を説明する
ための説明図である。
Claims (6)
- 【請求項１】 持続的でかつ共用されるオブジェクトを
用いるシステム又は言語での多重継承管理方法におい
て、 オブジェクトのフォーマットは、前記オブジェクトが持
続空間から仮想空間へロードされる間に変化せずに維持
され、 各クラスは、該クラスを使用しまたすべての再コンパイ
ルを介するすべてのアプリケーション内のクラス定数の
識別子に関連するオブジェクトを生じ、 前記オブジェクトの構造は、メモリでのアドレス位置と
このオブジェクトを生じるクラスのコードとは独立であ
り、 継承の管理を可能にするアドレッシング経路は、異なる
テーブルを介して借用されることを特徴とする多重継承
管理方法。 - 【請求項２】 請求項１記載の方法において、 メモリへの前記オブジェクトの記憶に対しては、各クラ
スはこのクラスに属するすべてのオブジェクトについて
同一であるパートと関連しており、 各パートは２つのサブパートから成り、第１のサブパー
トは前記オブジェクトを生じた実際のクラスの識別子を
含み、該識別子は継承の管理を可能にする前記経路の入
力点を生じるクラスのテーブルでのインデックスとして
用いられ、第２のサブパートは前記オブジェクトを生じ
たクラスによって定義された状態を含み、 前記クラス
によって定義された属性の全体はこの状態において再度
グループ化されることを特徴とする方法。 - 【請求項３】 請求項２記載の方法において、各クラス
に指定される前記クラス識別子は整数であることを特徴
とする方法。 - 【請求項４】 請求項２又は請求項３記載の方法におい
て、 クラスの前記テーブルは、各クラスに対して、それを介
してオブジェクトが操作され得る種々のマスクを含むマ
スクのテーブルに、ポインタを供給し、 各マスクは、継承されたクラスによって定義され、同時
に、前記オブジェクトと前記継承されたクラスに関連す
るパートとの操作を可能にする方法へのアクセスを承認
することを特徴とする方法。 - 【請求項５】 請求項４記載の方法において、 マスクのテーブルは継承されたクラスに前記オブジェク
トを生じたクラスである１つを加えた数のマスクを含
み、 各クラスは３つのフィールドを含み、第１のフィールド
は前記オブジェクトの最初のアドレスへのポインタから
開始して、前記オブジェクトを生じたクラスに関連する
パートへのポインタ、及びその逆を許容するオフセット
に対応し、第２のフィールドは当該オブジェクトに関連
するパートのアドレスの計算を許容し前記オブジェクト
の状態にアクセスするオフセットを生じるオフセット・
テーブルへのポインタに対応し、第３のフィールドは呼
び出されるべき方法の決定を許容する仮想テーブルへの
ポインタに対応することを特徴とする方法。 - 【請求項６】 請求項５記載の方法において、 ある方法が呼び出されると、当該方法に対応する呼び出
されるべき関数が計算され、 その目的のためにインデックスが、各クラスにそれに適
用可能な方法を含む仮想テーブルを関連させるコードの
発生器によって静的に定義され、 前記テーブルへの入力は、前記対応する方法を記憶する
関数へのポインタと、前記方法の前記第１のパラメータ
として扱われる前記オブジェクトのパートのアドレスの
計算を許容するオフセットとを含むことを特徴とする方
法。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR9402790A FR2717280B1 (fr) | 1994-03-10 | 1994-03-10 | Procédé de gestion de l'héritage multiple d'objets persistants et partagés. |
| FR9402790 | 1994-03-10 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JPH07262011A true JPH07262011A (ja) | 1995-10-13 |
Family
ID=9460894
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP7051463A Pending JPH07262011A (ja) | 1994-03-10 | 1995-03-10 | 持続的共用型オブジェクトの多重継承管理方法 |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US6052528A (ja) |
| EP (1) | EP0672983A1 (ja) |
| JP (1) | JPH07262011A (ja) |
| AU (1) | AU699650B2 (ja) |
| CA (1) | CA2144031A1 (ja) |
| FR (1) | FR2717280B1 (ja) |
Families Citing this family (28)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2775804B1 (fr) * | 1998-03-05 | 2000-04-14 | Alsthom Cge Alcatel | Procedes de stockage et de depaquetage des attributs d'un objet |
| US6330709B1 (en) * | 1998-03-30 | 2001-12-11 | International Business Machines Corporation | Virtual machine implementation for shared persistent objects |
| US6301582B1 (en) * | 1998-03-30 | 2001-10-09 | International Business Machines Corporation | System and method for storage of shared persistent objects |
| DE19819205A1 (de) | 1998-04-29 | 1999-11-04 | Siemens Ag | Datenhaltungssystem für persistente Daten |
| US6668285B1 (en) * | 1999-05-12 | 2003-12-23 | Koninklijke Philips Electronics N.V. | Object oriented processing with dedicated pointer memories |
| US6829761B1 (en) * | 1999-10-21 | 2004-12-07 | Oracle International Corporation | Method and apparatus for managing shared memory in a run-time environment |
| US6986102B1 (en) * | 2000-01-21 | 2006-01-10 | International Business Machines Corporation | Method and configurable model for storing hierarchical data in a non-hierarchical data repository |
| US7043488B1 (en) | 2000-01-21 | 2006-05-09 | International Business Machines Corporation | Method and system for storing hierarchical content objects in a data repository |
| US7356766B1 (en) | 2000-01-21 | 2008-04-08 | International Business Machines Corp. | Method and system for adding content to a content object stored in a data repository |
| US7346844B1 (en) | 2000-01-21 | 2008-03-18 | International Business Machines, Corporation | Method and system for moving content in a content object stored in a data repository |
| US7076494B1 (en) | 2000-01-21 | 2006-07-11 | International Business Machines Corporation | Providing a functional layer for facilitating creation and manipulation of compilations of content |
| US7007034B1 (en) | 2000-01-21 | 2006-02-28 | International Business Machines Corporation | File structure for storing content objects in a data repository |
| US7613993B1 (en) * | 2000-01-21 | 2009-11-03 | International Business Machines Corporation | Prerequisite checking in a system for creating compilations of content |
| US8589777B1 (en) | 2000-01-21 | 2013-11-19 | International Business Machines Corporation | Method and system for calculating cost of a compilation of content |
| US6839701B1 (en) | 2000-01-21 | 2005-01-04 | International Business Machines | Hitmask for querying hierarchically related content entities |
| US7089239B1 (en) | 2000-01-21 | 2006-08-08 | International Business Machines Corporation | Method and system for preventing mutually exclusive content entities stored in a data repository to be included in the same compilation of content |
| US7340481B1 (en) | 2000-01-21 | 2008-03-04 | International Business Machines Corp. | Method and system for adding user-provided content to a content object stored in a data repository |
| US7401097B1 (en) | 2000-01-21 | 2008-07-15 | International Business Machines Corporation | System and method for creating compilations of content |
| US7543304B2 (en) * | 2000-12-14 | 2009-06-02 | Borland Software Corporation | Method for efficient location of corba objects based on an unmarshaled object key in a request |
| US7620731B1 (en) * | 2001-02-21 | 2009-11-17 | Microsoft Corporation | Isolated persistent storage |
| US7069540B1 (en) * | 2001-07-02 | 2006-06-27 | Unisys Corporation | COM persistence model |
| US6912520B2 (en) * | 2001-08-29 | 2005-06-28 | Sun Microsystems, Inc. | System and method for providing a persistent object framework for managing persistent objects |
| US7010791B2 (en) * | 2001-09-20 | 2006-03-07 | Intel Corporation | Method for implementing multiple type hierarchies |
| US6976244B2 (en) * | 2002-01-09 | 2005-12-13 | International Business Machines Corporation | Method, system, and product for storage of attribute data in an object oriented environment |
| US7665077B2 (en) * | 2004-10-18 | 2010-02-16 | Microsoft Corporation | System and method for sharing objects between applications in a virtual runtime environment |
| US8387069B2 (en) * | 2006-07-28 | 2013-02-26 | Dell Products L.P. | Method to support dynamic object extensions for common information model (CIM) operation and maintenance |
| US9141450B2 (en) * | 2009-08-25 | 2015-09-22 | Adobe Systems Incorporated | Embedded application communication |
| EP2619687B1 (en) * | 2010-09-24 | 2016-04-06 | Intel Corporation | Sharing virtual functions in a shared virtual memory between heterogeneous processors of a computing platform |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH06266564A (ja) * | 1992-11-12 | 1994-09-22 | Internatl Business Mach Corp <Ibm> | 複合データ構造を生成及び記憶する方法及び装置 |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4853842A (en) * | 1985-09-11 | 1989-08-01 | Texas Instruments Incorporated | Computer memory system having persistent objects |
| JPH0833862B2 (ja) * | 1989-10-23 | 1996-03-29 | インターナシヨナル・ビジネス・マシーンズ・コーポレーシヨン | オブジエクト指向コンピユータ・システム |
| JPH047640A (ja) * | 1990-04-25 | 1992-01-13 | Hitachi Ltd | クラス継承解決処理方法 |
| US5327562A (en) * | 1992-05-06 | 1994-07-05 | Microsoft Corporation | Method for implementing virtual function tables in a compiler for an object-oriented programming language |
| EP0578207B1 (en) * | 1992-07-06 | 1999-12-01 | Microsoft Corporation | Method for naming and binding objects |
| US5615400A (en) * | 1993-06-30 | 1997-03-25 | Apple Computer, Inc. | System for object oriented dynamic linking based upon a catalog of registered function set or class identifiers |
| US5542078A (en) * | 1994-09-29 | 1996-07-30 | Ontos, Inc. | Object oriented data store integration environment for integration of object oriented databases and non-object oriented data facilities |
| US5630087A (en) * | 1994-11-02 | 1997-05-13 | Sun Microsystems, Inc. | Apparatus and method for efficient sharing of virtual memory translations |
-
1994
- 1994-03-10 FR FR9402790A patent/FR2717280B1/fr not_active Expired - Fee Related
-
1995
- 1995-03-01 EP EP95400439A patent/EP0672983A1/fr not_active Withdrawn
- 1995-03-06 CA CA002144031A patent/CA2144031A1/fr not_active Abandoned
- 1995-03-08 AU AU14709/95A patent/AU699650B2/en not_active Ceased
- 1995-03-10 JP JP7051463A patent/JPH07262011A/ja active Pending
-
1997
- 1997-05-14 US US08/856,040 patent/US6052528A/en not_active Expired - Fee Related
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH06266564A (ja) * | 1992-11-12 | 1994-09-22 | Internatl Business Mach Corp <Ibm> | 複合データ構造を生成及び記憶する方法及び装置 |
Also Published As
| Publication number | Publication date |
|---|---|
| FR2717280B1 (fr) | 1996-04-05 |
| FR2717280A1 (fr) | 1995-09-15 |
| CA2144031A1 (fr) | 1995-09-11 |
| AU699650B2 (en) | 1998-12-10 |
| US6052528A (en) | 2000-04-18 |
| AU1470995A (en) | 1995-09-21 |
| EP0672983A1 (fr) | 1995-09-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JPH07262011A (ja) | 持続的共用型オブジェクトの多重継承管理方法 | |
| US6253226B1 (en) | Duration-based memory management of complex objects | |
| Stroustrup | Multiple inheritance for C++ | |
| US6119145A (en) | Multithreaded client application storing a separate context for each transaction thus allowing threads to resume transactions started by other client threads | |
| EP1086419B1 (en) | A method of and system for implementing parameterized types to be compatible with existing unparameterized libraries | |
| JP3550151B2 (ja) | ロード・リンキング装置および方法 | |
| US5848419A (en) | Methods and apparatus for providing transparent persistence in a distributed object operating environment | |
| US5999987A (en) | Concurrent processing in object oriented parallel and near parallel | |
| US5907707A (en) | Object model for Java | |
| Shapiro et al. | Persistence and migration for C++ objects | |
| AU2003225220B2 (en) | Providing common memory management code to objects that are instances of different classes | |
| US6526457B1 (en) | Systems utility object interface for facilitating software portability | |
| US5794041A (en) | C++ ojbect model alternatives | |
| JPH03231352A (ja) | オブジェクトクラス定義情報実装装置 | |
| US5603030A (en) | Method and system for destruction of objects using multiple destructor functions in an object-oriented computer system | |
| US6327606B1 (en) | Memory management of complex objects returned from procedure calls | |
| EP1502192B1 (en) | Simplified deallocation of memory for programming objects | |
| Hamilton | Language integration in the common language runtime | |
| Paepcke | PCLOS: Stress testing CLOS Experiencing the metaobject protocol | |
| US6829761B1 (en) | Method and apparatus for managing shared memory in a run-time environment | |
| Hosking et al. | Towards compile-time optimisations for persistence | |
| JP4084956B2 (ja) | オブジェクト集合方法およびシステム | |
| US6279148B1 (en) | Method and apparatus for supporting efficient programming in dynamic pointer-safe languages | |
| Krakowiak et al. | A generic object-oriented virtual machine | |
| US6854113B1 (en) | Mixed-mode execution for object-oriented programming languages |