C ++ゲーム開発者がBoostライブラリを使用しないのはなぜですか？[閉まっている]

したがって、C ++タグの下でStack Overflowの質問を見たり答えたりすることに時間を費やすと、ほとんどすべての人がboostライブラリを使用していることにすぐに気付くでしょう。使用しない場合、「本当の」C ++を書いているわけではないと言う人もいます（私は同意しませんが、それはポイントではありません）。

しかし、C ++を使用し、ブーストを使用しないことでよく知られているゲーム業界があります。私は仕方がありませんが、それがなぜなのか疑問に思います。私はゲームを（現在）趣味として書いているので、ブーストを使用する気はありません。その趣味の一部は、できるときに必要なものを実装し、できないときにすぐに使えるライブラリを使用することです。しかし、それは私だけです。

一般に、ゲーム開発者がブーストライブラリを使用しないのはなぜですか？パフォーマンスまたはメモリの問題ですか？スタイル？他に何か？

スタックオーバーフローでこれを尋ねようとしていましたが、ここで質問した方が良いと考えました。

編集：

すべてのゲームプログラマーの意見を話すことはできず、すべてのゲームプロジェクトを見たこともないので、ゲーム開発者は決して boostを使用しないとは言えません。これは単に私の経験です。

質問を編集して、ブーストを使用する場合、なぜ使用することを選択したのかを尋ねることができますか？

一部の開発者は使用しますが、一部の開発者は使用しません（ゲームなど）。それは、それらの開発者のニーズ/要件が何であるか、そして彼らが活用しなければならない既存のテクノロジーに依存します。

C ++の標準ライブラリは、しばしば同じ扱いを受けます。そして、人々はあなたがそれについて疑問に思っているのと同じことをしばしば疑問に思います。理由のほとんどは類似しています、例えば：

• 開発者は、標準ライブラリまたはBoostが提供するのと同じサービスを提供する機能の社内ライブラリをすでに持っている場合があります。このような社内ライブラリは、標準ライブラリの実装サポートが弱く、Boostが基本的に存在していなかったため、以前から記述されていることが多かったため、多かれ少なかれ記述する必要がありました。このシナリオでは、通常、社内の機能から移行する価値はあまりありません。多くのコードを不安定にし、ほとんど利益をもたらさない大きな移植作業になります。

• 開発者は、Boostが活用する高度なC ++技術のコンパイラサポートが十分にサポートされていないプラットフォームで作業している可能性があります。そのため、Boostコードはまったくコンパイルされないか、非常にパフォーマンスが低下します。これは標準ライブラリにも当てはまりますが、最近ではそうではありません。

• Boostと言語の標準ライブラリは汎用であり、それはほとんどのアプリケーションに適していますが、開発者はより専門的なコンテナでより適切に対処できる特定のニーズがある場合があります。

上記には2つの合理的な理由があると思いますが、確かに他の理由もあります。ただし、Boost、標準ライブラリ、または「ここでは発明されていない」シンドロームに帰着する理由を回避する多くの理由は、理由が実際の現実にあまり基づいていないことを示している可能性があるため、注意する必要があります。

また、大規模なスタジオのニーズは通常、個々の開発者のニーズとは非常に異なることを忘れないでください。たとえば、個々の開発者はおそらく、保守のために漂うレガシーコードが少ないため、おそらく、独自に開発したバージョンのBoostまたは標準ライブラリ機能からの移植は、それほど大きな時間はかからず、その開発者は保守する必要がありませんそのコードは将来的に広範囲に渡るので、私の最初の箇条書きは無効になります。

最後に、目的と目標に対する要件と時間の投資を評価し、ニーズに最適なオプションを決定することがすべてです。Boostまたは標準ライブラリを使用していない開発者は、通常、そのようにして、その結論に達しました。おそらくあなたもそうするかもしれません。

編集数年後にこの質問に戻る
ブーストライブラリをさらに使用し続けているため、この質問を更新して、製品の説明が目的の機能と一致する場合にブーストを使用する理由を明確に説明すると思いました。これは、反対意見の人でも納得させるでしょう。openSSLをダウンロードして、クライアントとサーバーアプリケーションを作成してみてください。次に、すべてのプラットフォームでそれが機能するようにしてください。次に、boost :: asio :: sslをダウンロードして使用し、同じアプリケーションを作成します。クリーンで、最適化され、ピアレビューされた、クロスプラットフォームのコードを探すのにブーストが適切な場所であると確信していない場合、この簡単な演習はあなたを変えます。

Tl; drバージョン：

私の意見では、大量の強力な野生の獣であり、飼い慣らすのは簡単ではなく、基本的にあなたが方法を学ぼうとしているので、ブーストを使用しているインディーズまたは中小の開発会社のトンは見られませんそれを使用します。ドキュメントはいくつかの点で不足しており（長いバージョンを参照）、プロジェクト周辺の「コミュニティ」が欠落している、散在している、または非アクティブである（他のプロジェクトと比較して）ようです。

非常に長いバージョン：

すでに受け入れられている答えがあることは承知していますが、私が行うほぼすべてのプロジェクトで実際にブーストを使用している人として、私は答えを投稿すると思いました。

私が最初にブーストをぶらぶらしたときのことを覚えていますが、正直なところ、何が起こっているのか気になりませんでした。Boostのドキュメントはあまりありません。サンプルコードやコメントなどのスニペットがたくさんあるので、人々は私に同意しないかもしれませんが、それはすべて非常に寒くて曖昧であり、ナビゲートするのが難しいです。

また、プロジェクトの周りに「コミュニティ」を見つけたと感じる場所を見つけるのは難しいようです。実際、コミュニティは存在しない、または遊牧民のようです。あいにく、彼らのメーリングリストでさえも非常に多くのヒルのサイトでトローリングされているので、このウサギの穴を下って、常にあなたが始めた場所にループバックすることができます。

これらの2つの要因により、ブーストライブラリの使用を学ぶのはかなり困難な作業になります。ブーストを使用する技術はそれほど複雑ではありませんが、それは膨大なライブラリのセットであり、いくつかのコードスニペットとインターネットの最も暗い隅から散らばったメーリングリストの断片だけで武装しているのです。 ...さて、あなたはアイデアを得る。

バージョン1.45を中心にブーストをいじくりまわしましたが、バージョン1.52 / 1.53でのみ、本番環境で使用できるようになりました。ライブラリがどのように構築され、機能がどのようにカスタマイズできるかにより、コンパイル時の設定に応じて大幅に変化する可能性があるため、ブーストを設定した方法やその設定を覚えているなどの簡単なことでも、慣れて覚えておくべきことがたくさんありますあります。

ただし、間違いを犯さないでください。一度ブーストを振ると、強固なクロスプラットフォームプログラムを迅速に構築するための強力な武器が手に入ります。ちょうど取るboost::asio例えば。わずか数百行で、非常に強力でスケーラブルで堅牢なクロスプラットフォームの非同期Webサーバーを作成できます。私は長年にわたって複数のクライアント、サーバー、プロキシなどを、わずか数百行のコードで記述してきましたが、それぞれがまだ失敗することはなく、プラットフォームからプラットフォームに数分で移植できます。

他の人が指摘しているように、大企業は通常レガシーなものにこだわっているか、完全に理解している独自のものをロールバックしたいと思っています。また、私が聞いたことがあり、開発リーダーやプロジェクトマネージャーが「大きすぎる」ためにブーストを使用することを禁止しているという、本当にばかげたこともあります。私の推測では、ブーストは1つのライブラリであると信じているか、BCPを聞いたことがないということです。

ブーストを使用する理由

あなたがあなたの質問で暗示しているように、それは「the」C ++ライブラリだからです。Boostは、C ++の世界では、最終的に使用する必要があるもののスイスアーミーナイフと見なされています。そのため、ニーズがある場合は、パフォーマンスの高い、移植性の高いバージョンが必要です。大企業はブーストに貢献し、印象的な履歴書を持つ非常に教育を受けた人々が貢献し、維持します .C ++の新しい標準が開発されているとき、人々は通常、ブーストしてその一部をISO標準C ++にする必要があるかどうかを確認します。

したがって、おそらく既存のライブラリがある可能性のある機能を追加する必要がある場合、私はそれがかなり適切に最適化されており、移植性があり、非常に長い時間とバグが発見され、対処されます。オープンソースの世界では、これらの資質を手に入れるのは非常に困難です。

私たちは古い職場で少しBoostを使用していました。主にそれを回避し、その使用を制限する主な理由は次のとおりです。

• コンパイル時間-その一部はコンパイルが非常に遅く、最終的に任意のヘッダーに#includeを追加することに消極的です
• 複雑さ-ほとんどのゲーム開発者にはあまり知られていないため、コードが読めない
• パフォーマンス-いくつかの概念はデフォルトでゆっくり実行されます。shared_ptr

「より標準的な」STLについても同じことが言われていました（だった？）。この記事では、EASTLについて説明します。EASTLは、Electronic ArtsによるSTL（の一部）の社内書き換えであり、「より汎用的な」アプリケーション開発とは異なるゲーム開発のニーズに対応しています。

そのため、誰かがゲーム開発のニーズに合わせて（一部）ブーストを書き直しているのかもしれません！

ブーストを使用しないと誰が言いますか？ブーストを使用した1つまたは2つのC ++エンジンを知っています。私は彼らと直接仕事をしたことはありません。しかし、それはほとんどが私の体験がアンリアルにあるからです。

ブーストを使用しないために遭遇した理由については、これらは主観的です：

• 展開先のプラットフォームに固有の独自のデータ構造を展開するのが好きです
• 特に外部コードが他の外部開発ライブラリに依存している場合、プロジェクトで使用する必要がある非内部開発コードの量を制限するのが好きです。

基本的には次のとおりです。一般的な解決策は常に「適切」ではありません。

ライブラリで実際に働いている人は、より良いコメントができると確信しています。

StackOverflowにたむろして、ブーストを使用しません。それがまだ言及されていないので、私は私の理由を追加します。

Boostには本当に素晴らしいアイデアがたくさんあります。彼らがしたことを見て、新しいことやアイデアを試すのが好きです。C ++の多くの改善の基盤となっているため、すばらしいです。

しかし、多くの理由から、ブーストは非常に扱いにくい獣です。理由の1つは、事実上すべてのコンパイラと互換性が必要である（必要な）ことです。その結果、彼らはそれを引き出すためにMPLのような多くのトリックを使用する必要があります。たとえば、（かなり前に）shared_ptrを使用したかったため、実行するには、90％のブーストのようなソースとライブラリが必要でした。私は自分で書きました。読み取り可能な50行のコード。（weak_ptrやスレッドセーフがないなど、より厳しい場合の私の要件。）

多くの場合、ブーストの非常に小さなサブセットが必要ですが、ブースト全体を統合するのは面倒なだけの価値はありません。

編集：

明確にすることは明らかです。なぜなら、はっきりとやってきたわけではないように見えるからです（つまり、下票）。私はサードパーティのライブラリを使用しています。しかしほとんどの場合、すべてが平等で、サードパーティのライブラリまたはブーストを統合すると、他のサードパーティのライブラリはより速く、よりクリーンになります。残りは「2時間」の指のエクササイズで行われます。私はそれを構築するか、質問を購入するのに非常に一生懸命見てください。

私たちの場合（ゲームではなく）、boost（nor std）を使用しない大きな理由があります。10年前のコードがたくさんあります。シニアによると、stdとboostは不完全で、バグがいっぱいであるか、必要な高性能なものには遅すぎます。そのため、同じ概念（イテレータなど）を使用していくつかの基本クラスが実装され、アルゴリズム用に最適化されていることがよくありました。現在、3つのライブラリ（ours、std、boost）はすべて非常に似ています。

しかし、すべてのコードを移植したいのでしょうか？あんまり。他の多くの企業も同じジレンマに直面していると思います。多くのテスト済みで動作するコードを書き換えるか、std / boostを使用しないでください。

ゲームは一般的な目的ではないため、ゲームを作成するときにブーストやその他の汎用コードを個人的に使用することはありません。ゲームの実装に必要なコードの種類は通常、ゲーム開発に固有のものであり、常にではなく、98％（ランダムな数字）のようなものです。boostや他のlibの最後の数ビットのコードを追加することもできますが、必要な部分をあちこちに記述する方が良いでしょう。

余談ですが、c ++で独自のコードを記述するのはかなり楽しいと思います。そのため、boostなどを使用したことはありません。

ハウスライブラリのレガシーは要因ではありません...誰もが他の汎用ライブラリにブーストを使用してはいけない主な理由は、速度とメモリが最適化されていないためですそれはSTLPortと呼ばれるオープンソースバージョンであるため、STLの使用を恐れてはいけません。カスタムアロケータを実装するだけで大​​丈夫です。ブーストthoを使用しないでください。