2009-08-24 13 views
1

私の会社は現在ブーストライブラリによって賞賛されていませんし、私がそれらを使っていて何らかの作業のためにプッシュしている間に、その性質上いくつかのプロジェクトは使用できませんブースト。基本的にBoostのようなライブラリは仕事に持ち込むことができないので、デフォルトで利用できるライブラリ(現在はVisual Studio 2005を使用しています)に限られています。ブーストポインタのないstlコンテナの使用

So ...私の質問は、Boost :: shared_ptrとその兄弟を使用することができない場合、STLコンテナでポインタを使用する場合の代替方法は何ですか?

私が見る一つのオプションは、指定されたポインタの後にあるshared_ptrのようなコンテナクラスを書くことですが、最初に他の選択肢があるかどうかを知りたいと思います。

+17

ブーストコードをコピーして、クラスに自分の名前を付けてください。 –

+0

Neilのアイデアは単に素晴らしいです:) –

+0

あなたが派生製品にブーストライセンスを含めない限り、それはまた、ブーストライセンスの違反です。ライセンシングの恐怖は、外部コードを使用する危険性の一部であるため、この特定の行動措置はおそらく友人を育てる最良の方法ではありません。 –

答えて

3

もし彼らがブーストを受け入れるつもりがなければ、私は他の "ここでは開発されていない"ライブラリは疑問に思っていません。

  • ロール、独自のshared_ptr:

    それは私には思われる次の2つのオプションが残っています。

  • 生ポインタを使用し、自分でメモリを管理します。

どちらも理想的ではなく、それぞれ独自の痛みがあります。あなたの恩恵は、あなたが利用できるようにするためのすべてのソースを持っていることかもしれません。あなた自身のshared_ptrを書くためのモデルとして使うことができます。

+0

単純な非スレッドセーフなshared_ptrは問題ではありません。スレッドセーフを追加すると、問題がより複雑になる可能性があります。 –

+0

そこに良い照明と良い例があります。 – luke

+0

あなたが何をしているかに応じて、手動メモリ管理(コンテナ破壊前にすべてのポインタを自分で削除する)はそれほど難しくないかもしれません。 同じルートを使い、私たちのコードベースでboostを使うことができなかったので、私たち自身のshared_ptr実装を作成しなければなりませんでした。 –

1

これはあなたが何をしたいのかによって決まります。あたかもポインタを使うプロジェクトにshared_ptrが絶対必要であるかのようにはなりません。

本当に必要な場合は、可能であれば、自分のプロジェクトに本当に必要なクラス/テンプレート/関数を、すべてのboostライブラリをインポートせずにインポートします。

+0

コーディング基準と法的観点(FOSS)から承認されたものを取得することに至りました。ここのほとんどの人は、法的な面は大丈夫だと認識していますが、正式には述べられていないので、ブーストからコードをインポートすることはできません。例外はありますが、私はBoostを承認することを目指していますが、現在は残念です。 –

+0

あなたは自分でコードを書くことについて話しました。私の考えは、あなたがブーストコードを取ることでしたが、社内では自分のコードとして扱いました。利点は、多くの人がすでにコードをテストしていることです。 – StampedeXV

2

Visual Studio 2008には、std::tr1::shared_ptrがあります。私はそれがVS2005で利用可能であるかわからない、あなたはチェックする必要があります。

+0

いいえ、それを見ることはできません。私はTR1を他の仕事に使っていますが、この仕事はVS2005を使っています。 –

+0

さて、まだその実装をコピーすることができます。私はそれがよりコピー可能な実装を高めると信じています。 –

+0

@ JIa3ep:私は真剣にこれを疑う。結局のところ、商業会社(Dinkumware)の仕事です。 – sbi

0

バックグラウンドを知らないと、なぜブーストのライブラリが許可されていないのかは分かりません。要するに複雑な依存関係を避けるためには、簡単に問題を回避することができます。ほとんどのブーストライブラリは、単純に#includeヘッダーだけで動作します。つまり、リンクする必要がないため、dll-hellやその変形が避けられます。

外部ライブラリが(静的であれ動的であれ)リンクの複雑さのために評価されない場合は、必要なブーストヘッダを手作業でプロジェクトにコピーして直接使用することができます。

明快さと将来のアップグレードとメンテナンスを容易にするために、私はブーストライブラリの名前を変更しないでください(将来のコード作成者はコードがどこから来たのか分かります)。 "彼ら"がそのような単純なコードの包含を望まないなら、あなたはかなりの数のブーストヘッダーが仕様に含めるべきであるという議論をすることができます。法的には、ブーストライセンスは、できるだけ簡単かつ安全に統合できるように特別に設計されています。すべてのファイルはすべての関連するものを許可する明示的なライセンスを持っており、ほぼすべてのライブラリがまったく同じライセンスを持っています。

私は不思議ですが、なぜ正確にブーストヘッダーが許可されていないのですか?

+0

基本的には、外部ライブラリが許可されていない、安全性が重視されているすべてのコード(ライブラリを含む)が必要であると主張する顧客の要件、法的な問題や全体的なコード、ライブラリ、アプリケーションなどは、使用のために承認される必要があり、それは承認に時間がかかることを意味します。いくつかはそれを得るだろう、他の人は私が選択肢を見ていない人にとってはそうではないだろう。 –

+1

必要なブーストヘッダを手作業でプロジェクトにコピーするだけでは簡単ではありません。 Boostはあなたがそれを知る前に100のファイルを含めることになるので、不毛なものです。はい、彼らはライブラリを分解するツールを持っています。あなたはそれを使って不快な経験を避けるのがよいでしょう。 –

+0

リンク時の依存関係を避けるためではないことに注意してください.2つの別々のdllから '同じ'インクルードクラスをエクスポートすることは、すでに標準コンテナでも問題になります。 – xtofl

関連する問題