CArray以前は、やなどの MFC コレクション クラスを使用していましCMapた。しばらくして STL コンテナに切り替え、しばらく使用しています。STLの方がはるかに優れていると思いますが、その正確な理由を特定することはできません. 次のような推論の一部：
私が思いついた唯一の理由は、コンテナーでアルゴリズムを使用できることです。ここで欠落している他の理由はありますか? STL コンテナーが MFC コンテナーよりも優れている理由は何ですか?
VC++ プロダクト ユニット マネージャーの Ronald Laeremans は、2006 年 6 月にSTL を使用するとさえ述べていました。
率直に言って、チームは同じ答えを出します。MFC コレクション クラスは、下位互換性のためにのみ存在します。C++ にはコレクション クラスの標準があり、それが標準 C++ ライブラリです。MFC アプリケーションで標準ライブラリを使用する場合、技術的な欠点はありません。
この分野で大きな変更を行う予定はありません。
Ronald Laeremans
代理プロダクト ユニット マネージャー
Visual C++ チーム
ただし、Windows のインストール フェーズで実行されるコードに取り組んでいたある時点で、STL コンテナーの使用が許可されず、代わりに ATL コンテナーを使用するように言われました (実際にCStringは、特にそうではないと思います)。コンテナ）。説明は、STL コンテナーには、コードを実行する必要があるときに実際には使用できない可能性があるランタイム ビットへの依存関係がありましたが、これらの問題は ATL コレクションには存在しなかったというものでした。これはかなり特殊なシナリオであり、コードの 99% には影響しません。
STL コンテナー:
ただし、STL 以外のものを使用することは、本質的に間違っているわけではありません。
MFC の良い点の 1 つは、MFC コードの大規模なコーパスがまだ存在することです。他の回答では、サードパーティの互換性について話しています。サードパーティの MFC ベースのものを忘れないでください。
コードの一部を再利用できる将来のプロジェクトがある可能性があるため、可能な限り標準/互換性のあるライブラリを使用することを常に好みます。将来のプロジェクトでどのライブラリが使用されるかはわかりませんが、標準/互換性のあるものを使用すると、コードを再利用できる可能性が高くなります。
また、ライブラリを使用すればするほど、より快適にすばやく使用できるようになります。ライブラリの学習に時間を費やすつもりなら、それが定着し、特定のプラットフォームやフレームワークに縛られないようにしたいと考えています。
もちろん、パフォーマンス、機能、使いやすさに関しては、私の選択がかなり似ていることを前提として、これらすべてを述べています. たとえば、MFC クラスがこれらの領域で十分に大幅に改善されている場合は、代わりにそれらを使用します。
実際、一部の MFC コンテナでも STL アルゴリズムを使用できます。ただし、STL コンテナーは別の非常に実用的な理由で好まれます。多くのサードパーティ ライブラリ (Boost、arabica、Crypto++、utf-cpp...) は STL で動作するように設計されていますが、MFC コンテナーについては何も知りません。
MFC コンテナーは、プライベートにされた割り当て演算子から派生し、割り当て演算子CObjectを持っています。CObject私は実際にこれが非常に面倒だと感じました。
std::vector、unlinke CArray、メモリブロックが連続していることを保証するため、Cプログラミングインターフェイスと簡単に相互運用できます。
std::vector<char> buffer;
char* c_buffer = &*buffer.begin();
それは簡単な質問に要約されると思います: 誰をより信頼していますか? Microsoft を信頼する場合は、引き続き MFC バリアントを使用してください。業界を信頼するなら、STL を使用してください。
私が STL に投票するのは、現在 Windows で実行されているコードを、明日別のプラットフォームに移植する必要があるかもしれないからです。:)
これは、やりたい仕事に適したツールがどれであれ、「より良い」というのは主観的な用語です。
コンテナを他の標準に準拠したコードで使用する必要がある場合、またはそれがプラットフォーム間で共有されるコードになる場合は、STL コンテナの方がおそらく適しています。
コードが MFC ランドに残り、MFC コンテナーが機能することが確実な場合は、それらを使用し続けてみませんか?
STL コンテナーは、本質的に MFC コンテナーよりも優れているわけではありませんが、標準の一部であるため、より幅広いコンテキストでより便利です。
前述の側面: サポートが充実している、標準が利用可能である、パフォーマンスが最適化されている、アルゴリズムで使用できるように設計されているなどの側面に加えて、もう 1 つの側面を追加する場合があります: タイプ セーフ、およびコンパイル時のチェックの負荷です。doubleから を描くことさえ想像できませんstd::set<int>。
移植性の議論を完全に却下するつもりはありません。現在 MFC を使用しているからといって、常に使用するわけではありません。また、主に MFC 用に記述している場合でも、コードの一部は、より一般的で標準に準拠していれば、他のアプリケーションで再利用できます。
STL を検討するもう 1 つの理由は、その設計と進化が、MFC や ATL などの以前のライブラリの恩恵を受けていることだと思います。非常に多くのソリューションがよりクリーンで、再利用可能で、エラーが発生しにくいものになっています。（私は彼らがより良い命名規則を持っていたらいいのに.）
イテレータを使用してあらゆる種類のシーケンスをアルゴリズムと組み合わせて、A) すべての適切な順列が可能であり、B) 普遍的に拡張可能であるため、(15 年前のコンテナ ライブラリの概念について考えると) そのようなライブラリです。 10年も経たないうちに、他のすべてを水からほとんど吹き飛ばしたという、驚くほど素晴らしいアイデアですか？
真剣に、STL には欠点があります (反復子の代わりに範囲を使用しないのはなぜですか? また、その消去と削除のイディオムは正確ではありません)。しかし、これは素晴らしいアイデアに基づいており、新しいコンテナーを学習する必要がない非常に十分な理由があります。新しい仕事に着手するたびに、アルゴリズム ライブラリを使用します。