誰がC ++のIOStreamsを設計/設計しましたか？それでも、今日の標準では十分に設計されていると見なされますか？[閉まっている]

まず第一に、私は主観的な意見を求めているように見えるかもしれませんが、それは私が求めているものではありません。このトピックに関する根拠のある議論を聞いてみたいです。

最近のストリーム/シリアライゼーションフレームワークがどのように設計されるべきかについて洞察を得ることを期待して、私は最近、Angelika LangerとKlaus Kreftによる本「Standard C ++ IOStreams and Locales」のコピーを手に入れました。私は、IOStreamsが適切に設計されていなければ、そもそもC ++標準ライブラリに組み込まれていないと考えました。

この本のさまざまな部分を読んだ後、IOStreamsが全体的なアーキテクチャの観点からのSTLなどと比較できるかどうか疑問になり始めています。たとえば、アレクサンダーステパノフ（STLの「発明者」）とのこのインタビューを読んで、STLに入った設計上の決定について学びます。

特に私を驚かせるもの：

• IOStreamsの全体的な設計の責任者は誰なのかは不明のようです（これについての背景情報をいくつか読みたいと思います。誰かが良いリソースを知っていますか？）。

• あなたは、あなたがあなた自身のクラスとの入出力ストリームを拡張したい場合、あなたはかなり不可解とメンバ関数名を混乱とのインタフェースを取得入出力ストリームの直接の表面、例えば下に掘り下げ例えば一度getloc/ imbue、uflow/ underflow、snextc/ sbumpc/ sgetc/ sgetn、pbase/ pptr/ epptr（とそこのおそらくさらに悪い例）。これにより、全体的な設計と単一の部品がどのように連携するかを理解することが非常に難しくなります。私は上記でさえ本は助けにならないことくらい（私見）。

したがって、私の質問：

あなたは（実際には存在している場合、今日のソフトウェアエンジニアリングの基準で判断しなければならなかった場合であるこれらの任意の一般的な合意が）、うC ++の入出力ストリームは、まだうまく設計されたとみなされますか？（ソフトウェアの設計スキルを、一般的に古いと考えられているものから改善したくありません。）

：いくつかの悪い考えのアイデアは、標準への道を見つけauto_ptr、vector<bool>、valarrayおよびexportちょうど少数を示すために、。だから私は必ずしもIOStreamsの存在を質の高いデザインのしるしとして受け取らないでしょう。

IOStreamsには、市松模様の履歴があります。これらは実際には以前のストリームライブラリを作り直したものですが、今日のC ++イディオムの多くが存在しなかったときに作成されたため、設計者には後知恵の利点がありませんでした。時間の経過とともに明らかになった1つの問題は、Cのstdioと同じくらい効率的にIOStreamsを実装することがほぼ不可能であるということです。ロケールの定義および実装方法。これについての私の記憶はかなりあいまいです、私は認めます。数年前、comp.lang.c ++。moderatedについて激しい議論の的となっていたことを覚えています。

誰がそれらを設計したかについては、元のライブラリは（当然のことながら）Bjarne Stroustrupによって作成され、Dave Presottoによって再実装されました。これは、Andrew Koenigのマニピュレーターのアイデアを使用して、Cfront 2.0用にJerry Schwarzによって再設計および再実装されました。ライブラリの標準バージョンは、この実装に基づいています。

ソース「C ++のデザインと進化」、セクション8.3.1。

今日のソフトウェアエンジニアリング標準で判断する必要がある場合（実際にこれらについて一般的な合意がある場合）、C ++のIOStreamsは適切に設計されていると見なされますか？（ソフトウェアの設計スキルを、一般的に古いと考えられているものから改善したくありません。）

いくつかの理由から、私はNOと言います：

不十分なエラー処理

エラー条件は、ではなく例外とともに報告する必要がありますoperator void*。

「ゾンビオブジェクト」アンチパターンは、このようなバグの原因です。

フォーマットとI / Oの分離が不十分

ストリームオブジェクトは、必要かどうかにかかわらず、書式設定のための追加の状態情報を含める必要があるため、ストリームオブジェクトが不必要に複雑になります。

また、次のようなバグを書く確率も高くなります。

using namespace std; // I'm lazy.
cout << hex << setw(8) << setfill('0') << x << endl;
// Oops!  Forgot to set the stream back to decimal mode.

代わりに、次のようなものを書いた場合：

cout << pad(to_hex(x), 8, '0') << endl;

フォーマット関連の状態ビットはなく、問題もありません。

Java、C＃、Pythonなどの「モダン」言語では、すべてのオブジェクトにI / Oルーチンによって呼び出されるtoString/ ToString/ __str__関数があることに注意してください。私の知る限り、C ++だけstringstreamが文字列に変換する標準的な方法として使用することにより、逆の方法でそれを行います。

i18nのサポートが不十分

Iostreamベースの出力は、文字列リテラルを断片に分割します。

cout << "My name is " << name << " and I am " << occupation << " from " << hometown << endl;

フォーマット文字列は、文全体を文字列リテラルに入れます。

printf("My name is %s and I am %s from %s.\n", name, occupation, hometown);

後者のアプローチは、GNU gettextのような国際化ライブラリに適応する方が簡単です。全文を使用すると、翻訳者により多くのコンテキストが提供されるためです。文字列フォーマットルーチンが並べ替え（POSIX $printfパラメータなど）をサポートしている場合は、言語間の単語の順序の違いもより適切に処理します。

これは純粋な意見なので、別の回答として投稿します。

入力と出力（特に入力）の実行は非常に難しい問題です。そのため、当然のことながら、iostreamライブラリには、十分な知識と完璧な知識がたくさんあります。しかし、どの言語のI / Oライブラリもすべてこのようなものであるように思えます。私は、I / Oシステムがそのデザイナーに畏敬の念を抱かせるような美しさを持つプログラミング言語を使用したことがありません。iostreamsライブラリには、特にCI / Oライブラリ（拡張性、タイプセーフなど）に比べて利点がありますが、優れたOOまたは一般的な設計の例として、それを保持している人はいないと思います。

C ++のiostreamについての私の意見は、特に自分のストリームクラスを実装することで実際に拡張を始めた後で、時間とともに大幅に改善しました。メンバ関数の名前が途方もなく貧弱であるにもかかわらず、拡張性と全体的なデザインに感謝し始めましたxsputn。とにかく、I / OストリームはCのstdio.hを大幅に改善したものだと思います。Cのstdio.hには型の安全性がなく、重大なセキュリティ上の欠陥がたくさんあります。

IOストリームの主な問題は、テキストフォーマッティングとシリアライゼーションという2つの関連するがやや直交する概念が混同することです。一方では、IOストリームは、人間が読める形式のオブジェクトのテキスト表現を生成するように設計されており、他方では、オブジェクトを移植可能な形式にシリアル化するように設計されています。これら2つの目標が同じ場合もあれば、深刻な不快感をもたらす場合もあります。例えば：

std::stringstream ss;
std::string output_string = "Hello world";
ss << output_string;

...

std::string input_string;
ss >> input_string;
std::cout << input_string;

ここで、入力として取得するものは、元々ストリームに出力したものではありません。これは、<<オペレーターが文字列全体を出力するのに対し、>>ストリームには長さ情報が格納されていないため、オペレーターは空白文字に遭遇するまでストリームから読み取るだけだからです。したがって、「hello world」を含む文字列オブジェクトを出力しても、「hello」を含む文字列オブジェクトのみを入力します。したがって、ストリームはフォーマット機能としての目的を果たしていますが、オブジェクトを適切にシリアル化してからシリアル化解除することに失敗しました。

IOストリームはシリアル化機能として設計されていないと言うかもしれませんが、その場合、入力ストリームは実際には何ですか？さらに、他の標準的なシリアル化機能がないため、実際には、I / Oストリームを使用してオブジェクトをシリアル化することがよくあります。boost::date_timeまたはを検討してください。演算子を使用してboost::numeric::ublas::matrix行列オブジェクトを出力する場合<<、>>演算子を使用して入力すると、まったく同じ行列が得られます。しかし、これを実現するために、Boost設計者は列カウントと行カウントの情報をテキストデータとして出力に保存する必要があり、人間が読める実際の表示が損なわれました。繰り返しになりますが、テキストのフォーマット機能とシリアル化の厄介な組み合わせです。

他のほとんどの言語がこれら2つの機能をどのように分離しているかに注意してください。たとえば、Javaでは、フォーマットはtoString()メソッドを介して行われ、シリアル化はSerializableインターフェースを介して行われます。

私の意見では、最良の解決策は、バイトベースのストリームを標準の文字ベースのストリームと一緒に導入することでした。これらのストリームは、人間が読める形式/表示を考慮せずに、バイナリデータで動作します。これらは、C ++オブジェクトを移植可能なバイトシーケンスに変換するために、シリアル化/逆シリアル化機能としてのみ使用できます。

私は常にC ++ IOStreamsが不適切に設計されていることを発見しました。それらの実装は、新しいタイプのストリームを適切に定義することを非常に困難にします。また、io機能とフォーマット機能も混在しています（マニピュレーターについて考えてください）。

個人的に、私が見つけたストリームの設計と実装の中で最も優れているのは、Adaプログラミング言語です。これはデカップリングのモデルであり、新しいタイプのストリームを作成する喜びであり、出力関数は、使用するストリームに関係なく常に機能します。これは、最も一般的な分母への感謝です。ストリームにバイトを出力すると、それだけです。ストリーム関数は、バイトをストリームに入れる処理をします。たとえば、整数を16進数にフォーマットするのは彼らの仕事ではありません（もちろん、クラスメンバーと同等の、タイプアトリビュートのセットがあり、フォーマットを処理するために定義されています）

ストリームに関してC ++が同じくらい簡単だったらいいのに...

IOStreamsの設計は、拡張性と有用性の点で素晴​​らしいと思います。

1. ストリームバッファー：boost.iostream拡張機能を確認してください：gzip、teeを作成し、ストリームを数行でコピーし、特別なフィルターを作成します。それなしではそれは不可能でしょう。

2. ローカリゼーションの統合とフォーマットの統合。何ができるか見てください：

   std::cout << as::spellout << 100 << std::endl;

   印刷可能：「100」またはさらに：

   std::cout << translate("Good morning")  << std::endl;

   内蔵のロケールに応じて「Bonjour」や「בוקרטוב」を印刷可能std::cout！

   iostreamが非常に柔軟だからといって、このようなことを行うことができます。

それはもっとうまくできるでしょうか？

もちろんできます！実際、改善できることがたくさんあります...

現在、から正しく派生させるのは非常に困難stream_bufferです。ストリームに追加のフォーマット情報を追加することは簡単ではありませんが、可能です。

しかし、何年も前に振り返ってみると、私はまだライブラリのデザインが十分に優れていて、多くのグッズを提供することができました。

常に全体像を見ることができるわけではありませんが、拡張機能のポイントを残すと、考えていなかったポイントでもはるかに優れた能力が得られます。

（この答えは私の意見に基づいています）

IOStreamsは、同等の関数よりもはるかに複雑だと思います。C ++で書くときも、「古いスタイル」のI / Oにはcstdioヘッダーを使用しますが、これははるかに予測しやすいと思います。余談ですが（実際には重要ではありませんが、絶対的な時間差はごくわずかです）、IOStreamsはCI / Oよりも低速であることが多くの場合証明されています。

IOStreamを使用していると、いつも驚きます。

ライブラリはテキスト指向で、バイナリ指向ではないようです。これは最初の驚きかもしれません。ファイルストリームでバイナリフラグを使用しても、バイナリの動作を得るには不十分です。上記のユーザーCharles Salviaはそれを正しく観察しました：IOStreamsはフォーマットの側面（たとえば、浮動小数点数の制限された数字など）をシリアル化の側面（情報の損失を望まない場合）と混合します。おそらくこれらの側面を分離することは良いことでしょう。Boost.Serializationはこの半分を行います。必要に応じて、挿入機能と抽出機能にルーティングするシリアル化関数があります。すでにあなたは両方の側面の間の緊張を持っています。

多くの関数は、意味がわかりにくいものもあります（たとえば、get、getline、ignore、readです。区切り文字を抽出するものも、抽出しないものも、eofを設定するものもあります）。さらに、ストリームを実装するときの奇妙な関数名（xsputn、uflow、underflowなど）について言及する人もいます。wchar_tバリアントを使用すると状況はさらに悪化します。wifstreamはマルチバイトへの変換を行いますが、wstringstreamは行いません。wchar_tでは、バイナリI / Oはそのままでは機能しません。codecvtを上書きします。

cバッファI / O（つまりFILE）は、C ++のI / Oほど強力ではありませんが、透過性が高く、直観に反する動作はほとんどありません。

それでも、IOStreamに出くわすたびに、火のように蛾のように引き付けられます。多分本当に賢い人が全体的なアーキテクチャをよく見ていればそれは良いことでしょう。

質問の最初の部分に答えざるを得ません（だれがそうしたのですか？）。しかし、それは他の投稿で答えられました。

質問の2番目の部分（うまく設計されているか？）については、私の答えは「いいえ！」です。ここに私が何年もの間信じられないことに頭を振らせる小さな例があります：

#include <stdint.h>
#include <iostream>
#include <vector>

// A small attempt in generic programming ;)
template <class _T>
void ShowVector( const char *title, const std::vector<_T> &v)
{
    std::vector<_T>::const_iterator iter;
    std::cout << title << " (" << v.size() << " elements): ";
    for( iter = v.begin(); iter != v.end(); ++iter )
    {
        std::cout << (*iter) << " ";
    }
    std::cout << std::endl;
}
int main( int argc, const char * argv[] )
{
    std::vector<uint8_t> byteVector;
    std::vector<uint16_t> wordVector;
    byteVector.push_back( 42 );
    wordVector.push_back( 42 );
    ShowVector( "Garbled bytes as characters output o.O", byteVector );
    ShowVector( "With words, the numbers show as numbers.", wordVector );
    return 0;
}

上記のコードは、iostream設計のためにナンセンスを生成します。私の理解を超えたいくつかの理由で、それらはuint8_tバイトを文字として扱いますが、より大きな整数型は数値のように扱われます。Qed Badデザイン。

これを修正するために私が考えることができる方法もありません。タイプは、floatまたはdoubleの場合もあります。そのため、「int」にキャストして、文字ではなく数値がトピックであることを愚かなiostreamに理解させます。

私の返信への反対票を受け取った後、おそらくもう少し説明の言葉... IOStreamの設計は、アイテムがどのように扱われるかをプログラマーに伝える手段を提供しないため、欠陥があります。IOStream実装は任意の決定を行います（バイト数ではなく、uint8_tをcharとして扱うなど）。彼らは達成不可能を達成しようとするので、これはIOStreamデザインの欠陥です。

C ++は型の分類を許可していません-言語には機能がありません。is_number_type（）またはis_character_type（）IOStreamが適切な自動選択を行うために使用できるようなものはありません。それを無視して、推測で逃げようとすることは、ライブラリの設計上の欠陥です。

認められていますが、printf（）は、一般的な "ShowVector（）"実装でも同様に機能しません。しかし、それはiostreamの動作の言い訳にはなりません。しかし、printf（）の場合、ShowVector（）は次のように定義される可能性が非常に高くなります。

template <class _T>
void ShowVector( const char *formatString, const char *title, const std::vector<_T> &v );

C ++のiostreamには、他の応答で指摘されているように、多くの欠陥がありますが、その防御に何か注意したいと思います。

C ++は、真剣に使用されている言語間で事実上ユニークであり、変数の入力と出力を初心者にとって簡単にします。他の言語では、ユーザー入力は型強制または文字列フォーマッターを含む傾向がありますが、C ++はコンパイラーにすべての作業を行わせます。C ++はこの点でそれほどユニークではありませんが、同じことが出力にもほぼ当てはまります。それでも、クラスやオブジェクト指向の概念を理解する必要がなく、C ++でフォーマットされたI / Oをかなりうまく行うことができます。繰り返しますが、もしあなたが初心者を教えているなら、それは大きなプラスです。

初心者にとってのこの単純さには代償が伴い、より複雑な状況でI / Oを処理するのは頭痛の種になる可能性がありますが、その時点までにプログラマーはそれらに対処できるほど十分に学習しているか、少なくとも十分に古くなっています。飲む。