3

C++ 標準ライブラリは非常に汎用的で効率的なライブラリですが、そのインターフェイスの細かい点が少し残念に思えます。

  • アルゴリズムはコンテナーを直接受け取ることはできません。std::sort(myvec.begin(), myvec.end());の代わりにstd::sort(myvec);(最初から 2 番目のフォームが提供されなかった理由がよくわかりません)

  • 文字列を受け取る関数メンバーのほとんどは、const char *代わりに必要ですconst std::string&。(C++ 文字列はstd::string、少なくともオーバーロードが必要です)

私の知る限り、これら 2 つの小さな欠陥はc++0x標準で修正されるはずです。

これらのマイナーな欠陥の他のものを見ることができますか?
なぜそれが欠陥だと思いますか？
修正される日は来るのでしょうか？

(もちろん、ここでの議論はジェネリック プログラミングに賛成でも反対でもなく、実際には一般的な設計の問題についてでもありません。オーバーロードの欠落、アルゴリズムのバージョンの欠落、扱いにくいインターフェイスなどです。)

4

2 に答える 2

4
  • アルゴリズムはコンテナーを直接受け取ることはできません。std::sort(myvec.begin(), myvec.end()); std::sort(myvec); の代わりに

これは実際には機能です(C 配列のループを許可します) が、GMan がコメントで既に述べているように、改善される可能性があります。

  • 文字列を取るほとんどの関数メンバーには const std::string& の代わりに const char * が必要です

ほとんどのSTL関数はメンバーではなく、ほとんどが関数ではありませんが、関数テンプレートであり、（ほとんど？）文字列を排他的に扱うものはないため、これは明らかに間違っています。(おそらく、標準ライブラリ
の一部であるファイル ストリームについて話しているのでしょうが、STL に由来する標準ライブラリの一部ではありません。もちろん、それらが を使用するようになったのには理由がありますが、これはも改善される可能性があります。)const char*

そのため、STL を批判する多くの人と同じように、STL について十分に理解していないようです。それはそれについて批判することが何もないという意味ではありません。しかし、他の分野と同様に、これを行う前に、少なくとも物事がそのようになっている理由を知っておく必要があります。

于 2010-11-06T21:32:23.563 に答える
-6

などのアルゴリズムについてはsort、好きなようにラッパーを定義してください。

個々のラッパーを定義したくない場合は、マクロを定義します

#define ALL_OF( container ) startOf( container ), endOf( container )

適切なstartOf関数endOfテンプレートを使用すると、生の配列と標準ライブラリ コンテナーの両方でうまく機能します。

つまり、最初の問題は問題ではありません。

引数に関してconst char*は、通常、そうでないことは問題ではありませんstring const&。ただし、標準ライブラリにオーバーヘッドの少ない標準の文字列キャリアがあり、それが使用されていればよかったのにと思います。また、ファイル ストリーム コンストラクターなどでワイド文字列がサポートされていないことは実際の問題です (Windows コードでは標準外の拡張機能を使用する必要があります)。これは、実行環境用の正しいプログラムを標準 C++ で表現できない場合です。標準ライブラリのみを使用します。

もちろん、mainこれはコア言語とライブラリにまたがる問題です。

于 2010-11-06T21:33:47.410 に答える