(57)【要約】      （修正有）【課題】オペレーティングシステムをオブジェクト指向言語Ｃ＋＋で記述する際の、テキストストリング操作に関わるコードおよびサイクルオーバヘッドを減少させるようにする。【解決手段】テキストストリングに関するオブジェクトの全てを、各々が異なった関数を実行し、少なくともその１つがコードおよびサイクルオーバヘッドを減少するように変更されている、３つのクラスの１つに属するものとして扱う、オブジェクト指向オペレーティングシステム。これにより、実行可能コードのオーバーヘッドを最小にして必要なメモリ容量を最少とし、最小サイクル数での実行により消費電力を最少とすることができる。このオペレーティングシステムは特に、ＲＯＭベースのモバイルコンピュータ装置によく適合する。【選択図】図８
2006302303.tif 000002
【特許請求の範囲】
【請求項１】
テキストストリングに関するオブジェクトを扱うように構成されたオブジェクト指向オペレーティングシステムでプログラムされたコンピュータ装置であって、前記オペレーティングシステムが、前記オブジェクトの全てを、各々が異なった関数を実行し、少なくともその１つがコードおよびサイクルオーバヘッドを減少するように変更されている、３つのクラスの１つに属するものとして扱うことを特徴とするコンピュータ装置。
【請求項２】
テキストストリングに関するオブジェクトを扱うように構成されたオブジェクト指向オペレーティングシステムでプログラムされたコンピュータの周辺装置であって、前記オペレーティングシステムが、前記オブジェクトの全てを、各々が異なった関数を実行し、少なくともその１つがコードおよびサイクルオーバヘッドを減少するように変更されている、３つのクラスの１つに属するものとして扱うこと、さらにまた前記周辺装置が、オブジェクトを前記３つのクラスにはいるものとして扱うようにプログラムされていることを特徴とする周辺装置。
【請求項３】
テキストストリングに関するオブジェクトを扱うように構成され、コンピュータで読み取り可能な媒体にコード化されたコンピュータのオペレーティングシステムであって、前記オペレーティングシステムが、前記オブジェクトの全てを、各々が異なった関数を実行し、少なくともその１つがコードおよびサイクルオーバヘッドを減少するように変更されている、３つのクラスの１つに属するものとして扱うことを特徴とするオペレーティングシステム。
【請求項４】
テキストストリングに関するオブジェクトを扱うように構成されたコンピュータのオペレーティングシステムを使用してマイクロプロセッサを操作する方法であって、前記オペレーティングシステムが、前記オブジェクトの全てを、各々が異なった関数を実行し、少なくともその１つがコードおよびサイクルオーバヘッドを減少するように変更されている、３つのクラスの１つに属するものとして扱うことを特徴とする方法。
【請求項５】
テキストストリングに関するオブジェクトを扱うように構成されたコンピュータのオペレーティングシステムでコード化された、コンピュータで読み取り可能な媒体であって、前記オペレーティングシステムが、前記オブジェクトの全てを、各々が異なった関数を実行し、少なくともその１つがコードおよびサイクルオーバヘッドを減少するように変更されている、３つのクラスの１つに属するものとして扱うことを特徴とする媒体。
【請求項６】
前記３つのクラスの１つのオブジェクトがポインタであることを特徴とする請求項１から５のいずれか１項に記載の装置または方法。
【請求項７】
ポインタがリテラルテキストの元のメモリ位置を指し示すことを特徴とする請求項６に記載の装置または方法。
【請求項８】
前記オブジェクトがフラット構造であることを特徴とする請求項６に記載の装置または方法。
【請求項９】
前記３つのクラスの１つのオブジェクトが、長さが制限されたテキストを扱うことを特徴とする請求項１から５のいずれか１項に記載の装置または方法。
【請求項１０】
長さが制限されたテキストを扱う前記オブジェクトが、入手可できる可能性のあるメモリ管理関数の限定されたサブセットによって供給されることを特徴とする請求項９に記載の装置または方法。
【請求項１１】
長さが制限されたテキストを扱う前記オブジェクトが、スタティックメモリを使用することを特徴とする請求項１０に記載の装置または方法。
【請求項１２】
長さが制限されたテキストを扱う前記オブジェクトが、フラット構造であることを特徴とする請求項９に記載の装置または方法。
【請求項１３】
前記３つのクラスの１つのオブジェクトが、ヒープメモリを使用し、入手できるメモリ管理関数のフルセットを必要とすることを特徴とする請求項１から５のいずれか１項に記載の装置または方法。
【請求項１４】
前記３つのクラスのいずれかのオブジェクトがポリモルフィックであることを特徴とする請求項１から１３のいずれか１項に記載の装置または方法。
【請求項１５】
ポリモルフィズムが、各オブジェクト内の所定のフィールドを検査し、前記フィールド内の値に応じて、異なった種類の作用をもたらす関数を含むオペレーティングシステムによって、１つのインスタンスで達成されることを特徴とする請求項１４に記載の装置または方法。
【請求項１６】
前記フィールドが機械語と別のデータ項目を共有することを特徴とする請求項１５に記載の装置または方法。
【請求項１７】
８ビット文字セットおよび１６ビット文字セットで変化しないクラスネームのエイリアスを使用して、８ビット文字セットおよび１６ビット文字セットで変化しない形態で記述されていることを特徴とする請求項１から１６のいずれか１項に記載の装置または方法。
【請求項１８】
アスキーおよびユニコードで変化しないクラスネームのエイリアスを使用して、アスキーおよびユニコードで変化しない形態で記述されていることを特徴とする請求項１７に記載の装置または方法。
【請求項１９】
前記３つのクラスのいずれかのオブジェクトが、本質的に長さが指定され、従って「０」ターミネータを持たないことを特徴とする請求項１から１８のいずれか１項に記載の装置または方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータ用のオブジェクト指向オペレーティングシステムの改良に関する。本発明は特に、Ｃ＋＋プログラミング技法に基づいたオペレーティングシステムに関する。  このオペレーティングシステムの市場で入手可能な実施形態は、英国のＰｓｉｏｎ Ｓｏｆｔｗａｒｅ Ｐｌｃで製造されるＥＰＯＣ３２オペレーティングシステムである。ＥＰＯＣ３２はモバイルコンピュータ環境に適したオペレーティングシステムである。
【背景技術】
【０００２】
Ｃ＋＋言語は、パーソナルコンピュータなどのコンピュータ用のアプリケーションプログラムを記述するのに広く使用されているが、オペレーティングシステムを記述するのには、まれにしか用いられていない。パーソナルコンピュータ用のオペレーティングシステムを記述するときには、通常、実行可能コードのサイズを最小化すること、あるいはプログラム内でステップを実行するのに必要なサイクル数を最小化するという用件は優先されない。一般的には、性能と記述の容易さがより重要な用件である。
【特許文献１】とくになし
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかしながら、他の状況では、（例えば、それを格納するＲＯＭおよび／またはＲＡＭの容量を最少とするため）実行可能コードの占めるスペースを最小としなければならず、（例えば、消費電力を最少とするため）最小数のサイクルで実行する必要が生じる場合がある。
【０００４】
モバイルコンピューティング（例えば、パーソナルデジタル支援機器：ＰＤＡ）、スマートフォン（例えば、ワードプロセッサが組み込まれ、ファクシミリの送受信およびインターネットの閲覧が可能なＧＳＭセルラ電話）およびネットワークコンピュータ（ＮＣ）環境は、オペレーティングシステムのコードサイズを最小化することが利点となる環境の実例である。すなわち、最小化によって、主にハードウェア（特にＲＯＭおよび／またはＲＡＭ）のコストを削減することができる。広範囲に及ぶ消費材への適用は一般的に比較的低価格のハードウェアに依存しているので、この点は上記状況において特に重要である。同様に、モバイルコンピューティングおよびスマートフォンの範疇においては、プロセッサの実行サイクルを最小化することは、消費電力を最少化し、消費電力の最少化はバッテリの長寿命化に不可欠であるので、非常に重要である。Ｃ＋＋で記述され十分に設計されたオペレーティングシステムは、通常、サイズが相当大きく電力をかなり消費するものとなる。従って、これはモバイルコンピューティング、スマートフォンおよびＮＣ環境に適さない。
【０００５】
更に、コードサイズとオーバーヘッドサイクルの厳しい要求、特に、モバイル、スマートフォンおよびＮＣコンピューティング環境に関する厳しい要求を満たし、十分に機能的なオペレーティングシステムをＣ＋＋で設計するのは、一般的に困難であると考えられている。
【０００６】
用語
「ストリングクラスのオブジェクト」
Ｃ＋＋では、テキスト（例えば、コンピュータの画面に実際に現れる文字のストリング）は「オブジェクト」として表わされる。Ｃ＋＋または他のオブジェクト指向言語の当業者は、このカテゴリ化に精通しているであろう。このようなテキストに関連したオブジェクトは、「ストリングクラスのオブジェクト」と呼ばれる特定のタイプである。オブジェクトが属するクラスの種類（例えば、テキストの場合はストリングクラス）は、そのオブジェクトに実行することが許される操作を規定する。ストリングクラスには一定の操作（例えば、２つのテキストストリングをまとめて連結する）だけが行える。従って、ストリングクラスのある特定のオブジェクトは、特定のテキストストリングを表わしている。それは特定の、十分に定義された方法でのみ操作される。
【０００７】
テキストがファイリングシステムのファイルに存在するとき、テキストの項目からストリングクラスのオブジェクトを生成するためには、従来のＣ＋＋プログラミングでは以下のステップが実行される。
【０００８】
・メモリ内のバッファ位置をずらす
・ファイル読み取りサービスを使用してテキストをバッファに読み込む
・ストリング生成サービスを使用してバッファされたデータをストリングクラスのオブジェクトに変える
・バッファの内容を破棄する
Ｃ＋＋ではテキストストリングの実際の格納位置を識別するのは困難であるが、テキストストリングの位置を知る必要はない。なぜなら、直接操作するのはストリングクラスのオブジェクトであり、その結果実際のテキストストリングが操作される。従って、ストリングクラスのオブジェクトは、事実上テキストストリングのメモリ位置を知っており、テキスト操作に関連する必要なメモリ管理タスクの全てを扱うことができる。
【０００９】
ストリングクラスのオブジェクトの多重クラス
ＡＮＳＩ／ＩＳＯのＣ＋＋標準の草案として知られるＣ＋＋のバージョンでは、ストリングクラスの全てのオブジェクトは（＜ｓｔｒｉｎｇ＞として参照される、上記標準のスタンダードライブラリの草案の部分のストリングクラスで例示されているように）、洗練されたメモリ管理タスクが遂行されるような方法で処理される（例えば、バッファスペースを拡張したり、縮小したり、結合できる、すなわち、完全に動的な、テキスト用のバッファスペースの再配置）。しかし、このレベルのメモリ管理は、大量のコードを使用し、かなり大きいスペースを必要とする。
【００１０】
ここで従来のＣ＋＋のメモリ管理の２つの例を示す。
【００１１】
例１：Ｃ＋＋のリテラルテキストの処理
Ｃ＋＋では、ソースコードがテキストストリングを含むインスタンスが多数ある。これらのテキストストリングは「リテラルテキスト」として知られ、ソースコードを実行可能なオブジェクトコードへとコンパイルする時に、リテラルテキストはバッファメモリに永久的に格納される。リテラルテキストが操作されるとき、ストリングクラスのオブジェクトは、そこから生成されなければならない。しかしながら、このストリングクラスのオブジェクトの生成することで、メモリ内にテキストストリングが生成されることになり、このテキストストリンは、新たに生成されたストリングクラスのオブジェクトによって実際に操作されることになる。要するに、テキストストリングがメモリ内で複製されるのである。すなわち、テキストストリングは、ソースコードのコンパイルによって生じるオリジナルバッファで一度生成され、さらに、テキストの操作を可能とするストリングクラスのオブジェクトに関連したメモリ位置で再度複製される。
【００１２】
上記のように、あるコンピュータ環境では、コード空間および消費電力は重要である。しかしながら、（ＡＮＳＩ／ＩＳＯのＣ＋＋標準の草案で実現されるような）従来のＣ＋＋では、リテラルテキストの固有の複製を解消する機構がない。オペレーティングシステムではリテラルテキストを扱わなければならない場合が多数あるので、これはオペレーティングシステムでは特に問題である。
【００１３】
例２：Ｃ＋＋の長さが制限されたテキストの処理
Ｃ＋＋では、プログラマはヒープメモリを使用してテキストを処理する。長さが制限されたテキストは、長さが制限されていないテキストの処理に必要な十分に柔軟な手法を実際には必要としない。それにもかかわらず、従来のＣ＋＋では、テキストの長さに関係なく、ストリングクラスのオブジェクトに十分特徴付けられた、十分に柔軟な機構しかなく、それ以外の機構がない。ヒープメモリの取り扱いはコードおよびサイクルを集中的に使用するので、これは、メモリ管理コードにおけるオーバーヘッドを大きくする。
【００１４】
Ｃ＋＋の全体にわたるテキストのメモリ管理は、コードおよびサイクルを集中的に使用する。コード空間および消費電力はモバイル環境では重要であるので、従来のＣ＋＋の手法では、受容できないほどコードサイズが大きく、かつ、電力も大量に消費するオペレーティングシステムとなってしまう。
【課題を解決するための手段】
【００１５】
本発明のオペレーティングシステムは、ストリングクラスのオブジェクト（例えば、ＡＮＳＩ／ＩＳＯのＣ＋＋標準の草案で定義されるような）を、ストリングクラスのオブジェクトの３重構造、主に３つの新しいオブジェクトのクラスで置き換えることで再定義する。従来の、ＡＮＳＩ／ＩＳＯのＣ＋＋標準の草案による＜ｓｔｒｉｎｇ＞に機能的に関連し十分特徴付けられたメモリ管理関数は、３つの新しいクラスの全てに適用されない。十分に機能するものは多くの環境で有用であるが、コード空間および消費電力が重要なモバイルコンピューティング環境では（とりわけ）問題である。
【００１６】
従って、本発明の進歩的概念の一般化は、コンピュータのオペレーティングシステムに、テキストストリングを扱う３つの異なったクラス、すなわち、異なったクラスの各々が異なった状況に適している３つの異なったクラス、を提供することで、コードサイズおよびサイクルオーバヘッドを最小化することである。これは柔軟性を与える。すなわち、例えば、全ての機能を果たすメモリ管理関数は、今や実際にそれを必要とするテキストストリングにだけ適用されうる。
【００１７】
この新しいストリングクラスのオブジェクトのファミリを「ディスクリプタ（ｄｅｓｃｒｉｐｔｏｒ）」として参照することにする。好ましい実施形態では、このファミリのメンバを「ポインタディスクリプタ」、「バッファディスクリプタ」および「ヒープディスクリプタ」と呼ぶ。これらの概念は、当業者が親しんでいる「ポインタ」、「バッファ」および「ヒープ」の確立された概念とは（関連するが）異なることに注意が必要である。また、本明細書で想定するディスクリプタも、同じ名前のＶＭＳ設備や、アクティブオペレーティングシステムを識別するのに使用される小さな整数用のＵＮＩＸ（登録商標）用語とは何の関係もないことにも注意が必要である。当業者には、テキストストリングを扱うクラスの数が３つを越えるようにオペレーティングシステムを設計することができることが理解されるであろう。そのような変形も本発明の範囲に含まれる。３重構造は、クラスの増殖（ｐｒｏｌｉｆｅｒａｔｉｏｎ ｏｆ Ｃｌａｓｓｅｓ）としては最小（かつほとんど全ての場合にもっとも有効）である。
【００１８】
更に、ディスクリプタは好ましくはポリモルフィックであり、従って、単一のサービスが全てのディスクリプタに作用する。異なったディスクリプタの各々が別の方法で変更されたサービスを必要とするので、これによって、かなりのコードと、それより少ない程度でのオーバーヘッドの削減となる。
【発明を実施するための最良の形態】
【００１９】
本発明の第１の態様によれば、テキストストリングに関するオブジェクトを扱うように構成されたオブジェクト指向オペレーティングシステムでプログラムされたコンピュータであって、前記オペレーティングシステムが、前記オブジェクトの全てを、各々が異なった機能を実行し、少なくともその１つがコードおよびサイクルオーバヘッドを減少するように変更されている、３つのクラス（主に、ポインタディスクリプタクラス、バッファディスクリプタクラスおよびヒープディスクリプタクラス）の１つに属するものとして扱うことを特徴とするコンピュータが提供される。
【００２０】
本発明は、コードおよびサイクルオーバヘッドをかなり減少させるためには、従来の単一形態のストリングクラスのオブジェクトを、（例えば）各形態が異なった状況に最適化された、３つの異なった形態のオブジェクトに置き換えて、オペレーティングシステムを再設計する必要があるという知見に基づいている。
【００２１】
本発明の好適な形態では、従来の、メモリを集中的に使用するテキスト処理技法は、そのような技法を要求するオブジェクトを定義する新しいディスクリプタクラス（すなわち、ヒープディスクリプタ）に属するオブジェクトにのみ適用される。しかしながら、ポインタおよびバッファディスクリプタクラスは、従来のストリングクラスと比べてコードおよびプロセッササイクルを減少させるように設計されている。
【００２２】
上記従来技術で記載した２つの例（すなわち、例１：Ｃ＋＋のリテラルテキストの処理と、例２：Ｃ＋＋の長さが制限されたテキストの処理）を使用して、本発明のオペレーティングシステムは、（ｉ）リテラルテキストの複製の必要をなくすようにリテラルテキストを扱い、（ｉｉ）実際に必要な限られた状況でのみヒープメモリのコードの集中的使用を行うように実行時に動的に決定され、他の状況（例えば、プログラマが前もってテキストの最大長を知っているとき）では、代わりにスタティックメモリを使用して、テキストを扱う。特定の処理の更なる詳細は以下で行う。
【００２３】
好ましくは、オペレーティングシステムは同じ３重構造を用いて、テキストだけでなく生のデータも扱うように構成される。
【００２４】
先に定義したコンピュータ／オペレーティングシステムの組み合わせに加えて、他の進歩的態様も同様に扱うことができるであろう。例えば、そのようなオペレーティングシステムをインタフェースしなければならないあらゆるデバイスも、ストリングクラスのオブジェクト用の同じ３重構造を使用する必要がある。例えば、固体メモリデバイスのような周辺機器用ドライバソフトウェアは、この３重構造を使用する必要がある。周辺機器用制御パネルのソフトウェアも同様である。
【００２５】
従って、本発明の第２の態様では、テキストストリングに関するオブジェクトを扱うように構成されたオブジェクト指向オペレーティングシステムでプログラムされたコンピュータの周辺装置であって、前記オペレーティングシステムが、前記オブジェクトの全てを、各々が異なった関数を実行し、少なくともその１つがコードおよびサイクルオーバヘッドを減少するように変更されている、３つのクラス（主に、ポインタディスクリプタクラス、バッファディスクリプタクラスおよびヒープディスクリプタクラス）の１つに属するものとして扱うこと、さらにまた前記周辺装置が、オブジェクトを前記３つのクラスにはいるものとして扱うようにプログラムされていることを特徴とする周辺装置が提供される。
【００２６】
本発明の第３の態様では、テキストストリングに関するオブジェクトを扱うように構成され、コンピュータで読み取り可能な媒体にコード化されたコンピュータのオペレーティングシステムであって、前記オペレーティングシステムが、前記オブジェクトの全てを、各々が異なった関数を実行し、少なくともその１つがコードおよびサイクルオーバヘッドを減少するように変更されている、３つのクラス（主に、ポインタディスクリプタクラス、バッファディスクリプタクラスおよびヒープディスクリプタクラス）の１つに属するものとして扱うことを特徴とするオペレーティングシステムが提供される。
【００２７】
本発明の第４の態様では、テキストストリングに関するオブジェクトを扱うように構成されたコンピュータのオペレーティングシステムを使用してマイクロプロセッサを操作する方法であって、前記オペレーティングシステムが、前記オブジェクトの全てを、各々が異なった関数を実行し、少なくともその１つがコードおよびサイクルオーバヘッドを減少するように変更されている、３つのクラス（主に、ポインタディスクリプタクラス、バッファディスクリプタクラスおよびヒープディスクリプタクラス）の１つに属するものとして扱うことを特徴とする方法が提供される。
【００２８】
第５の態様では、テキストストリングに関するオブジェクトを扱うように構成されたコンピュータのオペレーティングシステムでコード化された、コンピュータで読み取り可能な媒体であって、前記オペレーティングシステムが、前記オブジェクトの全てを、各々が異なった関数を実行し、少なくともその１つがコードおよびサイクルオーバヘッドを減少するように変更されている、３つのクラス（主に、ポインタディスクリプタクラス、バッファディスクリプタクラスおよびヒープディスクリプタクラス）の１つに属するものとして扱うことを特徴とする媒体が提供される。典型的には、コンピュータで読み取り可能な媒体はマスクＲＯＭである。配布用に、媒体は一般的なＣＤ−ＲＯＭまたはフロッピー（登録商標）ディスクであってもよい。
【００２９】
本発明をＥＰＯＣ３２として知られる実施形態に関して記載する。ＥＰＯＣ３２は、英国のＰｓｉｏｎ Ｓｏｆｔｗａｒｅ Ｐｌｃによって開発された、（特に）モバイルおよびスマートフォン環境用の、３２ビットオペレーティングシステムである。ＥＰＯＣ３２の実施形態のより詳細な説明は、英国のＰｓｉｏｎ Ｓｏｆｔｗａｒｅ Ｐｌｃによって発行されたＥＰＯＣ３２に関するＳＤＫの、付録１として添付された部分に開示されている。本発明者および譲渡人の権利があらゆる意味で限定されない範囲において、ＳＤＫ全体を本明細書に参照によって組み込む。
【００３０】
ＥＰＯＣ３２は、多数の異なったマイクロプロセッサアーキテクチャ上で実行するように移植された。オペレーティングシステムの移植の詳細は本質的に本明細書の範囲外であるが、当業者には理解できるであろう。特に、ＥＰＯＣ３２は英国のＡｄｖａｎｃｅｄ ＲＩＳＣ ＭａｃｈｉｎｅｓのＡＲＭ ＲＩＳＣ型マイクロプロセッサに移植されている。ＡＲＭマイクロプロセッサの様々なモデルは、デジタルセルラ電話に広く使用されており、当業者にはよく知られている。しかしながら、本発明は多数の異なったマイクロプロセッサ上で実現できる。従って、本明細書の請求の範囲は、オペレーティングシステムが請求の範囲に記載されたような関数を実行する、あらゆる全てのハードウェアおよびソフトウェアの実施に及ぶものと理解すべきである。
【００３１】
上記従来技術の検討で挙げた、リテラルテキストおよび長さが制限されたテキストの例に戻り、ＥＰＯＣ３２は、ストリングクラスのオブジェクト用の上記３重構造を以下のように使用する。
【００３２】
例１：ＥＰＯＣ３２におけるリテラルテキスト
上記のように、従来のＣ＋＋では、リテラルテキストに関するテキストストリングはメモリ内で複製される。すなわち、ソースコードのコンパイルで生じるオリジナルバッファ内で一度生成され、テキストの操作を可能にするストリングクラスのオブジェクトに関するメモリ位置で再度複製される。この複製は無駄である。
【００３３】
しかしながら、ＥＰＯＣ３２は、リテラルテキストの元のメモリ位置（すなわち、コンパイラによって定められたメモリ位置）を指し示すポインタディスクリプタを使用する。このポインタディスクリプタ（ＥＰＯＣ３２ではＴＰｔｒＣ ポインタディスクリプタと呼ぶ）は、リテラルテキスト用のストリングクラスのオブジェクトである。（Ｃ＋＋では、本質的にポインタは通常オブジェクトとして認識されていない。
【００３４】
従って、ＥＰＯＣ３２のポインタ／オブジェクトのハイブリッドによって、リテラルテキストの追加のコピーの必要が完全に除去される。
【００３５】
例２：ＥＰＯＣ３２における長さが制限されたテキスト
上記のように、従来のＣ＋＋では、テキストの長さに関係なく、十分に柔軟で十分に特徴付けられたストリングクラスのオブジェクトを使用する機構しかなく、それ以外を使用する機構はない。ヒープメモリの処理はコードおよびサイクルを集中的に使用するので、これによりメモリ管理コードに多くのオーバーヘッドが生じる。
【００３６】
ＥＰＯＣ３２では、サイズが制限されたバッファディスクリプタと呼ばれる、ストリングのオブジェクトについての特別なクラスがある。これらはサイズが制限されているので、操作するのに複雑なメモリアロケーションコードを必要としない。更に、バッファディスクリプタは（ヒープメモリではなく）スタティックメモリを使用できる。スタティックメモリはヒープメモリでできるようなコードを集中的に使用する方式でメモリを再配置できないが、必要な操作を行うのに必要となるコードサイクルが少ない点で、使用するのにより効率的である（従って電力の削減となる）。ＥＰＯＣ３２は、実際に動的な場合に限って、多くのサイクルオーバヘッドを伴うヒープメモリを使用する。その場合には、ヒープディスクリプタクラスを使用する。
【００３７】
ＥＰＯＣ３２は、長さが制限されたストリングクラスのパラメータを、「ＴＢｕｆ」クラスのクラステンプレートを使用して定義する。（クラステンプレートはストリングクラスの多数のオブジェクトのプロパティを定義する。例えば、ＴＢｕｆ は全てのバッファディスクリプタ、すなわち、バッファの変形のストリングクラスの全てのオブジェクトのテンプレートである。ＴＢｕｆ はストリングクラスのそのようなオブジェクトに対して一定の共通プロパティを定義する。）
ＥＰＯＣ３２は、コードサイズおよびサイクルオーバヘッドを最小化する以外の重要な特徴も示す。それは主に以下の点である。
【００３８】
・「フラット」構造として動作する、ストリングおよび生のデータバッファクラスのオブジェクト
・ディスクリプタが与えるポリモルフィック特性
・ディスクリプタがユニコードおよびアスキーの一様なコーディングを可能とするフラット構造としてのストリングおよび生のデータバッファクラスのオブジェクト
全てのディスクリプタは「フラット」構造である（すなわち、ディスクリプタがコピーされると、ディスクリプタ自身だけがコピーされる。従来のＣ＋＋では、オブジェクトのコピーはオブジェクト自身だけでなく関連する全てのポインタおよびポインタで示されるデータ、すなわち、オブジェクトに意味を与える複雑な関連する構造、のコピーも必要である。）。従って、ＥＰＯＣ３２では、ディスクリプタをコピーすることは、通常のＣ＋＋で等価であるオブジェクトをコピーすることよりも、メモリオーバヘッドおよびサイクルにおいてはるかに経済的である。
【００３９】
これはＥＰＯＣ３２で、バッファおよびポインタについて以下のように達成される。
【００４０】
バッファディスクリプタ（ＴＢｕｆ）は、バッファによって参照される実際のテキストを含んでおり、従って、バッファをコピーすると本質的に関連するテキストをコピーする。Ｃ＋＋のようにポインタおよび関連するデータのコピーは必要ない。
【００４１】
ポインタディスクリプタ（ＴＰｔｒ）は、Ｃ＋＋型のポインタを内部に含んでいるので、複製するときにはＴＰｔｒだけが必要である。従来のＣ＋＋では、１つのエンティティだけでなく関連する別のポインタおよびテキストもコピーする必要があった。
【００４２】
ポリモルフィックオブジェクトとしてのディスクリプタ
共通の作用が異なった機構によって達成されるとしても、グループ内の全てのオブジェクトが単一のオブジェクトのように作用するとき、オブジェクトのグループはポリモルフィズムを示すと言われる。ポリモルフィズムは従来のＣ＋＋では、互いにポリモルフィックな全てのオブジェクトが、共通の位置に、仮想関数テーブルへのポインタ（従ってポインタは各オブジェクト内に必要である）を含んでいる、仮想関数によってもたらされる。このテーブルは各ポリモルフィック関数に対する実際のコードを識別する。ポリモルフィズムを共有する各クラスに対して別のテーブルが必要である。しかしこの手法は、各ポインタが３２ビット（すなわち４文字）であり各オブジェクトが仮想関数テーブルへのポインタを必要とするので、比較的大きな空間を使用する。更に、各オブジェクトで３２ビット長のフィールドも使用される。
【００４３】
（特に）モバイルオペレーティングシステム環境においては、このことは問題である。ＥＰＯＣ３２では、ストリングクラスのオブジェクトに対して次のように対処する。すなわち、３２ビット長のフィールドが細分割され、最初の４ビットがディスクリプタのタイプを記述する。そして関数は４ビットを検査し、正しいテキスト位置を指し示す（例えば、ディスクリプタがバッファならばディスクリプタ自体の中など）。従って、ストリングクラスのオブジェクトに対する３つの異なったクラスのディスクリプタ（すなわち、ポインタディスクリプタ、バッファディスクリプタおよびヒープディスクリプタ）の各々が、単一の３２ビットフィールドの最初の４ビットだけを使用して記述できるということによってポリモルフィズムが提供される。このようにしてかなりのメモリの節約が達成される。より一般的には、フィールドは別のデータ項目と機械語を共有する。
【００４４】
ユニコードおよびアスキーで変化しないコード
Ｃ＋＋では、１６ビットのユニコードのコーディングは、そうでなければ８ビットコードとなる全てのテキストデータのサイズを２倍にすることとなる。また、従来は、プログラマがソースコードを書くときに、アスキーまたはユニコードのどちらを使用して記述するかを決定する必要があった。
【００４５】
ＥＰＯＣ３２では、アスキーまたはユニコードの最終的な選択にかかわらず、同じソースコードが使用される。これはシステムを、クラスそれ自体（例えば、ポインタディスクリプタ、バッファディスクリプタおよびヒープディスクリプタ）でなく、アスキーおよびユニコードによって変化しない、クラスネームのエイリアスを使用して構成することによって達成される。従って、ユニコードを記述するのにポインタＴＰｔｒ１６ を使用したり、アスキーを記述するのにＴＰｔｒ８ を使用して作成する代わりに、プログラマはＴＰｔｒ クラスネームを使用して作成する。
【００４６】
作成時に、クラスネームは１６ビットユニコードまたは８ビットアスキーコードのいずれかでコンパイルできる。この手法は、異なったビット長でコード化される全ての文字セットを含むように適用できる。
【００４７】
ＥＰＯＣ３２の補足的利点
Ｃ＋＋では、テキストストリングは通常「０」で終了し、これによりシステムはテキストストリングの終了位置を容易に知ることができる。ＥＰＯＣ３２ではこれはもはや必要ない。なぜなら、ディスクリプタが参照されるデータの長さを定義する記述を含んでいるからである。従って、各テキスト項目毎に終端を示すのに「０」を使用する必要がなくなるので、更にまたコードの節約となる。
【００４８】
ディスクリプタの特徴の要約
ディスクリプタには３つのクラスがある。すなわち、ポインタディスクリプタ、バッファディスクリプタおよびヒープディスクリプタである。
・ポインタディスクリプタには２つの形態がある。不変ポインタディスクリプタ ＴＰｔｒＣ と可変ポインタディスクリプタＴＰｔｒである。
【００４９】
・不変ポインタディスクリプタ：ＴＰｔｒＣ
・これによりデータは変更できない。
・全てのメンバ関数が一定。
・不変ストリングまたはデータ（例えば変更されてはいけないデータ）
・ＴＤｅｓＣ から導出され、従って多数のメンバ関数を有する。
【００５０】
・可変ポインタディスクリプタ：ＴＰｔｒ
・設計者によって設定された最大長を越えない範囲で、このディスクリプタによってデータを変更できる。
・変更されている領域を含むメモリ領域を直接指し示す。
・ポインタ長により含まれるデータ項目数が決定される。
・全てのＴＤｅｓＣ メンバ関数に加えデータの変更および操作のためのＴＤｅｓ    ・ポインタディスクリプタはデータ表現とは別であるが、メモリ内の予め存在する領域から構成される。
【００５１】
・バッファディスクリプタには２つの形態がある。
【００５２】
・不変バッファディスクリプタ：Ｔｂｕｆ＜；ＴｉｎｔＳ＞；
・作成時または後で代入演算子（演算子＝）により、ディスクリプタにデータを設定できる。
・整数テンプレートにより長さが定義される。すなわち、ＴＢｕｆＣ＜；４０＞；は４０のデータ項目を含んでいる。
・全てのＴＤｅｓＣ メンバ関数を継承する。
【００５３】
・可変バッファデイスクリプタ：Ｔｂｕｆ＜；ＴｉｎｔＳ＞；
・最大長を越えない範囲で変更できるデータを含んでいる。
・最大長が最大データ項目数を定義する。
・実際の長さが実際のデータ項目数を定義する。
・整数テンプレートにより長さが定義される。すなわち、ＴＢｕｆ＜；４０＞；は４０のデータ項目だけを含んでいる。
・データ領域はディスクリプタオブジェクトの一部である。
・操作および変更の必要なデータを含めるのに有効であるが、その長さは既知の最大値（例えばＷＰテキスト）を越えない。
・全てのＴＤｅｓＣ メンバ関数に加えデータの変更および操作のためのＴＤｅｓメンバ関数を継承する。
【００５４】
・ヒープディスクリプタは１つの形態だけである。
・不変ヒープディスクリプタ：ＨＢｕｆＣ
・データと連続した長さを有する。
・データ領域はディスクリプタオブジェクトの一部であり、オブジェクト全体はヒープから割り当てられたセルを占める。
・作成時または後で代入演算子（演算子＝）により、ディスクリプタにデータを設定できる。
・全てのＴＤｅｓＣ メンバ関数を継承する。
・再割り当て可能、すなわち、データ領域は拡張および縮小できる。
【００５５】
付録１
Ｐｓｌｏｎ Ｓｏｆｔｗａｒｅ Ｐｌｃ．から１９９７年に発行されることになっているＥＰＯＣ３２「ディスクリプタ」ＳＤＫ（抜粋）。Ｐｓｌｏｎ Ｓｏｆｔｗａｒｅ Ｐｌｃ．から１９９７年７月（改訂１．０）に発行されたＳＤＫ全文を参照する。
【００５６】
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
ＳＤＫ：ディスクリプタ概要
ディスクリプタクラスの３重構造（主に、ポインタディスクリプタクラス、バッファディスクリプタクラスおよびヒープディスクリプタクラス）は、ストリングおよび一般的バイナリデータの両方に、それらが存在するメモリのタイプに関係なく、安全かつ一貫したアクセスおよび操作のための機構を提供する。例えば、ＲＯＭ内のコード部分のストリングを、ＲＡＭ内のファイルレコードと同様に扱える。
【００５７】
ディスクリプタによって表わされるデータは、メモリ内の定められた位置のデータ領域にある。このデータ領域は拡張できない。ディスクリプタデータの操作は、定められたデータ領域外の偶発的あるいは故意のメモリアクセスが許されないという意味で安全である（一般的に、無効なアクセスを行うコードは、（通常パニックとして知られる）例外の原因となる）。
【００５８】
ディスクリプタは、表わされたデータのタイプで区別をしないので、ストリングおよびバイナリデータの両方は同様に扱われる。ディスクリプタオブジェクトのメンバ関数のあるものはテキストデータを操作するように設計されているにもかかわらず、それらはバイナリデータにも作用する。これによりストリングおよびバイナリデータの扱いを統一し、コードを共有できるようにして効率を高める。
【００５９】
ディスクリプタクラスはいくつかの重要な用件を満足する：
・ユニコードおよびアスキーテキスト両方のサポートを提供する。マクロ ＵＮＩＣ０ＤＥは、アスキーまたはユニコードで作成された変数を選択するのに使用される。
・ストリングおよびバイナリデータの扱いを統一する。
・ＲＯＭ内のテキストまたはデータの安全かつ便利な参照を可能にする。
・関連するテキストまたはデータを操作する多くのメンバ関数を提供する。
・データの変更を可能とするが、定められたデータ領域外へ書き込もうとするあらゆる試みを防止する。
・仮想関数に関連するメモリオーバヘッドをなくす。
・組み込みタイプのように作用し、スタック上に安全に作成され、安全に孤立化（ｏｒｐｈａｎｅｄ）され得る。
・（ＨＢｕｆＣ がヒープ上に割り当てられ、規則の例外となる。）。
【００６０】
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
アスキーおよびユニコードテキスト
Ｅ３２．ディスクリプタ文字セット
アスキーテキスト文字は８ビット（１バイト）で表わされるが、ユニコード文字は１６ビット（２バイト）を必要とする。アスキーおよびユニコードテキストの両方をサポートするために、ディスクリプタクラスは、８ビットと１６ビットの２つの変形を有する。例えば、ＴＰｔｒ８ およびＴＰｔｒ１６ の２つのポインタディスクリプタクラスがある。
【００６１】
プログラムを、作成された変数から独立したクラスネームを使用してユニコードまたはアスキーテキストのいずれかをサポートするように構成できる。例えば、ディスクリプタクラスＴＰｔｒ を使用して、ＴＰｔｒ８ またはＴＰｔｒ１６ のいずれかを使用するようにシステムを構成できる。マクロ ＵＮＩＣ０ＤＥ が定義されたか否かによって、作成時（ｂｕｉｌｄ ｔｉｍｅ）に決定される。
【００６２】
ヘッダファイルＥ３２３２ｄｅｆ．ｈ（ＳＤＫの付録１参照）から抽出した次のコードは、変数から独立したクラスネームを適切に定義することによって実現する方法を示している。
【００６３】
＃ｉｆ ｄｅｆｉｎｅｄ（ＵＮＩＣＯＤＥ）
・・・
ｔｙｐｅｄｅｆ ＴＰｔｒ１６ ＴＰｔｒ；
・・・
＃ｅｌｓｅ
・・・
ｔｙｐｅｄｅｆ ＴＰｔｒ８ ＴＰｔｒ；
・・・
＃ｅｎｄｉｆ
【００６４】
アプリケーションコードには、「Ｃ」スタイルのストリングリテラルを直接使用しないようにすべきである。その代わり、適切な幅の「Ｃ」スタイルのストリングを生成するのに、適切なタイプのポインタに戻す、マクロ Ｓを使用すべきである。また、適切なタイプのディスクリプタを作成するには、マクロ Ｌ（「リテラル」に対する Ｌ）を使用すべきである。これらのマクロの定義については、ｅ３２．ｍａｃｒｏ．＿Ｓおよびｅ３２．ｍａｃｒｏ．＿Ｌを参照せよ。
【００６５】
例えば、
ｃｏｎｓｔ ＴＴｅｘｔ＊ｓｔｒ＝＿Ｓ（“Ｈｅｌｌｏ”）；
は、アスキーで作成された１バイト文字のストリングを生成するが、ユニコード作成では２バイト文字のストリングを生成する。
【００６６】
＿Ｌ（“Ｈｅｌｌｏ”）；
は、アスキーで作成された８ビットディスクリプタおよびユニコードで作成された１６ビットディスクリプタを生成する。常に正しい変数のディスクリプタを作成するように、例えば、平文“ａｂｃｄｅｆ”ではなく、常に＿Ｌ（“ａｂｃｄｅｆ”）を使用する。
【００６７】
ｍａｃｒｏ＿Ｓ８およびｍａｃｒｏ＿Ｌ８をそれぞれ使用することによって、作成された変数とは独立して、８ビット「Ｃ」スタイルストリングおよび８ビットポインタディスクリプタが明白に生成される。対応する１６ビットのバージョン、＿Ｓ１６および＿Ｌ１６も使用できる。これらの定義については、ｅ３２．ｍａｃｒｏ．＿Ｓ８， ｅ３２．ｍａｃｒｏ．＿Ｌ８， ｅ３２．ｍａｃｒｏ．＿Ｓ１６ および ｅ３２．ａｍｃｒｏ．＿Ｌ１６を参照せよ。
【００６８】
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
長さおよびサイズ
Ｅ３２３２．ディスクリプタ長さおよびサイズ
ディスクリプタは、表わすデータをそのデータの長さで特徴付ける。ディスクリプタの長さは、データ項目の数である。８ビットの変数に対しては、ディスクリプタの長さはそれが表わす１バイトデータの数であり、１６ビットの変数に対しては、ディスクリプタの長さはそれが表わす２バイトデータの数である。
【００６９】
ディスクリプタのサイズよ、ディスクリプタのデータが占めるバイト数であり、ディスクリプタの長さと同じである必要はない。８ビットの変数に対しては、サイズは長さと同じであり、１６ビットの変数に対しては、サイズは長さの２倍である。データが変更されていることを許可するディスクリプタもまた、その最大長によって特徴付けられる。これらのディスクリプタに対しては、表わされるデータの長さは、ゼロからこの最大値まで最大値と共に変化し得る。あらゆるディスクリプタの最大長は２２８である。
【００７０】
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
テキストおよびバイナリデータ
Ｅ３２３２．ディスクリブタテキストおよびバイナリ
「Ｃ」では、ストリングスは、ストリングの終端を示すゼロターミネータを必要とすることによって特徴付けられる。これらは多数の問題を招く。特に、これらは（データがバイナリゼロを含む場合に）バイナリデータを中に含むことができず、それらに対する操作は一般的に効率的でない。「Ｃ」ストリングスは、ＡＮＳＩの「Ｃ」ライブラリの関数グループ、ｍｅｍｘｘｘ（）およびｓｔｒｘｘｘ（）に反映されているように、バイナリデータとは異なった方法で扱う必要がある。ディスクリプタはストリングとバイナリデータを同じ方法で表わすことを可能とし、これは両方の場合に同じ関数を使用することを可能とする。バイナリデータに対しては、明示的に８ビットのディスクリプタを使用しなければならない。バイナリデータにとっては、ユニコードをアスキーの区別は意味がない。１６ビットバイナリデータは事実上使用しないことに注意せよ。
【００７１】
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
メモリ割り当て
Ｅ３２３２．ディスクリプタ割り当て
ディスクリプタクラスは（ＨＢｕｆＣ を除いて）、組み込みタイプのように作用する。これらはメモリの割り当てを行わず、デストラクタを持たない。これは、ディスクリプタクラスが組み込みタイプと同様にスタック上で孤立化され得ることを意味する。これは特に、コードを残せる状況では重要である。（孤立化の影響については、Ｅ３２３２．例外トラップ．クリーンアップ．用件を参照せよ）
ＨＢｕｆＣディスクリプタオブジェクトはヒープ上に割り当てられ、スタック上には作成されない。
【００７２】
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
例外
Ｅ３２３２．ディスクリプタ例外
ディスクリプタメンバ関数の全てのパラメータは、操作が正しく指定され、どのデータもディスクリプタのデータ領域外に書き込まれないことを保証するべく検査される。特定の結果は、どのメンバ関数も、可変ディスクリプタをその最大割り当て長を越えて拡張できないこととなる。元の割り当てを十分大きくするか、より大きいディスクリプタの必要性を見越して実行時により大きなディスクリプタを動的に割り当てるかによって、全てのディスクリプタがデータを収容できるように十分大きいことを保証するのは、プログラマの責任である。スタティックな手法は実施がより簡単であるが、これが無駄であると判明した特定の場合には、動的手法がより効果的であろう。例外の場合には、どんな認められていないメモリのアクセスも実行しないこと、およびどんなデータも移動または損傷されないことが安全であると考えられている。
【００７３】
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
ディスクリプタタイプ
Ｅ３２３２．ディスクリプタタイプ
ディスクリプタオブジェクトには３種類ある。
【００７４】
すなわち、
・ポインタディスクリプタ
ディスクリプタオブジェクトは、それが表わすデータとは別であるが、メモリ内の予め存在する領域に生成される。これには、
不変ポインタディスクリプタ、ＴＰｔｒＣ
可変ポインタディスクリプタ、ＴＰｔｒ
の２つの形態がある。
【００７５】
・バッファディスクリプタ
データ領域はディスクリプタオブジェクトの一部である。これには、
不変バッファディスクリプタ、ＴＢｕｆＣ＜；ＴｌｎｔＳ＞；
可変バッファディスクリプタ、ＴＢｕｆ＜；ＴｌｎｔＳ＞；
の２つの形態がある。
【００７６】
・ヒープディスクリプタ
データ領域はディスクリプタオブジェクトの一部であり、オブジェクト全体がヒープから割り当てられたセルを占有する。これは、
不変ヒープディスクリプタ、ＨＢｕｆＣ
の１つの形態だけである。
【００７７】
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
ポインタディスクリプタ−ＴＰｔｒＣ
Ｅ３２３２．ディスクリプタポインタディスクリプタ．ＴＰｔｒＣ
ＴＰｔｒＣ は、それによってどのデータも変更されない、不変ディスクリプタである。そのメンバ関数の全ては（コンストラクタを除いて）不変（ｃｏｎｓｔａｎｔ）である。図１にＴＰｔｒＣ が概略的に示されている。ＴＰｔｒＣ は不変ストリングまたはデータを参照する、例えば、ＲＯＭ常駐コード中に生成されたテキストをアクセスするとき、またはその参照によってデータが変更されてはならないＲＡＭ内のデータに参照を渡すときに有効である。ＴＰｔｒＣ は、例えば、テキストまたはデータの抽出部分内の文字の位置決めなどの、その内容を操作する多くのメンバ関数を提供するＴＤｅｓＣ から導出される。
【００７８】
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
ポインタディスクリプタ−ＴＰｔｒ
Ｅ３２３２．ディスクリプタ．ポインタディスクリプタ．ＴＰｔｒ
ＴＰｔｒ は、データが最大長を越えない範囲で、それによってデータを変更できるポインタディスクリプタである。最大長はコンストラクタによって設定される。
ＴＰｔｒ は、変更されているデータを含むメモリ内の領域を直接指し示す。ＴＰｔｒ は、図２Ａおよび２Ｂに概略的に示されている。
【００７９】
領域が含むことができるデータ項目の最大数は、最大長で定義される。ＴＰｔｒは、データ内に現在いくつのデータ項目が含まれているかを表わす。この値が最大値より小さいとき、データ領域の一部は未使用である。ＴＰｔｒ は、参照により変更されているよう意図されたデータを含むＲＡＭの領域、またはまだデータがないが、ディスクリプタの参照およびメンバ関数を使用してデータが生成されるＲＡＭの領域への参照を生成するのに有効である。
【００８０】
ＴＰｔｒ はまた、変更されているデータを含む、ＴＢｕｆＣ またはＨＢｕｆＣ ディスクリプタへの参照を生成するのに有効である。このように使用されるＴＰｔｒ は、ＴＢｕｆＣ またはＨＢｕｆＣ ディスクリプタを指し示す。ＴＢｕｆＣ またはＨＢｕｆＣ ディスクリプタに含まれるデータはＴＰｔｒ によって変更することができる。ＴＰｔｒ は、ＴＤｅｓＣ から導出されたＴＤｅｓ から導出される。従って、ＴＰｔｒ は、ＴＤｅｓＣ で定義された全てのｃｏｎｓｔ メンバ関数に加え、例えば、既存のテキストの末端に文字を付加する等の、データの操作および変更が可能なＴＤｅｓ のメンバ関数を継承している。
【００８１】
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
バッファディスクリプタ−ＴＢｕｆＣ＜；ＴＩｎｔ Ｓ＞；
Ｅ３２３２．ディスクリプタ．バッフアディスクリプタ．ＴＢｕｆＣ
ＴＢｕｆＣ は、データ領域が続く長さを有するバッファディスクリプタである。データは、生成時にまたは他のあらゆるときに割り当てられた演算子（演算子＝）によって、ディスクリプタ内に設定される。ディスクリプタによって保持されたデータは不変である。ＴＢｕｆＣ は、図３に概略的に示されている。ＴＢｕｆＣ の長さは、例えば、ＴＢｕｆＣ＜；４０＞；が４０までのデータ項目を含むことができるＴＢｕｆＣ を定義するように、整数テンプレートによって定義される。
【００８２】
ＴＢｕｆＣ は、例えばテキストまたはデータの抽出部分内の文字の位置を決める、その内容物を操作する多くのメンバ関数を提供するＴＤｅｓＣ から導出される。ＴＢｕｆＣ は、ＴＢｕｆＣ を参照する可変ポインタディスクリプタ（ＴＰｔｒ）を作成する、メンバ関数Ｄｅｓ（）を提供する。これにより、図４に概略的に表わしたように、ＴＰｔｒによってＴＢｕｆＣ のデータを変更することができる。ＴＰｔｒ の最大長は、整数テンプレートパラメータの値である。
【００８３】
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
バッファディスクリプタ−ＴＢｕｆ＜；ＴＩｎｔ Ｓ＞；
Ｅ３２３２．ディスクリプタ．バッファディスクリプタ．ＴＢｕｆ
ＴＢｕｆ は、データが最大長を越えない範囲で、変更できるデータを含むバッファディスクリプタである。図５にＴＢｕｆ が概略的に示されている。ＴＢｕｆ が内部のデータ領域に含むことができるデータ項目の数は、最大長によって定義される。
【００８４】
ディスクリプタの長さは、データ領域に現在いくつのデータ項目が含まれているかを表わしている。この値が最大値より小さいとき、データ領域のある部分は未使用である。ＴＢｕｆ の最大長は、例えば、ＴＢｕｆ＜；４０＞；が４０までの（かつ越えない！）データ項目を含むことができるＴＢｕｆ を定義するように、整数テンプレートによって定義される。ＴＢｕｆ は、例えばワードプロセッサのテキスト等の、操作および変更が必要であるが、その長さが既知の最大値を越えないデータを収容するのに有効である。ＴＢｕｆ は、ＴＤｅｓＣ から導出されたＴＤｅｓ から導出される。
【００８５】
従って、ＴＰｔｒ は、ＴＤｅｓＣ で定義された全てのｃｏｎｓｔ メンバ関数に加え、例えば、既存のテキストの末端に文字を付加する等の、データの操作および変更が可能なＴＤｅｓ のメンバ関数を継承している。
【００８６】
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
ヒープディスクリプタ−ＨＢｕｆＣ
Ｅ３２３２．ディスクリプタ．ヒ−プディスクリプタ．ＨＢｕｆＣ
ＨＢｕｆＣ は、データ領域が続く長さを有するディスクリプタである。スタティックメンバ関数、Ｎｅｗ（）、ＮｅｗＬ（）またはＮｅｗＬＣ（）を使用してヒープ上に割り当てられる。ディスクリプタの長さはこれらスタティック関数へのパラメータとして渡される。図６にＨＢｕｆＣ が概略的に示されている。データは、生成時にまたは他のあらゆるときに割り当てられた演算子（演算子＝）によって、ディスクリプタ内に設定される。ＨＢｕｆＣ は、例えばテキストまたはデータの抽出部分内の文字の位置を決める、その内容物を操作する多くのメンバ関数を提供するＴＤｅｓＣ から導出される。
【００８７】
ＨＢｕｆＣ は、ＨＢｕｆＣ を参照する可変ポインタディスクリプタ（ＴＰｔｒ）を作成する、メンバ関数Ｄｅｓ（）を提供する。ＴＰｔｒ の最大長は、ＨＢｕｆＣ データ領域の長さである。図７はこれを概略的に示している。
【００８８】
ヒープディスクリプタは再配置することができる。関数ＲｅＡｌｌｏｃ（）またはＲｅＡｌｌｏｃＬ（）は、ヒープディスクリプタのデータ領域の拡張あるいは縮小を可能にする。しかしながら、データ領域の長さは、現在保持しているデータの長さより短くすることはできない。データ領域を縮小する前に、ディスクリプタが保持するデータを減少させなければならない。割り当て演算子がヒープディスクリプタ中に設定できるデータの長さは、ディスクリプタのデータ領域に割り当てられたスペースに制限される。ヒープディスクリプタによって占有されたメモリは、Ｕｓｅｒ：：Ｆｒｅｅ（）のコールまたはキーワードｄｅｌｅｔｅを使用して明示的に開放する必要がある。
【００８９】
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
ディスクリプタクラスの継承・派生関係
Ｅ３２．ディスクリプタ．クラス
全てのディスクリプタクラス、ＴＰｔｒＣ，ＴＰｔｒ，ＴＢｕｆＣ，ＴＢｕｆおよびＨＢｕｆＣ は、抽象的基底クラス（ａｂｓｔｒａｃｔ ｂａｓｅ ｃｌａｓｓ）ＴＤｅｓＣ およびＴＤｅｓ から導出される。
【００９０】
クラスＴＢｕｆＣＢａｓｅ を抽象的基底クラスとして示したが、これは単に実施が容易なためである。図８はクラス間の関係を概略的に示している。
【００９１】
実際のディスクリプタクラスの作用は非常に似ており、従って、ディスクリプタのほとんどの関数は抽象的基底クラスによって提供される。ディスクリプタは（特にスタックで）広く使用されるので、ディスクリプタオブジェクトのサイズを最小にする必要がある。これを補助するように、各ディスクリプタオブジェクトにおいて仮想関数テーブルポインタのオーバーへッドをなくすため、仮想関数の定義をしない。その結果、基底クラスはそこから導出されるクラスの知識を潜在的に持っている。
【００９２】
Ｅ３２は、８ビット（アスキー）テキストおよびバイナリデータを扱うものと、１６ビット（ユニコード）テキストを扱うものとの２つのディスクリプタクラスの変数を供給する。実際のクラスの８ビット変数は、ＴＰｔｒＣ８，ＴＰｔｒ８，ＴＢｕｆＣ８＜；ＴＩｎｔ Ｓ＞；，ＴＢｕｆ８＜；ＴＩｎｔ Ｓ＞；およびＨＢｕｆＣ８であり、抽象クラスの８ビット変数は、ＴＤｅｓＣ８ およびＴＤｅｓ８ である。同様に、１６ビット変数の名前はそれぞれ、ＴＰｔｒＣ１６，ＴＰｔｒ１６，ＴＢｕｆＣ１６＜；Ｔｌｎｔ Ｓ＞；，ＴＢｕｆ１６＜；ＴＩｎｔＳ＞；，ＨＢｕｆＣ８，ＴＤｅｓＣ１６およびＴＤｅｓ１６である。
【００９３】
この区別はテキストを表わすのに使用されるディスクリプタにはトランスペアレントである。ＴＰｔｒＣ，ＴＰｔｒ，ＴＢｕｆＣ＜；ＴＩｎｔ Ｓ＞；，ＴＢｕｆ＜；ＴＩｎｔ Ｓ＞；およびＨＢｕｆＣクラスを生成し使用するプログラムを書くことにより、ユニコードおよびアスキーの両方に対する互換性が維持される。マクロ＿ＵＮＩＣ０ＤＥが定義されたか否かに応じて、構成時に適切な変数が選択される。マクロ＿ＵＮＩＣ０ＤＥが定義されていると１６ビット変数が変数が使用され、そうでなければＥ３２．ディスクリプタ．文字セットで説明したように８ビットの変数が使用される。
【００９４】
バイナリデータのディスクリプタは、明示的に８ビット変数を使用する必要があり、換言すると、コードは明示的に ＴＰｔｒＣ８，ＴＰｔｒ８，ＴＢｕｆＣ８＜；ＴＩｎｔ Ｓ＞；，ＴＢｕｆ８＜；ＴＩｎｔ Ｓ＞；およびＨＢｕｆＣ８のクラスを生成する。
【００９５】
バイナリデータに対して１６ビット変数を明示的に使用することもできるが、勧められない。一般に、８ビットおよび１６ビットの変数は、構造および実施において同一であり、クラス自体の記述は全体に渡り構成とは独立した名前を使用する。
【００９６】
多くのメンバ関数が、ディスクリプタが８ビットか１６ビットの変数であるかに応じて、ＴＵｉｎｔ８＊タイプまたはＴＵｉｎｔ１６＊タイプの引数を取ることに特に注意せよ。説明を単純にするため、これらの引数を関数プロトタイプＴＵｉｎｔ？？＊として記載する。
【図面の簡単な説明】
【００９７】
【図１】ＴＰｔｒＣの概略を示す図である。
【図２】ＴＰｔｒの概略を示す図である。
【図３】ＴＢｕｆＣの概略を示す図である。
【図４】ＴＰｔｒとＴＢｕｆＣの関係を示す図である。
【図５】ＴＢｕｆＣの概略を示す図である。
【図６】ＨＢｕｆＣの概略を示す図である。
【図７】ＴＰｔｒとＨＢｕｆＣの関係を示す図である。
【図８】クラス間の継承・派生の関係を示す図である。
【図１】
2006302303.tif 000003
【図２】
2006302303.tif 000004
【図３】
2006302303.tif 000005
【図４】
2006302303.tif 000006
【図５】
2006302303.tif 000007
【図６】
2006302303.tif 000008
【図７】
2006302303.tif 000009
【図８】
2006302303.tif 000010
【手続補正書】
【提出日】平成18年6月27日(2006.6.27)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
オブジェクト指向オペレーティングシステムを用いて、データ参照のためのメンバ関数を定義する単一のベースクラスから派生され、階層構造を有する５つのストリングクラスのオブジェクトを操作又はアクセスすることができるようにプログラムされたコンピュータ装置であって、
リードオンリーメモリと、
ランダムアクセスメモリと、
（ａ）前記ベースクラスから派生され、前記リードオンリーメモリ又は前記ランダムアクセスメモリのうちヒープ領域以外のメモリ領域に格納されたリテラルテキストを処理するための第１のストリングクラスに属するオブジェクトについては、ポインタを利用して、該リテラルテキストが格納されたオリジナルのメモリ領域にアクセスして処理する手段と、
（ｂ）前記データ参照のためのメンバ関数に加えデータの追加及び変更を可能とするメンバ関数を定義する前記ベースクラスの派生クラスから派生され、前記ランダムアクセスメモリのうちヒープ領域以外のメモリ領域に格納されたテキストを処理するための第２のストリングクラスに属するオブジェクトについては、ポインタを利用して、該テキストが格納されたオリジナルのメモリ領域にアクセスして処理する手段と、
（ｃ）前記ベースクラスから派生され、長さが制限されたテキストを処理するための第３のストリングクラスに属するオブジェクトについては、メモリ管理関数の限定されたサブセットを利用して、前記ランダムアクセスメモリのうちヒープ領域以外のメモリ領域に格納して処理する手段と、
（ｄ）前記第３のストリングクラスから派生され、長さが制限されたテキストを処理するための第４のストリングクラスに属するオブジェクトについては、前記データ参照のためのメンバ関数に加えデータの追加及び変更を可能とするメンバ関数を利用して、前記ランダムアクセスメモリのうちヒープ領域以外のメモリ領域に格納して処理する手段と、
（ｅ）前記ベースクラスから派生され、長さが動的に変化し得るテキストを処理するための第５のストリングクラスに属するオブジェクトについては、メモリ管理関数のフルセットを利用して、前記ランダムアクセスメモリのうちヒープ領域に格納して処理する手段と
を含むことを特徴とするコンピュータ装置。
【請求項２】
オブジェクト指向オペレーティングシステムを用いて、データ参照のためのメンバ関数を定義する単一のベースクラスから派生され、階層構造を有する５つのストリングクラスのオブジェクトを、リードオンリーメモリ、ランダムアクセスメモリおよびマイクロプロセッサを有するコンピュータ装置によって操作又はアクセスできるようにする方法であって、
（ａ）前記ベースクラスから派生され、前記リードオンリーメモリ又は前記ランダムアクセスメモリのうちヒープ領域以外のメモリ領域に格納されたリテラルテキストを処理するための第１のストリングクラスに属するオブジェクトについては、ポインタを利用して、該リテラルテキストが格納されたオリジナルのメモリ領域にアクセスして処理し、
（ｂ）前記データ参照のためのメンバ関数に加えデータの追加及び変更を可能とするメンバ関数を定義する前記ベースクラスの派生クラスから派生され、前記ランダムアクセスメモリのうちヒープ領域以外のメモリ領域に格納されたテキストを処理するための第２のストリングクラスに属するオブジェクトについては、ポインタを利用して、該テキストが格納されたオリジナルのメモリ領域にアクセスして処理し、
（ｃ）前記ベースクラスから派生され、長さが制限されたテキストを処理するための第３のストリングクラスに属するオブジェクトについては、メモリ管理関数の限定されたサブセットを利用して、前記ランダムアクセスメモリのうちヒープ領域以外のメモリ領域に格納して処理し、
（ｄ）前記第３のストリングクラスから派生され、長さが制限されたテキストを処理するための第４のストリングクラスに属するオブジェクトについては、前記データ参照のためのメンバ関数に加えデータの追加及び変更を可能とするメンバ関数を利用して、前記ランダムアクセスメモリのうちヒープ領域以外のメモリ領域に格納して処理し、
（ｅ）前記ベースクラスから派生され、長さが動的に変化し得るテキストを処理するための第５のストリングクラスに属するオブジェクトについては、メモリ管理関数のフルセットを利用して、前記ランダムアクセスメモリのうちヒープ領域に格納して処理する
ことを特徴とする方法。
【請求項３】
オブジェクト指向オペレーティングシステムを用いて、データ参照のためのメンバ関数を定義する単一のベースクラスから派生され、階層構造を有する５つのストリングクラスのオブジェクトを、リードオンリーメモリ、ランダムアクセスメモリおよびマイクロプロセッサを有するコンピュータ装置によって操作又はアクセスできるようにするためのコンピュータプログラムを格納した記憶媒体であって、
前記コンピュータプログラムは、
（ａ）前記ベースクラスから派生され、前記リードオンリーメモリ又は前記ランダムアクセスメモリのうちヒープ領域以外のメモリ領域に格納されたリテラルテキストを処理するための第１のストリングクラスに属するオブジェクトについては、ポインタを利用して、該リテラルテキストが格納されたオリジナルのメモリ領域にアクセスして処理する手段と、
（ｂ）前記データ参照のためのメンバ関数に加えデータの追加及び変更を可能とするメンバ関数を定義する前記ベースクラスの派生クラスから派生され、前記ランダムアクセスメモリのうちヒープ領域以外のメモリ領域に格納されたテキストを処理するための第２のストリングクラスに属するオブジェクトについては、ポインタを利用して、該テキストが格納されたオリジナルのメモリ領域にアクセスして処理する手段と、
（ｃ）前記ベースクラスから派生され、長さが制限されたテキストを処理するための第３のストリングクラスに属するオブジェクトについては、メモリ管理関数の限定されたサブセットを利用して、前記ランダムアクセスメモリのうちヒープ領域以外のメモリ領域に格納して処理する手段と、
（ｄ）前記第３のストリングクラスから派生され、長さが制限されたテキストを処理するための第４のストリングクラスに属するオブジェクトについては、前記データ参照のためのメンバ関数に加えデータの追加及び変更を可能とするメンバ関数を利用して、前記ランダムアクセスメモリのうちヒープ領域以外のメモリ領域に格納して処理する手段と、
（ｅ）前記ベースクラスから派生され、長さが動的に変化し得るテキストを処理するための第５のストリングクラスに属するオブジェクトについては、メモリ管理関数のフルセットを利用して、前記ランダムアクセスメモリのうちヒープ領域に格納して処理する手段と
を前記コンピュータ装置に機能させることを特徴とする記憶媒体。
【請求項４】
オブジェクト指向オペレーティングシステムを用いてストリングクラスのオブジェクトを操作又はアクセスすることができるようにプログラムされたコンピュータ装置であって、
単一のベースクラスから、前記ストリングクラスのオブジェクトとして
（ａ）  リテラルテキスト用の前記ストリングクラスのオブジェクトと、
（ｂ）  長さが制限されたテキスト用の前記ストリングクラスのオブジェクトと、
（ｃ）  ヒープメモリを使用する前記ストリングクラスのオブジェクトと
が導出される場合に、
前記コンピュータ装置は、
前記リテラルテキスト用の前記ストリングクラスのオブジェクトを、ヒープメモリにテキストストリングを複製する必要を無くすため、コンパイルで定められポインタにより指し示されたオリジナルのメモリ位置に該テキストストリングを格納するクラスに属するオブジェクトとして処理する手段と、
前記長さが制限されたテキスト用の前記ストリングクラスのオブジェクトを、所定長のテキストを格納するデータ領域を含み、実行時にヒープメモリの一部ではないメモリ位置に格納されるクラスに属するオブジェクトとして処理する手段と、
前記ヒープメモリを使用する前記ストリングクラスのオブジェクトを、利用可能なメモリ管理関数のフルセットを必要とするクラスに属するオブジェクトとして処理する手段と
を含むことを特徴とするコンピュータ装置。
【請求項５】
ストリングクラスのオブジェクトを、コンピュータ装置によって操作又はアクセスすることができるようにする方法であって、
単一のベースクラスから、前記ストリングクラスのオブジェクトとして
（ａ）  リテラルテキスト用の前記ストリングクラスのオブジェクトと、
（ｂ）  長さが制限されたテキスト用の前記ストリングクラスのオブジェクトと、
（ｃ）  ヒープメモリを使用する前記ストリングクラスのオブジェクトと
が導出される場合に、
前記コンピュータ装置は、
前記リテラルテキスト用の前記ストリングクラスのオブジェクトを、ヒープメモリにテキストストリングを複製する必要を無くすため、コンパイルで定められポインタにより指し示されたオリジナルのメモリ位置に該テキストストリングを格納するクラスに属するオブジェクトとして処理し、
前記長さが制限されたテキスト用の前記ストリングクラスのオブジェクトを、所定長のテキストを格納するデータ領域を含み、実行時にヒープメモリの一部ではないメモリ位置に格納されるクラスに属するオブジェクトとして処理し、
前記ヒープメモリを使用する前記ストリングクラスのオブジェクトを、利用可能なメモリ管理関数のフルセットを必要とするクラスに属するオブジェクトとして処理する
ことを特徴とする方法。
【請求項６】
ストリングクラスのオブジェクトを、コンピュータ装置によって操作又はアクセスすることができるようにするコンピュータプログラムを格納した記憶媒体であって、
単一のベースクラスから、前記ストリングクラスのオブジェクトとして
（ａ）  リテラルテキスト用の前記ストリングクラスのオブジェクトと、
（ｂ）  長さが制限されたテキスト用の前記ストリングクラスのオブジェクトと、
（ｃ）  ヒープメモリを使用する前記ストリングクラスのオブジェクトと
が導出される場合に、
前記コンピュータ装置上で動作する前記コンピュータプログラムは、
前記リテラルテキスト用の前記ストリングクラスのオブジェクトを、ヒープメモリにテキストストリングを複製する必要を無くすため、コンパイルで定められポインタにより指し示されたオリジナルのメモリ位置に該テキストストリングを格納するクラスに属するオブジェクトとして処理する手段と、
前記長さが制限されたテキスト用の前記ストリングクラスのオブジェクトを、所定長のテキストを格納するデータ領域を含み、実行時にヒープメモリの一部ではないメモリ位置に格納されるクラスに属するオブジェクトとして処理する手段と、
前記ヒープメモリを使用する前記ストリングクラスのオブジェクトを、利用可能なメモリ管理関数のフルセットを必要とするクラスに属するオブジェクトとして処理する手段と
を前記コンピュータ装置に機能させることを特徴とする記憶媒体。
【請求項７】
オブジェクト指向オペレーティングシステムを用いてストリングクラスのオブジェクトを操作又はアクセスすることができるようにプログラムされたコンピュータ装置であって、
単一のベースクラスから導出される前記ストリングクラスの全てのオブジェクトについて、
（ａ）  リテラルテキスト用の前記ストリングクラスのオブジェクトを、前記コンピュータ装置のヒープメモリにテキストストリングを複製する必要を無くすため、コンパイルで定められポインタにより指し示されたオリジナルのメモリ位置に該テキストストリングを格納するクラスに属するオブジェクトとして操作又はアクセスする手段と、
（ｂ）  長さが制限されたテキスト用の前記ストリングクラスのオブジェクトを、所定長のテキストを格納するデータ領域を含み、実行時に前記コンピュータ装置のヒープメモリの一部ではないメモリ位置に格納されるクラスに属するオブジェクトとして操作又はアクセスする手段と、
（ｃ）  前記コンピュータ装置のヒープメモリを使用する前記ストリングクラスのオブジェクトを、利用可能なメモリ管理関数のフルセットを必要とするクラスに属するオブジェクトとして操作又はアクセスする手段と
を含むことを特徴とするコンピュータ装置。
【請求項８】
ストリングクラスのオブジェクトを、コンピュータ装置によって操作又はアクセスすることができるようにする方法であって、
前記コンピュータ装置のプロセッサが、単一のベースクラスから導出される前記ストリングクラスの全てのオブジェクトについて、
（ａ）  リテラルテキスト用の前記ストリングクラスのオブジェクトを、前記コンピュータ装置のヒープメモリにテキストストリングを複製する必要を無くすため、コンパイルで定められポインタにより指し示されたオリジナルのメモリ位置に該テキストストリングを格納するクラスに属するオブジェクトとして操作又はアクセスし、
（ｂ）  長さが制限されたテキスト用の前記ストリングクラスのオブジェクトを、所定長のテキストを格納するデータ領域を含み、実行時に前記コンピュータ装置のヒープメモリの一部ではないメモリ位置に格納されるクラスに属するオブジェクトとして操作又はアクセスし、
（ｃ）  前記コンピュータ装置のヒープメモリを使用する前記ストリングクラスのオブジェクトを、利用可能なメモリ管理関数のフルセットを必要とするクラスに属するオブジェクトとして操作又はアクセス
することを特徴とする方法。
【請求項９】
ストリングクラスのオブジェクトを、コンピュータ装置によって操作又はアクセスすることができるようにするコンピュータプログラムを格納した記憶媒体であって、
前記コンピュータプログラムは、
単一のベースクラスから導出される前記ストリングクラスの全てのオブジェクトについて、
（ａ）  リテラルテキスト用の前記ストリングクラスのオブジェクトを、前記コンピュータ装置のヒープメモリにテキストストリングを複製する必要を無くすため、コンパイルで定められポインタにより指し示されたオリジナルのメモリ位置に該テキストストリングを格納するクラスに属するオブジェクトとして操作又はアクセスする手段と、
（ｂ）  長さが制限されたテキスト用の前記ストリングクラスのオブジェクトを、所定長のテキストを格納するデータ領域を含み、実行時に前記コンピュータ装置のヒープメモリの一部ではないメモリ位置に格納されるクラスに属するオブジェクトとして操作又はアクセスする手段と、
（ｃ）  前記コンピュータ装置のヒープメモリを使用する前記ストリングクラスのオブジェクトを、利用可能なメモリ管理関数のフルセットを必要とするクラスに属するオブジェクトとして操作又はアクセスする手段と
を前記コンピュータ装置に機能させることを特徴とする記憶媒体。
【請求項１０】
コンピュータ装置で動作するオブジェクト指向オペレーティングシステムの作成方法であって、
単一のベースクラスから導出される前記ストリングクラスの全てのオブジェクトについて、
（ａ）  リテラルテキスト用の前記ストリングクラスのオブジェクトを、前記コンピュータ装置のヒープメモリにテキストストリングを複製する必要を無くすため、コンパイルで定められポインタにより指し示されたオリジナルのメモリ位置に該テキストストリングを格納するクラスに属するオブジェクトとして操作又はアクセスするよう定義するステップと、
（ｂ）  長さが制限されたテキスト用の前記ストリングクラスのオブジェクトを、所定長のテキストを格納するデータ領域を含み、実行時に前記コンピュータ装置のヒープメモリの一部ではないメモリ位置に格納されるクラスに属するオブジェクトとして操作又はアクセスするよう定義するステップと、
（ｃ）  前記コンピュータ装置のヒープメモリを使用する前記ストリングクラスのオブジェクトを、利用可能なメモリ管理関数のフルセットを必要とするクラスに属するオブジェクトとして操作又はアクセスするよう定義するステップと
を含むことを特徴とするオブジェクト指向オペレーティングシステムの作成方法。
【請求項１１】
コンピュータ装置で動作するオブジェクト指向オペレーティングシステムの作成方法であって、
単一のベースクラスから導出される前記ストリングクラスの全てのオブジェクトについて、
（ａ）前記ベースクラスから派生され、前記リードオンリーメモリ又は前記ランダムアクセスメモリのうちヒープ領域以外のメモリ領域に格納されたリテラルテキストを処理するための第１のストリングクラスに属するオブジェクトについては、ポインタを利用して、該リテラルテキストが格納されたオリジナルのメモリ領域にアクセスして処理するよう定義するステップと、
（ｂ）前記データ参照のためのメンバ関数に加えデータの追加及び変更を可能とするメンバ関数を定義する前記ベースクラスの派生クラスから派生され、前記ランダムアクセスメモリのうちヒープ領域以外のメモリ領域に格納されたテキストを処理するための第２のストリングクラスに属するオブジェクトについては、ポインタを利用して、該テキストが格納されたオリジナルのメモリ領域にアクセスして処理するよう定義するステップと、
（ｃ）前記ベースクラスから派生され、長さが制限されたテキストを処理するための第３のストリングクラスに属するオブジェクトについては、メモリ管理関数の限定されたサブセットを利用して、前記ランダムアクセスメモリのうちヒープ領域以外のメモリ領域に格納して処理するよう定義するステップと、
（ｄ）前記派生クラスから派生され、長さが制限されたテキストを処理するための第４のストリングクラスに属するオブジェクトについては、メモリ管理関数の限定されたサブセットを利用して、前記ランダムアクセスメモリのうちヒープ領域以外のメモリ領域に格納して処理するよう定義するステップと、
（ｅ）前記ベースクラスから派生され、長さが動的に変化し得るテキストを処理するための第５のストリングクラスに属するオブジェクトについては、メモリ管理関数のフルセットを利用して、前記ランダムアクセスメモリのうちヒープ領域に格納して処理するよう定義するステップと
を含むことを特徴とするオブジェクト指向オペレーティングシステムの作成方法。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】００５２
【補正方法】変更
【補正の内容】
【００５２】
・不変バッファディスクリプタ：ＴｂｕｆＣ＜；ＴｉｎｔＳ＞；
・作成時または後で代入演算子（演算子＝）により、ディスクリプタにデータを設定できる。
・整数テンプレートにより長さが定義される。すなわち、ＴＢｕｆＣ＜；４０＞；は４０のデータ項目を含んでいる。
・全てのＴＤｅｓＣ メンバ関数を継承する。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】００５０
【補正方法】変更
【補正の内容】
【００５０】
・可変ポインタディスクリプタ：ＴＰｔｒ
・設計者によって設定された最大長を越えない範囲で、このディスクリプタによってデータを変更できる。
・変更されている領域を含むメモリ領域を直接指し示す。
・ポインタ長により含まれるデータ項目数が決定される。
・全てのＴＤｅｓＣ メンバ関数に加えデータの変更および操作のためのＴＤｅｓメンバ関数を継承する。
・ポインタディスクリプタはデータ表現とは別であるが、メモリ内の予め存在する領域から構成される。