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