C++ コード行の簡単なスニペットを作成するたびに
std::string s;
cin >> s;
行全体を取得するのではなく、空白で止まるのを忘れていたので、自分を呪っています。
そして、思い出すgetlineと、私はいつも 2 つの種類について混乱してしまいます。
std::string s;
getline (std::cin, s);
と：
char cs[256];
std::cin.getline (cs, sizeof (cs));
データ型以外にこれら2つに実際に違いはありますか?
C++のやり方は前者であるべきだと私には思えます。とにかくヌル終了文字配列の代わりに実際の文字列を使用する必要があるとすれば、どのような状況で後者を使用しますか?
そして、入力は実際には入力ストリームの範囲である必要があるため、前者の部分ではないのはなぜistreamですか?
グローバルなgetline()関数は、C++ std::stringオブジェクトで機能します。
istream::getline()メソッドは、「古典的な」C 文字列 (へのポインターchar) で動作します。
標準ライブラリは、IOStream、String、STL の 3 つの (主要な) 部分に加えて、いくつかのグッズや C ヘッダーで構成されていることに注意してください。
これらの部分が疎結合されていてもおかしなことは何もありません (そうでないことを望みますが)。
その他の不一致には、std::string::lengthvsが含まれます。std::string::size後者は STL とのインターフェイスの互換性のために追加され、前者は古いコードとの互換性のために保持されています。
これは、一般的なインターフェイス設計の問題です。 cin.getline()はリクエストを行う自然な方法ですが、ストリーム コードが に依存することを避けるために<string>、cin.getline(std::string&)機能を提供することはできません。文字列がスコープに取り込まれたら、独立したgetline(cin, s)ものを後で追加できます。とにかく、言語のすべての部分にchar*何もないので問題ありません。#include
いくつかの点では、言語が後のコードで既存のクラス (Ruby など) にさらに機能を追加できるようになっているのは良いことですが、別の点では、非ローカリゼーションは噛み付き、保守性を損ないます。それからもちろん、最小限のメンバー関数と多くの独立した関数についての一般的な議論があります。個人的には、インターフェースを直感的で表現力に欠けるものにするのではなく、それぞれ独自のものにするべきだと思います。
iostreams ライブラリ内のgetlineバリアントは文字列をターゲットとしてサポートしていないため、文字列ライブラリはサポートするバリアントを定義しました。
はい、最新の C++ の方法は、free 関数を使用して std::string を入力することです。
しかし、IOStream には std::string よりもはるかに長い歴史があり (標準バージョンは、少なくとも同じ設計の 3 番目の化身です)、その歴史は物事がそのようになっている理由を説明しています。
(getline メンバーには、動的割り当てを意味しないという利点があります。その特性は、便利な場合もありますが、ゼロからの設計ではおそらく十分ではありません)。