JP4611245B2 - コンピュータ装置およびストリングクラスのオブジェクトを操作又はアクセスする方法 - Google Patents

Description

本発明は、コンピュータ用のオブジェクト指向オペレーティングシステムの改良に関する。本発明は特に、Ｃ＋＋プログラミング技法に基づいたオペレーティングシステムに関する。 このオペレーティングシステムの市場で入手可能な実施形態は、英国のＰｓｉｏｎ Ｓｏｆｔｗａｒｅ Ｐｌｃで製造されるＥＰＯＣ３２オペレーティングシステムである。ＥＰＯＣ３２はモバイルコンピュータ環境に適したオペレーティングシステムである。

Ｃ＋＋言語は、パーソナルコンピュータなどのコンピュータ用のアプリケーションプログラムを記述するのに広く使用されているが、オペレーティングシステムを記述するのには、まれにしか用いられていない。パーソナルコンピュータ用のオペレーティングシステムを記述するときには、通常、実行可能コードのサイズを最小化すること、あるいはプログラム内でステップを実行するのに必要なサイクル数を最小化するという用件は優先されない。一般的には、性能と記述の容易さがより重要な用件である。
とくになし

しかしながら、他の状況では、（例えば、それを格納するＲＯＭおよび／またはＲＡＭの容量を最少とするため）実行可能コードの占めるスペースを最小としなければならず、（例えば、消費電力を最少とするため）最小数のサイクルで実行する必要が生じる場合がある。

モバイルコンピューティング（例えば、パーソナルデジタル支援機器：ＰＤＡ）、スマートフォン（例えば、ワードプロセッサが組み込まれ、ファクシミリの送受信およびインターネットの閲覧が可能なＧＳＭセルラ電話）およびネットワークコンピュータ（ＮＣ）環境は、オペレーティングシステムのコードサイズを最小化することが利点となる環境の実例である。すなわち、最小化によって、主にハードウェア（特にＲＯＭおよび／またはＲＡＭ）のコストを削減することができる。広範囲に及ぶ消費材への適用は一般的に比較的低価格のハードウェアに依存しているので、この点は上記状況において特に重要である。同様に、モバイルコンピューティングおよびスマートフォンの範疇においては、プロセッサの実行サイクルを最小化することは、消費電力を最少化し、消費電力の最少化はバッテリの長寿命化に不可欠であるので、非常に重要である。Ｃ＋＋で記述され十分に設計されたオペレーティングシステムは、通常、サイズが相当大きく電力をかなり消費するものとなる。従って、これはモバイルコンピューティング、スマートフォンおよびＮＣ環境に適さない。

更に、コードサイズとオーバーヘッドサイクルの厳しい要求、特に、モバイル、スマートフォンおよびＮＣコンピューティング環境に関する厳しい要求を満たし、十分に機能的なオペレーティングシステムをＣ＋＋で設計するのは、一般的に困難であると考えられている。

用語
「ストリングクラスのオブジェクト」
Ｃ＋＋では、テキスト（例えば、コンピュータの画面に実際に現れる文字のストリング）は「オブジェクト」として表わされる。Ｃ＋＋または他のオブジェクト指向言語の当業者は、このカテゴリ化に精通しているであろう。このようなテキストに関連したオブジェクトは、「ストリングクラスのオブジェクト」と呼ばれる特定のタイプである。オブジェクトが属するクラスの種類（例えば、テキストの場合はストリングクラス）は、そのオブジェクトに実行することが許される操作を規定する。ストリングクラスには一定の操作（例えば、２つのテキストストリングをまとめて連結する）だけが行える。従って、ストリングクラスのある特定のオブジェクトは、特定のテキストストリングを表わしている。それは特定の、十分に定義された方法でのみ操作される。

テキストがファイリングシステムのファイルに存在するとき、テキストの項目からストリングクラスのオブジェクトを生成するためには、従来のＣ＋＋プログラミングでは以下のステップが実行される。

・メモリ内のバッファ位置をずらす
・ファイル読み取りサービスを使用してテキストをバッファに読み込む
・ストリング生成サービスを使用してバッファされたデータをストリングクラスのオブジェクトに変える
・バッファの内容を破棄する
Ｃ＋＋ではテキストストリングの実際の格納位置を識別するのは困難であるが、テキストストリングの位置を知る必要はない。なぜなら、直接操作するのはストリングクラスのオブジェクトであり、その結果実際のテキストストリングが操作される。従って、ストリングクラスのオブジェクトは、事実上テキストストリングのメモリ位置を知っており、テキスト操作に関連する必要なメモリ管理タスクの全てを扱うことができる。

ストリングクラスのオブジェクトの多重クラス
ＡＮＳＩ／ＩＳＯのＣ＋＋標準の草案として知られるＣ＋＋のバージョンでは、ストリングクラスの全てのオブジェクトは（＜ｓｔｒｉｎｇ＞として参照される、上記標準のスタンダードライブラリの草案の部分のストリングクラスで例示されているように）、洗練されたメモリ管理タスクが遂行されるような方法で処理される（例えば、バッファスペースを拡張したり、縮小したり、結合できる、すなわち、完全に動的な、テキスト用のバッファスペースの再配置）。しかし、このレベルのメモリ管理は、大量のコードを使用し、かなり大きいスペースを必要とする。

ここで従来のＣ＋＋のメモリ管理の２つの例を示す。

例１：Ｃ＋＋のリテラルテキストの処理
Ｃ＋＋では、ソースコードがテキストストリングを含むインスタンスが多数ある。これらのテキストストリングは「リテラルテキスト」として知られ、ソースコードを実行可能なオブジェクトコードへとコンパイルする時に、リテラルテキストはバッファメモリに永久的に格納される。リテラルテキストが操作されるとき、ストリングクラスのオブジェクトは、そこから生成されなければならない。しかしながら、このストリングクラスのオブジェクトの生成することで、メモリ内にテキストストリングが生成されることになり、このテキストストリンは、新たに生成されたストリングクラスのオブジェクトによって実際に操作されることになる。要するに、テキストストリングがメモリ内で複製されるのである。すなわち、テキストストリングは、ソースコードのコンパイルによって生じるオリジナルバッファで一度生成され、さらに、テキストの操作を可能とするストリングクラスのオブジェクトに関連したメモリ位置で再度複製される。

上記のように、あるコンピュータ環境では、コード空間および消費電力は重要である。しかしながら、（ＡＮＳＩ／ＩＳＯのＣ＋＋標準の草案で実現されるような）従来のＣ＋＋では、リテラルテキストの固有の複製を解消する機構がない。オペレーティングシステムではリテラルテキストを扱わなければならない場合が多数あるので、これはオペレーティングシステムでは特に問題である。

例２：Ｃ＋＋の長さが制限されたテキストの処理
Ｃ＋＋では、プログラマはヒープメモリを使用してテキストを処理する。長さが制限されたテキストは、長さが制限されていないテキストの処理に必要な十分に柔軟な手法を実際には必要としない。それにもかかわらず、従来のＣ＋＋では、テキストの長さに関係なく、ストリングクラスのオブジェクトに十分特徴付けられた、十分に柔軟な機構しかなく、それ以外の機構がない。ヒープメモリの取り扱いはコードおよびサイクルを集中的に使用するので、これは、メモリ管理コードにおけるオーバーヘッドを大きくする。

Ｃ＋＋の全体にわたるテキストのメモリ管理は、コードおよびサイクルを集中的に使用する。コード空間および消費電力はモバイル環境では重要であるので、従来のＣ＋＋の手法では、受容できないほどコードサイズが大きく、かつ、電力も大量に消費するオペレーティングシステムとなってしまう。

本発明のオペレーティングシステムは、ストリングクラスのオブジェクト（例えば、ＡＮＳＩ／ＩＳＯのＣ＋＋標準の草案で定義されるような）を、ストリングクラスのオブジェクトの３重構造、主に３つの新しいオブジェクトのクラスで置き換えることで再定義する。従来の、ＡＮＳＩ／ＩＳＯのＣ＋＋標準の草案による＜ｓｔｒｉｎｇ＞に機能的に関連し十分特徴付けられたメモリ管理関数は、３つの新しいクラスの全てに適用されない。十分に機能するものは多くの環境で有用であるが、コード空間および消費電力が重要なモバイルコンピューティング環境では（とりわけ）問題である。

従って、本発明の進歩的概念の一般化は、コンピュータのオペレーティングシステムに、テキストストリングを扱う３つの異なったクラス、すなわち、異なったクラスの各々が異なった状況に適している３つの異なったクラス、を提供することで、コードサイズおよびサイクルオーバヘッドを最小化することである。これは柔軟性を与える。すなわち、例えば、全ての機能を果たすメモリ管理関数は、今や実際にそれを必要とするテキストストリングにだけ適用されうる。

この新しいストリングクラスのオブジェクトのファミリを「ディスクリプタ（ｄｅｓｃｒｉｐｔｏｒ）」として参照することにする。好ましい実施形態では、このファミリのメンバを「ポインタディスクリプタ」、「バッファディスクリプタ」および「ヒープディスクリプタ」と呼ぶ。これらの概念は、当業者が親しんでいる「ポインタ」、「バッファ」および「ヒープ」の確立された概念とは（関連するが）異なることに注意が必要である。また、本明細書で想定するディスクリプタも、同じ名前のＶＭＳ設備や、アクティブオペレーティングシステムを識別するのに使用される小さな整数用のＵＮＩＸ（登録商標）用語とは何の関係もないことにも注意が必要である。当業者には、テキストストリングを扱うクラスの数が３つを越えるようにオペレーティングシステムを設計することができることが理解されるであろう。そのような変形も本発明の範囲に含まれる。３重構造は、クラスの増殖（ｐｒｏｌｉｆｅｒａｔｉｏｎ ｏｆ Ｃｌａｓｓｅｓ）としては最小（かつほとんど全ての場合にもっとも有効）である。

更に、ディスクリプタは好ましくはポリモルフィックであり、従って、単一のサービスが全てのディスクリプタに作用する。異なったディスクリプタの各々が別の方法で変更されたサービスを必要とするので、これによって、かなりのコードと、それより少ない程度でのオーバーヘッドの削減となる。

本発明の第１の態様によれば、テキストストリングに関するオブジェクトを扱うように構成されたオブジェクト指向オペレーティングシステムでプログラムされたコンピュータであって、前記オペレーティングシステムが、前記オブジェクトの全てを、各々が異なった機能を実行し、少なくともその１つがコードおよびサイクルオーバヘッドを減少するように変更されている、３つのクラス（主に、ポインタディスクリプタクラス、バッファディスクリプタクラスおよびヒープディスクリプタクラス）の１つに属するものとして扱うことを特徴とするコンピュータが提供される。

本発明は、コードおよびサイクルオーバヘッドをかなり減少させるためには、従来の単一形態のストリングクラスのオブジェクトを、（例えば）各形態が異なった状況に最適化された、３つの異なった形態のオブジェクトに置き換えて、オペレーティングシステムを再設計する必要があるという知見に基づいている。

本発明の好適な形態では、従来の、メモリを集中的に使用するテキスト処理技法は、そのような技法を要求するオブジェクトを定義する新しいディスクリプタクラス（すなわち、ヒープディスクリプタ）に属するオブジェクトにのみ適用される。しかしながら、ポインタおよびバッファディスクリプタクラスは、従来のストリングクラスと比べてコードおよびプロセッササイクルを減少させるように設計されている。

上記従来技術で記載した２つの例（すなわち、例１：Ｃ＋＋のリテラルテキストの処理と、例２：Ｃ＋＋の長さが制限されたテキストの処理）を使用して、本発明のオペレーティングシステムは、（ｉ）リテラルテキストの複製の必要をなくすようにリテラルテキストを扱い、（ｉｉ）実際に必要な限られた状況でのみヒープメモリのコードの集中的使用を行うように実行時に動的に決定され、他の状況（例えば、プログラマが前もってテキストの最大長を知っているとき）では、代わりにスタティックメモリを使用して、テキストを扱う。特定の処理の更なる詳細は以下で行う。

好ましくは、オペレーティングシステムは同じ３重構造を用いて、テキストだけでなく生のデータも扱うように構成される。

先に定義したコンピュータ／オペレーティングシステムの組み合わせに加えて、他の進歩的態様も同様に扱うことができるであろう。例えば、そのようなオペレーティングシステムをインタフェースしなければならないあらゆるデバイスも、ストリングクラスのオブジェクト用の同じ３重構造を使用する必要がある。例えば、固体メモリデバイスのような周辺機器用ドライバソフトウェアは、この３重構造を使用する必要がある。周辺機器用制御パネルのソフトウェアも同様である。

従って、本発明の第２の態様では、テキストストリングに関するオブジェクトを扱うように構成されたオブジェクト指向オペレーティングシステムでプログラムされたコンピュータの周辺装置であって、前記オペレーティングシステムが、前記オブジェクトの全てを、各々が異なった関数を実行し、少なくともその１つがコードおよびサイクルオーバヘッドを減少するように変更されている、３つのクラス（主に、ポインタディスクリプタクラス、バッファディスクリプタクラスおよびヒープディスクリプタクラス）の１つに属するものとして扱うこと、さらにまた前記周辺装置が、オブジェクトを前記３つのクラスにはいるものとして扱うようにプログラムされていることを特徴とする周辺装置が提供される。

本発明の第３の態様では、テキストストリングに関するオブジェクトを扱うように構成され、コンピュータで読み取り可能な媒体にコード化されたコンピュータのオペレーティングシステムであって、前記オペレーティングシステムが、前記オブジェクトの全てを、各々が異なった関数を実行し、少なくともその１つがコードおよびサイクルオーバヘッドを減少するように変更されている、３つのクラス（主に、ポインタディスクリプタクラス、バッファディスクリプタクラスおよびヒープディスクリプタクラス）の１つに属するものとして扱うことを特徴とするオペレーティングシステムが提供される。

本発明の第４の態様では、テキストストリングに関するオブジェクトを扱うように構成されたコンピュータのオペレーティングシステムを使用してマイクロプロセッサを操作する方法であって、前記オペレーティングシステムが、前記オブジェクトの全てを、各々が異なった関数を実行し、少なくともその１つがコードおよびサイクルオーバヘッドを減少するように変更されている、３つのクラス（主に、ポインタディスクリプタクラス、バッファディスクリプタクラスおよびヒープディスクリプタクラス）の１つに属するものとして扱うことを特徴とする方法が提供される。

第５の態様では、テキストストリングに関するオブジェクトを扱うように構成されたコンピュータのオペレーティングシステムでコード化された、コンピュータで読み取り可能な媒体であって、前記オペレーティングシステムが、前記オブジェクトの全てを、各々が異なった関数を実行し、少なくともその１つがコードおよびサイクルオーバヘッドを減少するように変更されている、３つのクラス（主に、ポインタディスクリプタクラス、バッファディスクリプタクラスおよびヒープディスクリプタクラス）の１つに属するものとして扱うことを特徴とする媒体が提供される。典型的には、コンピュータで読み取り可能な媒体はマスクＲＯＭである。配布用に、媒体は一般的なＣＤ−ＲＯＭまたはフロッピー（登録商標）ディスクであってもよい。

本発明をＥＰＯＣ３２として知られる実施形態に関して記載する。ＥＰＯＣ３２は、英国のＰｓｉｏｎ Ｓｏｆｔｗａｒｅ Ｐｌｃによって開発された、（特に）モバイルおよびスマートフォン環境用の、３２ビットオペレーティングシステムである。ＥＰＯＣ３２の実施形態のより詳細な説明は、英国のＰｓｉｏｎ Ｓｏｆｔｗａｒｅ Ｐｌｃによって発行されたＥＰＯＣ３２に関するＳＤＫの、付録１として添付された部分に開示されている。本発明者および譲渡人の権利があらゆる意味で限定されない範囲において、ＳＤＫ全体を本明細書に参照によって組み込む。

ＥＰＯＣ３２は、多数の異なったマイクロプロセッサアーキテクチャ上で実行するように移植された。オペレーティングシステムの移植の詳細は本質的に本明細書の範囲外であるが、当業者には理解できるであろう。特に、ＥＰＯＣ３２は英国のＡｄｖａｎｃｅｄ ＲＩＳＣ ＭａｃｈｉｎｅｓのＡＲＭ ＲＩＳＣ型マイクロプロセッサに移植されている。ＡＲＭマイクロプロセッサの様々なモデルは、デジタルセルラ電話に広く使用されており、当業者にはよく知られている。しかしながら、本発明は多数の異なったマイクロプロセッサ上で実現できる。従って、本明細書の請求の範囲は、オペレーティングシステムが請求の範囲に記載されたような関数を実行する、あらゆる全てのハードウェアおよびソフトウェアの実施に及ぶものと理解すべきである。

上記従来技術の検討で挙げた、リテラルテキストおよび長さが制限されたテキストの例に戻り、ＥＰＯＣ３２は、ストリングクラスのオブジェクト用の上記３重構造を以下のように使用する。

例１：ＥＰＯＣ３２におけるリテラルテキスト
上記のように、従来のＣ＋＋では、リテラルテキストに関するテキストストリングはメモリ内で複製される。すなわち、ソースコードのコンパイルで生じるオリジナルバッファ内で一度生成され、テキストの操作を可能にするストリングクラスのオブジェクトに関するメモリ位置で再度複製される。この複製は無駄である。

しかしながら、ＥＰＯＣ３２は、リテラルテキストの元のメモリ位置（すなわち、コンパイラによって定められたメモリ位置）を指し示すポインタディスクリプタを使用する。このポインタディスクリプタ（ＥＰＯＣ３２ではＴＰｔｒＣ ポインタディスクリプタと呼ぶ）は、リテラルテキスト用のストリングクラスのオブジェクトである。（Ｃ＋＋では、本質的にポインタは通常オブジェクトとして認識されていない。

従って、ＥＰＯＣ３２のポインタ／オブジェクトのハイブリッドによって、リテラルテキストの追加のコピーの必要が完全に除去される。

例２：ＥＰＯＣ３２における長さが制限されたテキスト
上記のように、従来のＣ＋＋では、テキストの長さに関係なく、十分に柔軟で十分に特徴付けられたストリングクラスのオブジェクトを使用する機構しかなく、それ以外を使用する機構はない。ヒープメモリの処理はコードおよびサイクルを集中的に使用するので、これによりメモリ管理コードに多くのオーバーヘッドが生じる。

ＥＰＯＣ３２では、サイズが制限されたバッファディスクリプタと呼ばれる、ストリングのオブジェクトについての特別なクラスがある。これらはサイズが制限されているので、操作するのに複雑なメモリアロケーションコードを必要としない。更に、バッファディスクリプタは（ヒープメモリではなく）スタティックメモリを使用できる。スタティックメモリはヒープメモリでできるようなコードを集中的に使用する方式でメモリを再配置できないが、必要な操作を行うのに必要となるコードサイクルが少ない点で、使用するのにより効率的である（従って電力の削減となる）。ＥＰＯＣ３２は、実際に動的な場合に限って、多くのサイクルオーバヘッドを伴うヒープメモリを使用する。その場合には、ヒープディスクリプタクラスを使用する。

ＥＰＯＣ３２は、長さが制限されたストリングクラスのパラメータを、「ＴＢｕｆ」クラスのクラステンプレートを使用して定義する。（クラステンプレートはストリングクラスの多数のオブジェクトのプロパティを定義する。例えば、ＴＢｕｆ は全てのバッファディスクリプタ、すなわち、バッファの変形のストリングクラスの全てのオブジェクトのテンプレートである。ＴＢｕｆ はストリングクラスのそのようなオブジェクトに対して一定の共通プロパティを定義する。）
ＥＰＯＣ３２は、コードサイズおよびサイクルオーバヘッドを最小化する以外の重要な特徴も示す。それは主に以下の点である。

・「フラット」構造として動作する、ストリングおよび生のデータバッファクラスのオブジェクト
・ディスクリプタが与えるポリモルフィック特性
・ディスクリプタがユニコードおよびアスキーの一様なコーディングを可能とするフラット構造としてのストリングおよび生のデータバッファクラスのオブジェクト
全てのディスクリプタは「フラット」構造である（すなわち、ディスクリプタがコピーされると、ディスクリプタ自身だけがコピーされる。従来のＣ＋＋では、オブジェクトのコピーはオブジェクト自身だけでなく関連する全てのポインタおよびポインタで示されるデータ、すなわち、オブジェクトに意味を与える複雑な関連する構造、のコピーも必要である。）。従って、ＥＰＯＣ３２では、ディスクリプタをコピーすることは、通常のＣ＋＋で等価であるオブジェクトをコピーすることよりも、メモリオーバヘッドおよびサイクルにおいてはるかに経済的である。

これはＥＰＯＣ３２で、バッファおよびポインタについて以下のように達成される。

バッファディスクリプタ（ＴＢｕｆ）は、バッファによって参照される実際のテキストを含んでおり、従って、バッファをコピーすると本質的に関連するテキストをコピーする。Ｃ＋＋のようにポインタおよび関連するデータのコピーは必要ない。

ポインタディスクリプタ（ＴＰｔｒ）は、Ｃ＋＋型のポインタを内部に含んでいるので、複製するときにはＴＰｔｒだけが必要である。従来のＣ＋＋では、１つのエンティティだけでなく関連する別のポインタおよびテキストもコピーする必要があった。

ポリモルフィックオブジェクトとしてのディスクリプタ
共通の作用が異なった機構によって達成されるとしても、グループ内の全てのオブジェクトが単一のオブジェクトのように作用するとき、オブジェクトのグループはポリモルフィズムを示すと言われる。ポリモルフィズムは従来のＣ＋＋では、互いにポリモルフィックな全てのオブジェクトが、共通の位置に、仮想関数テーブルへのポインタ（従ってポインタは各オブジェクト内に必要である）を含んでいる、仮想関数によってもたらされる。このテーブルは各ポリモルフィック関数に対する実際のコードを識別する。ポリモルフィズムを共有する各クラスに対して別のテーブルが必要である。しかしこの手法は、各ポインタが３２ビット（すなわち４文字）であり各オブジェクトが仮想関数テーブルへのポインタを必要とするので、比較的大きな空間を使用する。更に、各オブジェクトで３２ビット長のフィールドも使用される。

（特に）モバイルオペレーティングシステム環境においては、このことは問題である。ＥＰＯＣ３２では、ストリングクラスのオブジェクトに対して次のように対処する。すなわち、３２ビット長のフィールドが細分割され、最初の４ビットがディスクリプタのタイプを記述する。そして関数は４ビットを検査し、正しいテキスト位置を指し示す（例えば、ディスクリプタがバッファならばディスクリプタ自体の中など）。従って、ストリングクラスのオブジェクトに対する３つの異なったクラスのディスクリプタ（すなわち、ポインタディスクリプタ、バッファディスクリプタおよびヒープディスクリプタ）の各々が、単一の３２ビットフィールドの最初の４ビットだけを使用して記述できるということによってポリモルフィズムが提供される。このようにしてかなりのメモリの節約が達成される。より一般的には、フィールドは別のデータ項目と機械語を共有する。

ユニコードおよびアスキーで変化しないコード
Ｃ＋＋では、１６ビットのユニコードのコーディングは、そうでなければ８ビットコードとなる全てのテキストデータのサイズを２倍にすることとなる。また、従来は、プログラマがソースコードを書くときに、アスキーまたはユニコードのどちらを使用して記述するかを決定する必要があった。

ＥＰＯＣ３２では、アスキーまたはユニコードの最終的な選択にかかわらず、同じソースコードが使用される。これはシステムを、クラスそれ自体（例えば、ポインタディスクリプタ、バッファディスクリプタおよびヒープディスクリプタ）でなく、アスキーおよびユニコードによって変化しない、クラスネームのエイリアスを使用して構成することによって達成される。従って、ユニコードを記述するのにポインタＴＰｔｒ１６ を使用したり、アスキーを記述するのにＴＰｔｒ８ を使用して作成する代わりに、プログラマはＴＰｔｒ クラスネームを使用して作成する。

作成時に、クラスネームは１６ビットユニコードまたは８ビットアスキーコードのいずれかでコンパイルできる。この手法は、異なったビット長でコード化される全ての文字セットを含むように適用できる。

ＥＰＯＣ３２の補足的利点
Ｃ＋＋では、テキストストリングは通常「０」で終了し、これによりシステムはテキストストリングの終了位置を容易に知ることができる。ＥＰＯＣ３２ではこれはもはや必要ない。なぜなら、ディスクリプタが参照されるデータの長さを定義する記述を含んでいるからである。従って、各テキスト項目毎に終端を示すのに「０」を使用する必要がなくなるので、更にまたコードの節約となる。

ディスクリプタの特徴の要約
ディスクリプタには３つのクラスがある。すなわち、ポインタディスクリプタ、バッファディスクリプタおよびヒープディスクリプタである。
・ポインタディスクリプタには２つの形態がある。不変ポインタディスクリプタ ＴＰｔｒＣ と可変ポインタディスクリプタＴＰｔｒである。

・不変ポインタディスクリプタ：ＴＰｔｒＣ
・これによりデータは変更できない。
・全てのメンバ関数が一定。
・不変ストリングまたはデータ（例えば変更されてはいけないデータ）
・ＴＤｅｓＣ から導出され、従って多数のメンバ関数を有する。

・可変ポインタディスクリプタ：ＴＰｔｒ
・設計者によって設定された最大長を越えない範囲で、このディスクリプタによってデータを変更できる。
・変更されている領域を含むメモリ領域を直接指し示す。
・ポインタ長により含まれるデータ項目数が決定される。
・全てのＴＤｅｓＣ メンバ関数に加えデータの変更および操作のためのＴＤｅｓメンバ関数を継承する。
・ポインタディスクリプタはデータ表現とは別であるが、メモリ内の予め存在する領域から構成される。

・バッファディスクリプタには２つの形態がある。

・不変バッファディスクリプタ：ＴｂｕｆＣ＜；ＴｉｎｔＳ＞；
・作成時または後で代入演算子（演算子＝）により、ディスクリプタにデータを設定できる。
・整数テンプレートにより長さが定義される。すなわち、ＴＢｕｆＣ＜；４０＞；は４０のデータ項目を含んでいる。
・全てのＴＤｅｓＣ メンバ関数を継承する。

・可変バッファデイスクリプタ：Ｔｂｕｆ＜；ＴｉｎｔＳ＞；
・最大長を越えない範囲で変更できるデータを含んでいる。
・最大長が最大データ項目数を定義する。
・実際の長さが実際のデータ項目数を定義する。
・整数テンプレートにより長さが定義される。すなわち、ＴＢｕｆ＜；４０＞；は４０のデータ項目だけを含んでいる。
・データ領域はディスクリプタオブジェクトの一部である。
・操作および変更の必要なデータを含めるのに有効であるが、その長さは既知の最大値（例えばＷＰテキスト）を越えない。
・全てのＴＤｅｓＣ メンバ関数に加えデータの変更および操作のためのＴＤｅｓメンバ関数を継承する。

・ヒープディスクリプタは１つの形態だけである。
・不変ヒープディスクリプタ：ＨＢｕｆＣ
・データと連続した長さを有する。
・データ領域はディスクリプタオブジェクトの一部であり、オブジェクト全体はヒープから割り当てられたセルを占める。
・作成時または後で代入演算子（演算子＝）により、ディスクリプタにデータを設定できる。
・全てのＴＤｅｓＣ メンバ関数を継承する。
・再割り当て可能、すなわち、データ領域は拡張および縮小できる。

付録１
Ｐｓｌｏｎ Ｓｏｆｔｗａｒｅ Ｐｌｃ．から１９９７年に発行されることになっているＥＰＯＣ３２「ディスクリプタ」ＳＤＫ（抜粋）。Ｐｓｌｏｎ Ｓｏｆｔｗａｒｅ Ｐｌｃ．から１９９７年７月（改訂１．０）に発行されたＳＤＫ全文を参照する。

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
ＳＤＫ：ディスクリプタ概要
ディスクリプタクラスの３重構造（主に、ポインタディスクリプタクラス、バッファディスクリプタクラスおよびヒープディスクリプタクラス）は、ストリングおよび一般的バイナリデータの両方に、それらが存在するメモリのタイプに関係なく、安全かつ一貫したアクセスおよび操作のための機構を提供する。例えば、ＲＯＭ内のコード部分のストリングを、ＲＡＭ内のファイルレコードと同様に扱える。

ディスクリプタによって表わされるデータは、メモリ内の定められた位置のデータ領域にある。このデータ領域は拡張できない。ディスクリプタデータの操作は、定められたデータ領域外の偶発的あるいは故意のメモリアクセスが許されないという意味で安全である（一般的に、無効なアクセスを行うコードは、（通常パニックとして知られる）例外の原因となる）。

ディスクリプタは、表わされたデータのタイプで区別をしないので、ストリングおよびバイナリデータの両方は同様に扱われる。ディスクリプタオブジェクトのメンバ関数のあるものはテキストデータを操作するように設計されているにもかかわらず、それらはバイナリデータにも作用する。これによりストリングおよびバイナリデータの扱いを統一し、コードを共有できるようにして効率を高める。

ディスクリプタクラスはいくつかの重要な用件を満足する：
・ユニコードおよびアスキーテキスト両方のサポートを提供する。マクロ ＵＮＩＣ０ＤＥは、アスキーまたはユニコードで作成された変数を選択するのに使用される。
・ストリングおよびバイナリデータの扱いを統一する。
・ＲＯＭ内のテキストまたはデータの安全かつ便利な参照を可能にする。
・関連するテキストまたはデータを操作する多くのメンバ関数を提供する。
・データの変更を可能とするが、定められたデータ領域外へ書き込もうとするあらゆる試みを防止する。
・仮想関数に関連するメモリオーバヘッドをなくす。
・組み込みタイプのように作用し、スタック上に安全に作成され、安全に孤立化（ｏｒｐｈａｎｅｄ）され得る。
・（ＨＢｕｆＣ がヒープ上に割り当てられ、規則の例外となる。）。

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
アスキーおよびユニコードテキスト
Ｅ３２．ディスクリプタ文字セット
アスキーテキスト文字は８ビット（１バイト）で表わされるが、ユニコード文字は１６ビット（２バイト）を必要とする。アスキーおよびユニコードテキストの両方をサポートするために、ディスクリプタクラスは、８ビットと１６ビットの２つの変形を有する。例えば、ＴＰｔｒ８ およびＴＰｔｒ１６ の２つのポインタディスクリプタクラスがある。

プログラムを、作成された変数から独立したクラスネームを使用してユニコードまたはアスキーテキストのいずれかをサポートするように構成できる。例えば、ディスクリプタクラスＴＰｔｒ を使用して、ＴＰｔｒ８ またはＴＰｔｒ１６ のいずれかを使用するようにシステムを構成できる。マクロ ＵＮＩＣ０ＤＥ が定義されたか否かによって、作成時（ｂｕｉｌｄ ｔｉｍｅ）に決定される。

ヘッダファイルＥ３２３２ｄｅｆ．ｈ（ＳＤＫの付録１参照）から抽出した次のコードは、変数から独立したクラスネームを適切に定義することによって実現する方法を示している。

＃ｉｆ ｄｅｆｉｎｅｄ（ＵＮＩＣＯＤＥ）
・・・
ｔｙｐｅｄｅｆ ＴＰｔｒ１６ ＴＰｔｒ；
・・・
＃ｅｌｓｅ
・・・
ｔｙｐｅｄｅｆ ＴＰｔｒ８ ＴＰｔｒ；
・・・
＃ｅｎｄｉｆ

アプリケーションコードには、「Ｃ」スタイルのストリングリテラルを直接使用しないようにすべきである。その代わり、適切な幅の「Ｃ」スタイルのストリングを生成するのに、適切なタイプのポインタに戻す、マクロ Ｓを使用すべきである。また、適切なタイプのディスクリプタを作成するには、マクロ Ｌ（「リテラル」に対する Ｌ）を使用すべきである。これらのマクロの定義については、ｅ３２．ｍａｃｒｏ．＿Ｓおよびｅ３２．ｍａｃｒｏ．＿Ｌを参照せよ。

例えば、
ｃｏｎｓｔ ＴＴｅｘｔ＊ｓｔｒ＝＿Ｓ（“Ｈｅｌｌｏ”）；
は、アスキーで作成された１バイト文字のストリングを生成するが、ユニコード作成では２バイト文字のストリングを生成する。

＿Ｌ（“Ｈｅｌｌｏ”）；
は、アスキーで作成された８ビットディスクリプタおよびユニコードで作成された１６ビットディスクリプタを生成する。常に正しい変数のディスクリプタを作成するように、例えば、平文“ａｂｃｄｅｆ”ではなく、常に＿Ｌ（“ａｂｃｄｅｆ”）を使用する。

ｍａｃｒｏ＿Ｓ８およびｍａｃｒｏ＿Ｌ８をそれぞれ使用することによって、作成された変数とは独立して、８ビット「Ｃ」スタイルストリングおよび８ビットポインタディスクリプタが明白に生成される。対応する１６ビットのバージョン、＿Ｓ１６および＿Ｌ１６も使用できる。これらの定義については、ｅ３２．ｍａｃｒｏ．＿Ｓ８， ｅ３２．ｍａｃｒｏ．＿Ｌ８， ｅ３２．ｍａｃｒｏ．＿Ｓ１６ および ｅ３２．ａｍｃｒｏ．＿Ｌ１６を参照せよ。

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
長さおよびサイズ
Ｅ３２３２．ディスクリプタ長さおよびサイズ
ディスクリプタは、表わすデータをそのデータの長さで特徴付ける。ディスクリプタの長さは、データ項目の数である。８ビットの変数に対しては、ディスクリプタの長さはそれが表わす１バイトデータの数であり、１６ビットの変数に対しては、ディスクリプタの長さはそれが表わす２バイトデータの数である。

ディスクリプタのサイズよ、ディスクリプタのデータが占めるバイト数であり、ディスクリプタの長さと同じである必要はない。８ビットの変数に対しては、サイズは長さと同じであり、１６ビットの変数に対しては、サイズは長さの２倍である。データが変更されていることを許可するディスクリプタもまた、その最大長によって特徴付けられる。これらのディスクリプタに対しては、表わされるデータの長さは、ゼロからこの最大値まで最大値と共に変化し得る。あらゆるディスクリプタの最大長は２２８である。

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
テキストおよびバイナリデータ
Ｅ３２３２．ディスクリブタテキストおよびバイナリ
「Ｃ」では、ストリングスは、ストリングの終端を示すゼロターミネータを必要とすることによって特徴付けられる。これらは多数の問題を招く。特に、これらは（データがバイナリゼロを含む場合に）バイナリデータを中に含むことができず、それらに対する操作は一般的に効率的でない。「Ｃ」ストリングスは、ＡＮＳＩの「Ｃ」ライブラリの関数グループ、ｍｅｍｘｘｘ（）およびｓｔｒｘｘｘ（）に反映されているように、バイナリデータとは異なった方法で扱う必要がある。ディスクリプタはストリングとバイナリデータを同じ方法で表わすことを可能とし、これは両方の場合に同じ関数を使用することを可能とする。バイナリデータに対しては、明示的に８ビットのディスクリプタを使用しなければならない。バイナリデータにとっては、ユニコードをアスキーの区別は意味がない。１６ビットバイナリデータは事実上使用しないことに注意せよ。

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
メモリ割り当て
Ｅ３２３２．ディスクリプタ割り当て
ディスクリプタクラスは（ＨＢｕｆＣ を除いて）、組み込みタイプのように作用する。これらはメモリの割り当てを行わず、デストラクタを持たない。これは、ディスクリプタクラスが組み込みタイプと同様にスタック上で孤立化され得ることを意味する。これは特に、コードを残せる状況では重要である。（孤立化の影響については、Ｅ３２３２．例外トラップ．クリーンアップ．用件を参照せよ）
ＨＢｕｆＣディスクリプタオブジェクトはヒープ上に割り当てられ、スタック上には作成されない。

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
例外
Ｅ３２３２．ディスクリプタ例外
ディスクリプタメンバ関数の全てのパラメータは、操作が正しく指定され、どのデータもディスクリプタのデータ領域外に書き込まれないことを保証するべく検査される。特定の結果は、どのメンバ関数も、可変ディスクリプタをその最大割り当て長を越えて拡張できないこととなる。元の割り当てを十分大きくするか、より大きいディスクリプタの必要性を見越して実行時により大きなディスクリプタを動的に割り当てるかによって、全てのディスクリプタがデータを収容できるように十分大きいことを保証するのは、プログラマの責任である。スタティックな手法は実施がより簡単であるが、これが無駄であると判明した特定の場合には、動的手法がより効果的であろう。例外の場合には、どんな認められていないメモリのアクセスも実行しないこと、およびどんなデータも移動または損傷されないことが安全であると考えられている。

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
ディスクリプタタイプ
Ｅ３２３２．ディスクリプタタイプ
ディスクリプタオブジェクトには３種類ある。

すなわち、
・ポインタディスクリプタ
ディスクリプタオブジェクトは、それが表わすデータとは別であるが、メモリ内の予め存在する領域に生成される。これには、
不変ポインタディスクリプタ、ＴＰｔｒＣ
可変ポインタディスクリプタ、ＴＰｔｒ
の２つの形態がある。

・バッファディスクリプタ
データ領域はディスクリプタオブジェクトの一部である。これには、
不変バッファディスクリプタ、ＴＢｕｆＣ＜；ＴｌｎｔＳ＞；
可変バッファディスクリプタ、ＴＢｕｆ＜；ＴｌｎｔＳ＞；
の２つの形態がある。

・ヒープディスクリプタ
データ領域はディスクリプタオブジェクトの一部であり、オブジェクト全体がヒープから割り当てられたセルを占有する。これは、
不変ヒープディスクリプタ、ＨＢｕｆＣ
の１つの形態だけである。

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
ポインタディスクリプタ−ＴＰｔｒＣ
Ｅ３２３２．ディスクリプタポインタディスクリプタ．ＴＰｔｒＣ
ＴＰｔｒＣ は、それによってどのデータも変更されない、不変ディスクリプタである。そのメンバ関数の全ては（コンストラクタを除いて）不変（ｃｏｎｓｔａｎｔ）である。図１にＴＰｔｒＣ が概略的に示されている。ＴＰｔｒＣ は不変ストリングまたはデータを参照する、例えば、ＲＯＭ常駐コード中に生成されたテキストをアクセスするとき、またはその参照によってデータが変更されてはならないＲＡＭ内のデータに参照を渡すときに有効である。ＴＰｔｒＣ は、例えば、テキストまたはデータの抽出部分内の文字の位置決めなどの、その内容を操作する多くのメンバ関数を提供するＴＤｅｓＣ から導出される。

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
ポインタディスクリプタ−ＴＰｔｒ
Ｅ３２３２．ディスクリプタ．ポインタディスクリプタ．ＴＰｔｒ
ＴＰｔｒ は、データが最大長を越えない範囲で、それによってデータを変更できるポインタディスクリプタである。最大長はコンストラクタによって設定される。
ＴＰｔｒ は、変更されているデータを含むメモリ内の領域を直接指し示す。ＴＰｔｒ は、図２Ａおよび２Ｂに概略的に示されている。

領域が含むことができるデータ項目の最大数は、最大長で定義される。ＴＰｔｒは、データ内に現在いくつのデータ項目が含まれているかを表わす。この値が最大値より小さいとき、データ領域の一部は未使用である。ＴＰｔｒ は、参照により変更されているよう意図されたデータを含むＲＡＭの領域、またはまだデータがないが、ディスクリプタの参照およびメンバ関数を使用してデータが生成されるＲＡＭの領域への参照を生成するのに有効である。

ＴＰｔｒ はまた、変更されているデータを含む、ＴＢｕｆＣ またはＨＢｕｆＣ ディスクリプタへの参照を生成するのに有効である。このように使用されるＴＰｔｒ は、ＴＢｕｆＣ またはＨＢｕｆＣ ディスクリプタを指し示す。ＴＢｕｆＣ またはＨＢｕｆＣ ディスクリプタに含まれるデータはＴＰｔｒ によって変更することができる。ＴＰｔｒ は、ＴＤｅｓＣ から導出されたＴＤｅｓ から導出される。従って、ＴＰｔｒ は、ＴＤｅｓＣ で定義された全てのｃｏｎｓｔ メンバ関数に加え、例えば、既存のテキストの末端に文字を付加する等の、データの操作および変更が可能なＴＤｅｓ のメンバ関数を継承している。

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
バッファディスクリプタ−ＴＢｕｆＣ＜；ＴＩｎｔ Ｓ＞；
Ｅ３２３２．ディスクリプタ．バッフアディスクリプタ．ＴＢｕｆＣ
ＴＢｕｆＣ は、データ領域が続く長さを有するバッファディスクリプタである。データは、生成時にまたは他のあらゆるときに割り当てられた演算子（演算子＝）によって、ディスクリプタ内に設定される。ディスクリプタによって保持されたデータは不変である。ＴＢｕｆＣ は、図３に概略的に示されている。ＴＢｕｆＣ の長さは、例えば、ＴＢｕｆＣ＜；４０＞；が４０までのデータ項目を含むことができるＴＢｕｆＣ を定義するように、整数テンプレートによって定義される。

ＴＢｕｆＣ は、例えばテキストまたはデータの抽出部分内の文字の位置を決める、その内容物を操作する多くのメンバ関数を提供するＴＤｅｓＣ から導出される。ＴＢｕｆＣ は、ＴＢｕｆＣ を参照する可変ポインタディスクリプタ（ＴＰｔｒ）を作成する、メンバ関数Ｄｅｓ（）を提供する。これにより、図４に概略的に表わしたように、ＴＰｔｒによってＴＢｕｆＣ のデータを変更することができる。ＴＰｔｒ の最大長は、整数テンプレートパラメータの値である。

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
バッファディスクリプタ−ＴＢｕｆ＜；ＴＩｎｔ Ｓ＞；
Ｅ３２３２．ディスクリプタ．バッファディスクリプタ．ＴＢｕｆ
ＴＢｕｆ は、データが最大長を越えない範囲で、変更できるデータを含むバッファディスクリプタである。図５にＴＢｕｆ が概略的に示されている。ＴＢｕｆ が内部のデータ領域に含むことができるデータ項目の数は、最大長によって定義される。

ディスクリプタの長さは、データ領域に現在いくつのデータ項目が含まれているかを表わしている。この値が最大値より小さいとき、データ領域のある部分は未使用である。ＴＢｕｆ の最大長は、例えば、ＴＢｕｆ＜；４０＞；が４０までの（かつ越えない！）データ項目を含むことができるＴＢｕｆ を定義するように、整数テンプレートによって定義される。ＴＢｕｆ は、例えばワードプロセッサのテキスト等の、操作および変更が必要であるが、その長さが既知の最大値を越えないデータを収容するのに有効である。ＴＢｕｆ は、ＴＤｅｓＣ から導出されたＴＤｅｓ から導出される。

従って、ＴＰｔｒ は、ＴＤｅｓＣ で定義された全てのｃｏｎｓｔ メンバ関数に加え、例えば、既存のテキストの末端に文字を付加する等の、データの操作および変更が可能なＴＤｅｓ のメンバ関数を継承している。

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
ヒープディスクリプタ−ＨＢｕｆＣ
Ｅ３２３２．ディスクリプタ．ヒ−プディスクリプタ．ＨＢｕｆＣ
ＨＢｕｆＣ は、データ領域が続く長さを有するディスクリプタである。スタティックメンバ関数、Ｎｅｗ（）、ＮｅｗＬ（）またはＮｅｗＬＣ（）を使用してヒープ上に割り当てられる。ディスクリプタの長さはこれらスタティック関数へのパラメータとして渡される。図６にＨＢｕｆＣ が概略的に示されている。データは、生成時にまたは他のあらゆるときに割り当てられた演算子（演算子＝）によって、ディスクリプタ内に設定される。ＨＢｕｆＣ は、例えばテキストまたはデータの抽出部分内の文字の位置を決める、その内容物を操作する多くのメンバ関数を提供するＴＤｅｓＣ から導出される。

ＨＢｕｆＣ は、ＨＢｕｆＣ を参照する可変ポインタディスクリプタ（ＴＰｔｒ）を作成する、メンバ関数Ｄｅｓ（）を提供する。ＴＰｔｒ の最大長は、ＨＢｕｆＣ データ領域の長さである。図７はこれを概略的に示している。

ヒープディスクリプタは再配置することができる。関数ＲｅＡｌｌｏｃ（）またはＲｅＡｌｌｏｃＬ（）は、ヒープディスクリプタのデータ領域の拡張あるいは縮小を可能にする。しかしながら、データ領域の長さは、現在保持しているデータの長さより短くすることはできない。データ領域を縮小する前に、ディスクリプタが保持するデータを減少させなければならない。割り当て演算子がヒープディスクリプタ中に設定できるデータの長さは、ディスクリプタのデータ領域に割り当てられたスペースに制限される。ヒープディスクリプタによって占有されたメモリは、Ｕｓｅｒ：：Ｆｒｅｅ（）のコールまたはキーワードｄｅｌｅｔｅを使用して明示的に開放する必要がある。

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
ディスクリプタクラスの継承・派生関係
Ｅ３２．ディスクリプタ．クラス
全てのディスクリプタクラス、ＴＰｔｒＣ，ＴＰｔｒ，ＴＢｕｆＣ，ＴＢｕｆおよびＨＢｕｆＣ は、抽象的基底クラス（ａｂｓｔｒａｃｔ ｂａｓｅ ｃｌａｓｓ）ＴＤｅｓＣ およびＴＤｅｓ から導出される。

クラスＴＢｕｆＣＢａｓｅ を抽象的基底クラスとして示したが、これは単に実施が容易なためである。図８はクラス間の関係を概略的に示している。

実際のディスクリプタクラスの作用は非常に似ており、従って、ディスクリプタのほとんどの関数は抽象的基底クラスによって提供される。ディスクリプタは（特にスタックで）広く使用されるので、ディスクリプタオブジェクトのサイズを最小にする必要がある。これを補助するように、各ディスクリプタオブジェクトにおいて仮想関数テーブルポインタのオーバーへッドをなくすため、仮想関数の定義をしない。その結果、基底クラスはそこから導出されるクラスの知識を潜在的に持っている。

Ｅ３２は、８ビット（アスキー）テキストおよびバイナリデータを扱うものと、１６ビット（ユニコード）テキストを扱うものとの２つのディスクリプタクラスの変数を供給する。実際のクラスの８ビット変数は、ＴＰｔｒＣ８，ＴＰｔｒ８，ＴＢｕｆＣ８＜；ＴＩｎｔ Ｓ＞；，ＴＢｕｆ８＜；ＴＩｎｔ Ｓ＞；およびＨＢｕｆＣ８であり、抽象クラスの８ビット変数は、ＴＤｅｓＣ８ およびＴＤｅｓ８ である。同様に、１６ビット変数の名前はそれぞれ、ＴＰｔｒＣ１６，ＴＰｔｒ１６，ＴＢｕｆＣ１６＜；Ｔｌｎｔ Ｓ＞；，ＴＢｕｆ１６＜；ＴＩｎｔＳ＞；，ＨＢｕｆＣ８，ＴＤｅｓＣ１６およびＴＤｅｓ１６である。

この区別はテキストを表わすのに使用されるディスクリプタにはトランスペアレントである。ＴＰｔｒＣ，ＴＰｔｒ，ＴＢｕｆＣ＜；ＴＩｎｔ Ｓ＞；，ＴＢｕｆ＜；ＴＩｎｔ Ｓ＞；およびＨＢｕｆＣクラスを生成し使用するプログラムを書くことにより、ユニコードおよびアスキーの両方に対する互換性が維持される。マクロ＿ＵＮＩＣ０ＤＥが定義されたか否かに応じて、構成時に適切な変数が選択される。マクロ＿ＵＮＩＣ０ＤＥが定義されていると１６ビット変数が変数が使用され、そうでなければＥ３２．ディスクリプタ．文字セットで説明したように８ビットの変数が使用される。

バイナリデータのディスクリプタは、明示的に８ビット変数を使用する必要があり、換言すると、コードは明示的に ＴＰｔｒＣ８，ＴＰｔｒ８，ＴＢｕｆＣ８＜；ＴＩｎｔ Ｓ＞；，ＴＢｕｆ８＜；ＴＩｎｔ Ｓ＞；およびＨＢｕｆＣ８のクラスを生成する。

バイナリデータに対して１６ビット変数を明示的に使用することもできるが、勧められない。一般に、８ビットおよび１６ビットの変数は、構造および実施において同一であり、クラス自体の記述は全体に渡り構成とは独立した名前を使用する。

多くのメンバ関数が、ディスクリプタが８ビットか１６ビットの変数であるかに応じて、ＴＵｉｎｔ８＊タイプまたはＴＵｉｎｔ１６＊タイプの引数を取ることに特に注意せよ。説明を単純にするため、これらの引数を関数プロトタイプＴＵｉｎｔ？？＊として記載する。

ＴＰｔｒＣの概略を示す図である。 ＴＰｔｒの概略を示す図である。 ＴＢｕｆＣの概略を示す図である。 ＴＰｔｒとＴＢｕｆＣの関係を示す図である。 ＴＢｕｆＣの概略を示す図である。 ＨＢｕｆＣの概略を示す図である。 ＴＰｔｒとＨＢｕｆＣの関係を示す図である。 クラス間の継承・派生の関係を示す図である。

Claims (3)

1. 単一のベースクラス（TDesC）から派生した、階層構造を有する５つのストリングクラスのオブジェクトを操作又はアクセスできるようにプログラムされたオブジェクト指向のオペレーティングシステムを使用するコンピュータ装置において、
   リードオンリーメモリと、
   ランダムアクセスメモリと、
   （ａ）前記ベースクラス（TDesC）から派生し、リテラルテキストを扱うためのストリングクラスであって、前記リードオンリーメモリ又は前記ランダムアクセスメモリのうちヒープ領域以外のメモリ領域に該リテラルテキストを格納し、該テキストが格納されたオリジナルのメモリ領域にポインタを利用してアクセスするように定義された第１のストリングクラス（TPtrC）に属するオブジェクトを、該第１のストリングクラス（TPtrC）の定義にしたがって操作又はアクセスする手段と、
   （ｂ）データの追加及び変更を可能とするメンバ関数を定義した、前記ベースクラス（TDesC）から派生した他のクラス(TDes)からさらに派生し、予め設定された最大長を超えない長さのテキストを前記ランダムアクセスメモリのうちヒープ領域以外のメモリ領域に格納し、該テキストが格納されオリジナルのメモリ領域にポインタを利用してアクセスし、該最大長を超えない範囲で該テキストにデータを追加又は変更するように定義された第２のストリングクラス（TPtr）に属するオブジェクトを、該第２のストリングクラス（TPtr）の定義にしたがって操作又はアクセスする手段と、
   （ｃ）前記ベースクラス（TDesC）から派生し、長さが制限されたテキストを前記ランダムアクセスメモリのうちスタティックメモリ領域に格納してアクセスするように定義された第３のストリングクラス(TBufC)に属するオブジェクトを、該第３のストリングクラス(TBufC)の定義にしたがって操作又はアクセスする手段と、
   （ｄ）前記ベースクラス（TDesC）から派生した前記他のクラス(TDes)からさらに派生し、長さが制限されたテキストを前記ランダムアクセスメモリのうちスタティックメモリ領域に格納し、前記データの追加及び変更を可能とする複数のメンバ関数を利用してデータの追加及び変更をするように定義された第４のストリングクラス(TBuf)に属するオブジェクトを、該第４のストリングクラス(TBuf)の定義にしたがって操作又はアクセスする手段と、
   （ｅ）前記ベースクラス（TDesC）から派生し、長さが動的に変化し得るテキストを、前記ランダムアクセスメモリのうちのヒープ領域を使用するために必要となるすべてのメモリ管理関数を利用して該ヒープ領域に格納してアクセスするように定義された第５のストリングクラス(HBufC)に属するオブジェクトを、該第５のストリングクラス(HBufC)の定義にしたがって操作又はアクセスする手段と
   を含むことを特徴とするコンピュータ装置。
2. 単一のベースクラス（TDesC）から派生した、階層構造を有する５つのストリングクラスのオブジェクトを操作又はアクセスできるようにプログラムされたオブジェクト指向のオペレーティングシステムを使用する、リードオンリーメモリ、ランダムアクセスメモリおよびマイクロプロセッサを有するコンピュータ装置によって該オブジェクトについて操作又はアクセスする方法であって、
   前記マイクロプロセッサが、
   （ａ）前記ベースクラス（TDesC）から派生し、リテラルテキストを扱うためのストリングクラスであって、前記リードオンリーメモリ又は前記ランダムアクセスメモリのうちヒープ領域以外のメモリ領域に該リテラルテキストを格納し、該テキストが格納されたオリジナルのメモリ領域にポインタを利用してアクセスするように定義された第１のストリングクラス（TPtrC）に属するオブジェクトを、該第１のストリングクラス（TPtrC）の定義にしたがって操作又はアクセスし、
   （ｂ）データの追加及び変更を可能とするメンバ関数を定義した、前記ベースクラス（TDesC）から派生した他のクラス(TDes)からさらに派生し、予め設定された最大長を超えない長さのテキストを前記ランダムアクセスメモリのうちヒープ領域以外のメモリ領域に格納し、該テキストが格納されたオリジナルのメモリ領域にポインタを利用してアクセスし、該最大長を超えない範囲で該テキストにデータを追加又は変更するように定義された第２のストリングクラス（TPtr）に属するオブジェクトを、該第２のストリングクラス（TPtr）の定義にしたがって操作又はアクセスし、
   （ｃ）前記ベースクラス（TDesC）から派生し、長さが制限されたテキストを前記ランダムアクセスメモリのうちスタティックメモリ領域に格納してアクセスするように定義された第３のストリングクラス(TBufC)に属するオブジェクトを、該第３のストリングクラス(TBufC)の定義にしたがって操作又はアクセスし、
   （ｄ）前記ベースクラス（TDesC）から派生した前記他のクラス(TDes)からさらに派生し、長さが制限されたテキストを前記ランダムアクセスメモリのうちスタティックメモリ領域に格納し、前記データの追加及び変更を可能とする複数のメンバ関数を利用してデータの追加及び変更をするように定義された第４のストリングクラス(TBuf)に属するオブジェクトを、該第４のストリングクラス(TBuf)の定義にしたがって操作又はアクセスし、
   （ｅ）前記ベースクラス（TDesC）から派生し、長さが動的に変化し得るテキストを、前記ランダムアクセスメモリのうちのヒープ領域を使用するために必要となるすべてのメモリ管理関数を利用して該ヒープ領域に格納してアクセスするように定義された第５のストリングクラス(HBufC)に属するオブジェクトを、該第５のストリングクラス(HBufC)の定義にしたがって操作又はアクセスする
   ことを特徴とする方法。
3. 単一のベースクラス（TDesC）から派生した、階層構造を有する５つのストリングクラスのオブジェクトを、リードオンリーメモリ、ランダムアクセスメモリおよびマイクロプロセッサを有するコンピュータ装置によって操作又はアクセスできるようにプログラムされたオブジェクト指向のコンピュータプログラムを格納した記憶媒体であって、
   前記コンピュータプログラムは、
   （ａ）前記ベースクラス（TDesC）から派生し、リテラルテキストを扱うためのストリングクラスであって、前記リードオンリーメモリ又は前記ランダムアクセスメモリのうちヒープ領域以外のメモリ領域に該リテラルテキストを格納し、該テキストが格納されたオリジナルのメモリ領域にポインタを利用してアクセスするように定義された第１のストリングクラス（TPtrC）に属するオブジェクトを、該第１のストリングクラス（TPtrC）の定義にしたがって操作又はアクセスする手段と、
   （ｂ）データの追加及び変更を可能とするメンバ関数を定義した、前記ベースクラス（TDesC）から派生した他のクラス(TDes)からさらに派生し、予め設定された最大長を超えない長さのテキストを前記ランダムアクセスメモリのうちヒープ領域以外のメモリ領域に格納し、該テキストが格納されたオリジナルのメモリ領域にポインタを利用してアクセスし、該最大長を超えない範囲で該テキストにデータを追加又は変更するように定義された第２のストリングクラス（TPtr）に属するオブジェクトを、該第２のストリングクラス（TPtr）の定義にしたがって操作又はアクセスする手段と、
   （ｃ）前記ベースクラス（TDesC）から派生し、長さが制限されたテキストを前記ランダムアクセスメモリのうちスタティックメモリ領域に格納してアクセスするように定義された第３のストリングクラス(TBufC)に属するオブジェクトを、該第３のストリングクラス(TBufC)の定義にしたがって操作又はアクセスする手段と、
   （ｄ）前記ベースクラス（TDesC）から派生した前記他のクラス(TDes)からさらに派生し、長さが制限されたテキストを前記ランダムアクセスメモリのうちスタティックメモリ領域に格納し、前記データの追加及び変更を可能とする複数のメンバ関数を利用してデータの追加及び変更をするように定義された第４のストリングクラス(TBuf)に属するオブジェクトを、該第４のストリングクラス(TBuf)の定義にしたがって操作又はアクセスする手段と、
   （ｅ）前記ベースクラス（TDesC）から派生し、長さが動的に変化し得るテキストを、前記ランダムアクセスメモリのうちのヒープ領域を使用するために必要となるすべてのメモリ管理関数を利用して該ヒープ領域に格納してアクセスするように定義された第５のストリングクラス(HBufC)に属するオブジェクトを、該第５のストリングクラス(HBufC)の定義にしたがって操作又はアクセスする手段と
   を前記コンピュータ装置に機能させることを特徴とする記憶媒体。

Images