特にアプリケーション クラスで、iostream << 演算子のオーバーロードを記述する場合、そのストリーム オブジェクトで有効な標準マニピュレータに基づいて、そのオーバーロードの動作を変更することが望ましい場合があります。<< オーバーロードの実装内からストリームの標準マニピュレータの状態をポーリングできますか?
たとえば、
std::cout << std::internal << myClassReference;
～とは異なる振る舞いをする
std::cout << std::left << myClassReference;
違いを超えて、<< のカスタム オーバーロードは、その実装でメンバー << に引き継がれている可能性があります。
iostream のマニピュレータの状態をポーリングできる場合、これはどのように行われますか? また、マニピュレータの状態を同様にポーリングできるように、カスタム マニピュレータを実装する人は何をすべきでしょうか?
C++ ストリームのフォーマット状態のポーリングは、すべての C++ ストリームが継承するクラスのflags()関数を使用して行うことができます。std::ios_base
この関数には、 で呼び出されるポーリング関数と で呼び出される設定関数flagsの 2 種類があります。これらの関数はどちらも、 を呼び出す前の状態のオブジェクトのコピーを返します。conststream.flags()stream.flags(mynewflags)fmtflagsflags
カスタム マニピュレータ セットを実装するのは少し難しく、実装者は最初にそれらのマニピュレータを格納およびアクセスする方法を決定する必要があります。個人的には、おそらく間接的に から継承する別のストリーム オブジェクトを実装しstd::ios_base、それを使用してベース ストリーム (おそらく標準ライブラリの 1 つだけで、この新しいクラスはストリーム タイプでテンプレート化されている可能性があります) と追加のストリームの両方をカプセル化することを好みます。マニピュレータ フラグ。それ以外の場合は、外部変数のマニピュレータ フラグをチェックする方法、または任意のoperator<<出力関数で変数を渡すことを忘れないようにする方法が必要になります。これは、カスタム フラグをポーリングするために別のメンバー関数を作成する必要があることを意味しますが、実際にはそれが賢明に思えます。