間違いなく、ほとんどの C++ プログラミング プロジェクトで STL を使用することを選択します。最近、「STLを使わないケースはありますか？」という質問がありました...
考えれば考えるほど、STL を使用しないことを選択する場合があるかもしれないことに気付きました...たとえば、コードベースが数年続くと予想される非常に大規模で長期的なプロジェクト...おそらくプロジェクトのニーズに正確に適合するカスタム コンテナ ソリューションは、初期オーバーヘッドに見合うだけの価値がありますか? STLにしないことを選択するケースはありますか？
STL を使用しない主な理由は次のとおりです。
どちらも実際には非常にまれな要件です。
長期的なプロジェクトでは、STL と機能が重複する独自のコンテナーを展開すると、メンテナンスと開発のコストが増加するだけです。
組み込みシステムなどの厳密なメモリ要件を持つプロジェクトは、ヒープから取得され、ヒープに戻されるものを制御および管理することが難しい場合があるため、STLには適さない場合があります。Evanが述べたように、適切なアロケータを作成するとこれに役立ちますが、使用されるすべてのバイトをカウントする場合、またはメモリの断片化に関係する場合は、STLが最適化されているため、特定の問題に合わせたソリューションを手動でロールする方が賢明です。最も一般的な使用法。
また、boost::arrayやboost::unordered_mapなど、現在の標準にはない、より適切なコンテナが存在するため、特定のケースでSTLを使用しないことを選択することもできます。
stl を使用することには非常に多くの利点があります。長期プロジェクトの場合、メリットがコストを上回ります。
そうは言っても、STL コンテナーは並行性をまったく処理しません。したがって、並行性が必要な環境では、Intel TBB 並行コンテナーなどの他のコンテナーを使用します。これらは、さまざまなスレッドがコンテナーを同時に変更でき、コンテナーへのアクセスをシリアル化する必要がないように、きめの細かいロックを使用してはるかに高度です。
通常、最善の策は、STL コンテナーを手巻きのコンテナーに置き換えるのではなく、STL をカスタム アロケーターと共に使用することです。STL の良いところは、使用した分だけ料金が発生することです。
これは典型的なビルド vs 購入のシナリオだと思います。ただし、この場合、私はほとんどの場合「購入」し、STL またはより良いソリューション (おそらく Boost からのもの) を使用してから、自分で作成すると思います。アプリケーションが使用するビルディング ブロックではなく、アプリケーションが行うことにほとんどの労力を集中する必要があります。
そうは思いません。独自のコンテナーを作成する際には、それらを STL と互換性のあるものにしようとすることさえあります。なぜなら、ジェネリック アルゴリズムのパワーが大きすぎてあきらめられないからです。独自のコンテナーを作成し、すべてのアルゴリズムをそのコンテナーに特化するだけの場合でも、STL は少なくとも名目上は使用する必要があります。そうすることで、すべてのソートアルゴリズムを sort(c.begin(), c.end()) で呼び出すことができます。たとえ動作が異なっていても、同じ効果を持つように並べ替えを特殊化する場合。
Symbian のコーディング。
STLPort は Symbian 9 をサポートしているため、STL を使用することに反対するケースは以前よりも弱くなっています (「利用できない」というのはかなり説得力のあるケースです)。 Symbian のやり方で物事を行う。
もちろん、これらの理由から、Symbian のコーディングは「C++ プログラミング プロジェクト」ではないと主張されるかもしれません。
私が取り組んできたプロジェクトのほとんどは、実際に使用可能な STL のバージョンよりもはるかに古いコードベースを持っていました。そのため、今は導入しないことにしました。
これが発生する可能性のある状況の 1 つは、STL から必要な機能を既に提供している外部ライブラリを既に使用している場合です。たとえば、私の会社はスペースが限られた領域でアプリケーションを開発しており、ウィンドウ ツールキットに Qt を既に使用しています。Qt は STL のようなコンテナー クラスを提供するため、プロジェクトに STL を追加する代わりにそれらを使用します。
私が見た主な問題は、非スロー演算子newに依存するレガシーコードと統合する必要があることです。
マルチスレッド コードで STL を使用する際に問題を発見しました。スレッド間で STL オブジェクトを共有しない場合でも、多くの実装では非スレッド セーフな構造が使用されます (インターロック インクリメント スタイルの代わりに参照カウントに ++ を使用したり、非スレッド セーフ アロケーターを使用したりするなど)。
これらのケースのそれぞれで、私はまだ STL を使用して問題を修正することを選択しました (必要なものを取得するのに十分なフックがあります)。
独自のコレクションを作成することを選択した場合でも、イテレーターでのみ動作するアルゴリズムやその他の STL 関数を使用できるように、イテレーターの STL スタイルに従うことをお勧めします。
私は1984年頃にCのプログラミングを始めましたが、STLを使用したことはありません。何年にもわたって、私は自分の関数ライブラリを作成してきましたが、STLがまだ安定していないか、クロスプラットフォームのサポートが不足しているときに、それらは進化して成長してきました。私の共通ライブラリは、他の人（主にlibjpeg、libpng、ffmpeg、mysqlなど）や他のいくつかのコードを含むように成長しており、外部コードの量を最小限に抑えたいと思っています。今ではSTLは素晴らしいと確信していますが、率直に言って、ツールボックス内のアイテムに満足しており、この時点でさらに多くのツールをロードする必要はないと考えています。しかし、私は確かに、新しいプログラマーがSTLを使用することで、すべてを最初からコーディングしなくても、大きな飛躍を遂げることができると考えています。
標準 C++ では、一部のイテレータ操作の実装が例外をスローすることを逆に許可しています。その可能性は、場合によっては問題になる可能性があります。したがって、重要な操作に対して例外をスローしないことが保証されている独自の単純なコンテナーを実装することができます。