Boost は、すべての C++ ユーザーが使用できる標準の非標準 C++ ライブラリであることを意図しています。オープンソースの C++ プロジェクトで利用できると仮定するのは合理的ですか、それとも依存関係が大きすぎますか?
dajobe
質問する
7230 次
10 に答える
45
基本的に、あなたの質問は「[フリー ライブラリ xyz] を C++ オープン ソース プロジェクトの依存関係として持つことは合理的ですか?」というものです。</p>
次に、Stroustrup からの次の引用を考えてみましょう。答えは本当に簡単です。
優れたライブラリがなければ、興味深いタスクのほとんどを C++ で行うのは困難です。しかし、優れたライブラリがあれば、ほとんどすべてのタスクを簡単に行うことができます
これが正しいと仮定すると (そして私の経験では正しい)、依存関係のない適切なサイズの C++ プロジェクトを作成することはまったく不合理です。
この議論をさらに発展させると、(開発者の) クライアント システムで合理的に期待できる C++ 依存関係 (システム ライブラリを除く)の1 つが Boost ライブラリです。そうではないことはわかっていますが、ソフトウェアが作成するのは不合理な推定ではありません。
ソフトウェアが Boost に依存することさえできない場合、どのライブラリにも依存することはできません。
于 2008-09-24T07:22:18.570 に答える
28
http://www.boost.org/doc/tools.htmlをご覧ください。具体的には、ブースト依存関係をプロジェクトに組み込みたい場合は、 bcpユーティリティが役立ちます。Web サイトからの抜粋:
「bcp ユーティリティは、Boost のサブセットを抽出するためのツールです。Boost とは別にライブラリを配布したい Boost 作成者や、Boost のサブセットをアプリケーションと共に配布したい Boost ユーザーに役立ちます。bcp は、コードが依存している Boost の部分と、それらの依存関係で使用されているライセンスについても報告できます。」
もちろん、これにはいくつかの欠点がある可能性がありますが、少なくともそうなる可能性があることを認識しておく必要があります。
于 2008-09-24T07:19:21.013 に答える
13
以前はシステムに依存関係を導入することに非常に慎重でしたが、今では依存関係が大した問題ではないことがわかりました。最新のオペレーティング システムにはパッケージ マネージャーが付属しており、多くの場合、依存関係を自動的に解決したり、少なくとも管理者が必要なものを簡単にインストールできるようにしたりできます。たとえば、Boost は Gentoo-Postage では dev-libs/boost として、FreeBSD ポートでは devel/boost として利用できます。
最新のオープン ソース ソフトウェアは、他のシステム上に多くを構築しています。最近の調査では、FreeBSD パッケージの依存関係を追跡することにより、FreeBSD 4.11 システムの 12,357 ポート パッケージには合計 21,135 のライブラリ依存関係があることを確認しました。つまり、コンパイルするために、ベース システムの一部である 52 のライブラリ以外のライブラリが必要でした。ライブラリの依存関係は 688 の異なるライブラリで構成され、1 つのプロジェクトで使用される異なる外部ライブラリの数は 1 から 38 の間で変化し、モード値は 2 でした。さらに、5,117 のプロジェクトが少なくとも 1 つの外部ライブラリを使用し、405 のプロジェクトが 10 以上のライブラリを使用しました。 .
最後に、あなたの質問に対する答えは、コストと利益の分析から得られます。Boost のような、成熟し、広く使用され、レビューおよびテストされたライブラリを再利用するメリットは、依存関係の低コストおよび低下するコストよりも大きいですか? Boost の機能を簡単に使用する場合の答えは、先に進んで Boost を使用する必要があるということです。
于 2008-09-24T06:12:03.980 に答える
4
C ++コードを作成するときにブーストを使用する利点は、オープンソースコードを配布するという余分な複雑さを大幅に上回ります。
私はプログラマーのメモ帳で作業しており、コードはテスト、スマートポインター、およびPython統合のブーストに依存しています。要件のためにいくつかの苦情がありましたが、ほとんどの場合、コードで作業したい場合はそれを受け入れます。ブースト依存関係を取ることは、私が決して後悔したことのない決断でした。
他の人の複雑さを少し軽減するために、ブーストpython用のバージョン管理済みのビルド済みライブラリをインクルードして、インクルードディレクトリにブーストを提供するだけで済みます。
于 2008-09-24T10:56:43.097 に答える
4
KDE も Boost に依存しています。
ただし、それは主に目標に依存し、プロジェクトの範囲ではなく、ターゲット ユーザーにさらに依存します。たとえば、TinyJSON (非常に小さなプロジェクト) はほぼ 100% Boost ですが、それが提供する API は Boost に似ており、JSON バインディングを必要とする Boost プログラマーを対象としているため、問題ありません。ただし、他の多くの JSON ライブラリは、他の対象者を対象としているため、Boost を使用しません。
一方で、仕事で Boost を使用することはできません。また、他の多くの開発者 (日常の仕事) が同じ船に乗っていることも知っています。したがって、ターゲットがオープンソースであり、Boost を使用するグループである場合は、先に進むことができると思います。エンタープライズを対象とする場合は、プロジェクトを機能させるために、よく考えて、Boost から必要な部分だけをコピーして貼り付ける (そしてそのサポートにコミットする) ことをお勧めします。
- 編集:仕事で使用できない理由は、ソフトウェアが約 7 つの異なるプラットフォームと 4 つのコンパイラ間で移植可能でなければならないためです。したがって、すべてのターゲットと互換性があることが証明されていないため、boost を使用できません。理由は技術的なものです。(Boost を他の目的で使用することもあるため、OpenSource と Boost License の部分は問題ありません)
于 2008-09-24T06:02:20.230 に答える
4
場合によります。Boost で定義されたクラス テンプレートのみのヘッダー ファイルを使用している場合は、すべてのコードが外部依存関係なしでコンパイル時に生成されるため、Boost 共有ライブラリを吸い込まないため、そのまま使用してください。バージョニングの問題は共有 C++ ライブラリにとって厄介な問題であり、Boost もこの問題を免れることはできないため、この問題を完全に回避できるのであれば、それは良いことです。
于 2008-09-24T07:14:27.857 に答える
2
Boost が提供する広範な機能と、おっしゃる通り標準の非標準 C++ ライブラリであることが、依存関係として正当化されると思います。
于 2008-09-24T07:28:26.217 に答える
1
残念ながら、はい、ubuntu ではすぐに利用できますが、RHEL 4 および 5 では、ほとんどの場合、tarball から作成することになります。それらは素晴らしいライブラリであり、非常に大きなものです...たとえば、画鋲だけが本当に必要な場合にレール スパイクを使用するようなものです。
于 2008-09-24T06:01:42.243 に答える
1
それはすべて、Boost の使用方法によって異なります。ディオミディスが言ったように、Boost の重要な機能を使用する場合は、先に進んでください。図書館の利用は犯罪ではありません。
もちろん、新しい依存関係を導入することには常にいくつかの短所や余分な心配が伴うため、Boost を使用しないことを好む人はたくさんいますが、オープンソース プロジェクトでは...私の意見では、単に学習したいだけであれば、Boost を使用しても問題ありません。それらのスキルを向上させます。
于 2008-09-24T07:26:11.870 に答える