C ++開発でSTLを放棄することは現実的ですか？
一部の領域（ゲーム業界など）では、STLは推奨されません。だから私の質問です：場合によってはSTLを使用しないことが本当に良い習慣ですか？もしそうなら、最新のC++のSTLを使用しない最大の理由は何ですか？
正当な理由は1つしか考えられませんが、それは非常にまれです。ハードリアルタイムです。標準ライブラリの多くのものは内部的にメモリを割り当てますが、ハードリアルタイムアプリケーションには十分に確定的ではないため、回避する必要があります。これらのアプリケーションは通常非常に単純ですが、非常に厳密なレビューとテストのため、開発にはかなりの時間がかかります。
無効ですが、非常に一般的な理由が1つ考えられます。計算の複雑さを理解していない開発者がSTLを誤用し、ライブラリのせいにします。
STLは通常、実行時にコールバックポインターを使用するCスタイルのソリューションや仮想メソッドを使用するポリモーフィズムベースのソリューションよりも高速です（ このBjarne Stroustrupの基調講演も参照 ）。しかし、開発者が与えられた複雑さの仕様を理解せず、いくつかの複雑なオブジェクトのベクトルのベクトルのようなものを作成することによってライブラリを誤用する場合（ただし、C++ 11では問題ではなくなります！）、パフォーマンスの問題を引き起こし、自分自身を防御します。 「ご覧のとおり、ベクトルはかなり遅い」ということは、標準ライブラリが遅いという認識を引き起こす可能性があります。そしてマネージャーがそのような認識を得ると、それは組織内で非常に長く生きることができます。
明らかに、ターゲットとするプラットフォームがサポートしていないものは使用できません。ただし、現在4つの最も一般的なモバイルプラットフォーム（Android、iOS、Bada、古いWinCE）を対象としており、標準ライブラリと Boost の一部を使用しています。
WinCEの初期の段階では、標準ライブラリの多くはMicrosoftによってサポートされていませんでした（IIRC iostreamはVisual Studio 2005でのみ提供されました）が、その前に STLport を使用することが可能でした。そして、あなたは通常、それをコンパイルして何にでもすることができます。したがって、この理由も無効と呼びます。
その上、かなり長い間、それは「STL」ではなく、ANSI C++標準ライブラリです。言語自体を定義するのとまったく同じ標準ドキュメントによって定義されます。それをサポートしないものは、C++と呼ばれるに値しません。
私はSTLを使用しており、すでに何年もブーストしています。それを放棄してカスタムツールを使用したい場合、動機は次のようになります。
- コンパイル時間の短縮（75％）。 iostreamを含めるだけで、100万行のコードをモジュールに追加できます。はい、プリコンパイル済みヘッダーは非常に役立ちますが、それでも大きなプロジェクトではコンパイルが大幅に遅くなります。長い目で見れば、それに取り組む人の多くの時間を浪費します。
- パフォーマンス。 （25％）STLは一般的に機能するように作成されていますが、構造を最適化して希望どおりに機能させることができます。たとえば、何百万もの短い文字列を持つデータ構造があるとします。 boost :: small_vector（小さい静的ローカルデータベクトル、大きな文字列のみの動的割り当て）のプリンシパルに基づいてカスタム文字列クラスを使用する方がはるかに高速かもしれません。この種の変更により、コードの重要なセクションが何倍も速く動作するようになります。
C++標準テンプレートライブラリを使用しない大きな正当な理由が1つあります。ターゲットプラットフォームの1つに完全に準拠した実装がない（またはまったく実装されていない）ため、1つも取得されないことがわかっています。次の年以内に。
複雑さ（実装の効率性）はわかりませんが、標準のコンテナではなくQtコンテナと文字列を広範囲に使用しており、正常に動作します。また、セットとリストのQt実装の方が使いやすいと思います。
したがって、ニーズに合った別のライブラリを使用できる場合は、STLを放棄するのが現実的です。
パトリックが言及した STL全体を使用しない理由、つまり、プラットフォームにSTLがないため。
全体として、質問には要点が欠けていると思います。ほとんどの場合、それはオールオアナッシングの決定ではなく、選択の1つです。コンテナーとアルゴリズムを使用することもできますが、文字列とI/OにはStd Lib以外の何かを使用することにします。
大きな理由がない限り、それは現実的ではありません。私が考えることができるそのような理由のいくつかには、STL（または標準ライブラリの他の部分）の部分的または欠けている実装、またはあなたが回避しなければならないリソース制限（メモリ、CPU速度、ストレージなど）が含まれますあなたが達成する必要があることに固執する独自のツールを転がします。
ゲーム業界では、ほとんどの（ある程度小さい）スタジオに、内部ライブラリと、ターゲットプラットフォームに合わせて高度に調整された多くの標準ライブラリパーツの実装があります。簡単に言えば、コンソール向けのゲームを開発する場合、ハードウェアは今日の標準によって非常に制限されています。理由のため、手作りのアセンブリには何千ものラインがあります。コード内のすべての種類のリソースフットプリントを最小限に抑え、ゲームをより高速に実行して、ゲームの世界（またはより大きな世界など）でより多くのコンテンツを許可し、より良い製品を生み出すことが非常に重要です。
"すべての成功したゲームは、独自のリンクリストの実装を展開することから始まります。"