マニュアルのトップに戻るには、このバナーをクリックしてください。
脚注
- 1
- この例では、通貨の値を示すクラス moneytype
が作成済みで、そのクラスの入出力ストリームの挿入演算子
<< と抽出演算子 >>
を作成済みであると仮定しています。また、これらの演算子による値の書式設定と構文解析は、現在処理を行っているストリームに組み込まれたロケールの
money_put ファセットと money_get
ファセットに基づいて行われるものとします。通貨の代わりに電話番号を取り上げた、この方法の詳しい例については、第 5 章を参照してください。 moneytype
クラスは標準 C++ ライブラリのクラスではありません。
戻る
- 2
- char や wchar_t
など、文字型のシフト演算子には、この規則を適用しません。これらは、標準ライブラリ
namespace ::std の大域関数です。
戻る
- 3
- ただし、これらのフラグの組み合わせが無効でも、入出力ストリームに設定することはできます。
戻る
- 4
- 標準では、ストリームのロケールの numpunct
ファセットにグループ情報がある場合に、それを無視するか、処理するかは指定していません。いずれにしても、グループ化をオン、オフするマニピュレータはありません。
戻る
- 5
- 空白文字の文字分類は、使用する文字セットによって異なります。抽出子では、ロケールの
ctype ファセットからこの情報を取り出します。
戻る
- 6
- ストリームバッファの作成が、ストリームに委託される場合もあれば、バッファがストリーム外から提供されることもあります。そのため、バッファのサイズがゼロになることもあります。
戻る
- 7
- 標準では、ストリームの内部データにメモリーを割り当てることができなかった場合に、badbit
を設定したり、bad_alloc や ios_base::failure
を送出するかどうかを指定していません。
戻る
- 8
- 実際には、標準では入出力ストリームにおけるメモリー割り当てエラーの処理方法を指定していません。基本的には、次の
2 つのモデルがあります。
-
例外マスクでビットが設定されているかどうかに関係なく、bad_alloc
例外を送出する。
- 内部資源 iword と pword
の割り当て時に送出された bad_alloc
例外をストリーム層で捕獲する。次に
badbit か failbit
を設定する。例外マスクの各ビットが対応する設定になっている場合に限って、例外が送出される。この場合に送出される例外は、ios_failure
か元の bad_alloc であるかを設定する必要があります。
さらに、ストリーム層では、ストリームバッファ層で送出されるすべての例外を必ず捕獲します。それによって、badbit
を設定し、例外マスクで問題がなければ元の例外を再度送出します。
戻る
- 9
- ストリーム状態か例外マスクが変化すると、例外が送出されます。これは、例外マスクの設定に応じて、関数
setstate() と exception() で例外が生成されるためです。
戻る
- 10
- Bjarne Stroustrup の『The C++ Programming Language,
3rd Edition』の 366 ページを参照してください。
戻る
- 11
- 在来型入出力ストリームではコンストラクタをサポートして、ファイルストリームを開かれているファイルに結合する、ファイル記述子を読み込んでいました。これは、標準入出力ストリームでは利用できませんが、Rogue
Wave
の標準入出力ストリームの実装では、対応する拡張機能を用意しています
(ファイルストリームについては、『標準 C++ クラスライブラリ・リファレンス』を参照)。
戻る
- 12
- 出力ファイルストリームの場合、オープンモードの
out は、out|trunc と等価です。すなわち、trunc
フラグを省略することができます。ただし、双方向ファイルストリームの場合、trunc
は明示的に指定する必要があります。
戻る
- 13
- 基本的に、バイナリモードフラグは、個々のオペレーティングシステムのサービス関数に渡ります。つまり
キャリッジリターンや改行処理だけでなく、システム固有の変換は、基本的にすべて無効になります。
戻る
- 14
- 旧来の入出力ストリームでは、これが異なり、動的出力ストリームと静的出力ストリームを使用することができました。詳細については、24.4 節を参照してください。
戻る
- 15
- ただし、変更されることがあります。このマニュアルの作成時点では、ストリームの
imbue() 関数に対する呼び出しでは、両方のロケールが変更されていました。
戻る
- 16
- ユーザーの便宜を図って、Manip
を静的オブジェクトまたは大域オブジェクトとして提供するための別の方法も可能です。この方法は、大域オブジェクトと静的オブジェクトに対して、初期化の順序に対して問題が発生することが明らかになっています。
戻る
- 17
- 在来型入出力ストリームには、ostream_withassign
というクラスがあり、ストリームオブジェクトのコピーと割り当てが明示的に可能になっています。
戻る
- 18
- 在来型入出力ストリームにはコピーコンストラクタと割り当て演算子が非公開メンバー関数として定義されています。そのため、使用することはできません。ストリームのコピーコンストラクタと割り当て演算子を、非公開メンバー関数として定義するかどうかは自由です。
戻る
- 19
- この機能は在来型入出力ストリームにはありましたが、標準入出力ストリームにはありません。Rogue
Wave
の標準入出力ストリームの実装では、在来型入出力ストリームとの下位互換性のために古い機能を残していますが、これは標準機能ではありません。この機能を使用すると、他の標準入出力ライブラリに対してアプリケーションを移植できなくなることがあります。
戻る
- 20
- ストリームバッファのロケールの設定を制御するか、その制御をどのようにするかは、特に指定されていません。このマニュアルの作成時点では、ストリームの
imbue()
関数に対する呼び出しで、ストリームバッファのロケールオブジェクトも変更されていました。上の例では、共有ストリームバッファのロケールオブジェクトは、file2
です。ストリームバッファでは、ロケールの変換ファセットを使用し、どちらのロケールともおそらく同じ
void
変換ファセットがあるはずなので、このことは問題にはなりません。ただし、ストリームのロケールに異なるコード変換ファセットがある場合は問題になります。
戻る
- 21
- 在来型入出力ストリームの strstream
では、ストリームの内部バッファに対するポインタを取り出すことができます。標準入出力ストリームの
stringstream と異なり、この場合は内部データのコピーは作成されません。そのため、標準
stringstream の代わりに陳腐化した機能である strstream
を使用することで、データの 2 番目のコピーを作成する手間を省略することができます。
戻る
- 22
- 入力ストリームの場合、sync()
の動作は実装定義であり、標準化されていません。在来型入出力ストリームには
sync()
関数があり、目的の同期化を実行します。すなわち、現在のファイル位置からバッファにデータを転送します。
戻る
- 23
- X/Open の関数 strftime()、strptime()、wcsftime()
を参照してください。
戻る
- 24
- ドラフト段階の資料によれば、これらは 2
つの独立した配列になります。ただし、RW
の実装では、1 つの配列だけの古い方法を使用します。
戻る
- 25
- この例では、エラー処理は省略しています。標準では
pword() と iword() による障害の表示方法が指定されていないためです。選択肢としては、bad_alloc 例外の送出と、failbit
の設定があります。
戻る
- 26
- これは、本格的な例ではありません。
1
つのデータメンバーを追加するためだけに新しいクラスを派生させることは、現実には考えられません。ただし、例を理解しやすくすることで、新しいストリームクラスの派生の原理を学ぶこができます。
戻る
- 27
- 問題とその対策の詳細については、Bjarne
Stroustrup の『The Design and Evolution of C++』Addison-Wesley
1994 の 14.2 節、p. 306ff
を参照してください。
戻る
- 28
- この方法の説明は、Steve Teale の『C++
IOStereams Handbook』Addison-Wesley 1993 の 6.10
節の p. 90ff
を参照してください。この例には、いくつかの深刻なバグがあるため注意してください。
戻る
- 29
- ASCII と EBCDIC の変換例はシングルバイトの文字変換であるため、partial
が返ることはありません。文字が認識されて変換されるか、変換が失敗して
error
が返るかのいずれかになります。この
partial
リターンコードは、ワイド文字と複数バイト変換の場合に有効です。
戻る
Copyright (c) 1998, Rogue Wave Software, Inc.
このマニュアルに関する誤りのご指摘やご質問は、電子メールにてお送りください。
OEM リリース, 1998 年 6 月