cin.getlineとグローバルな getline関数が別の場所にある技術的な理由に興味があります。
cin のこれらすべての関数シグネチャを単純に定義しない理由は何ですか。
//THESE TWO EXIST
istream& cin::getline (char* s, streamsize n );
istream& cin::getline (char* s, streamsize n, char delim );
//THESE TWO COULD EXIST
istream& cin::getline (string &s);
istream& cin::getline (string &s, char delim );
他のタイプが追加される可能性があり、文字列を cin と結婚させたくないためでしたか?
多かれ少なかれ。「彼ら」はおそらく、おそらく結合を最小限に抑えるために、std::istreamがstd::stringに依存することを望んでいませんでした。
std :: getline（）<string>がモジュールで定義されていることに注意してください。
同様の質問については、私の回答を参照してください。これは C++ 標準委員会による見落としかもしれませんが、依存関係の問題で説明することもできます。標準がヘッダーstd::stringで関数のオーバーロードを必要とする場合、実装者はin . これは依存関係の要件であり、コンパイル単位自体が を必要としない場合でも、必要なもののコンパイルがさらに遅くなります。<iostream>#include<string><iostream><iostream>std::string
一方、ヘッダーにはおよび<string>への参照を取る関数があることに注意してください。ただし、標準では、すべての IO 機能を前方宣言するという名前のヘッダーも必要であり、ヘッダーはコンパイル時の高速ヘッダーに依存します。逆の依存関係は、コンパイルがはるかに遅くなります。std::basic_istream<>std::basic_ostream<><iosfwd><string><iosfwd>
C++ 標準委員会が標準ライブラリ内の機能間の相互作用を実際には最適化していない場所がいくつかあります。
std::string とライブラリでのその使用は、これらの 1 つです。
もう 1 つの例は std::swap です。多くのコンテナーにはスワップ メンバー関数がありますが、std::swap のオーバーロードは提供されません。同じことが std::sort にも当てはまります。
これらの小さなことがすべて、次の標準で修正されることを願っています。
関連性があり、回答を受け入れているように見えるため、他のスレッドで見つけたこの投稿を追加します。