web-dev-qa-db-ja.com

boost :: shared_ptrの使用からstd :: shared_ptrに切り替える必要がありますか？

GCCで-std=c++0xを使用してC++ 0xのサポートを有効にしたいと思います。 GCC 4.5（および4.6）で 現在サポートされているC++ 11機能 は必ずしも必要ではありませんが、それらに慣れ始めたいと思います。たとえば、反復子を使用するいくつかの場所では、auto型が便利です。

しかし、繰り返しますが、現在サポートされている機能はneed必要ありません。ここでの目標は、新しい標準の機能をプログラミングの「語彙」に組み込むことを奨励することです。

C++ 11サポートについて知っていることから、GCCでC++ 11を有効にしてから、たとえば、2つとしてboost::shared_ptrからstd::shared_ptrのみを使用するように切り替えることをお勧めします混ぜないで？

PS：私は この良い質問 を知っていますが、これはshared_ptrの異なるフレーバーを比較しますが、標準が完成する前に使用するより高いレベルのアドバイスを求めています。別の言い方をすれば、GCCのようなコンパイラが「実験的機能」をサポートしていると言った場合、コンパイル中にStackOverflowの大きな時間の流れや不可解な質問の原因となる奇妙なエラーが発生する可能性があるということですか？

Edit：std::shared_ptrから切り替えることにしました。GCC4.5でのサポートを この質問の例 。

c++booststlc++11shared-ptr
65
Alan Turing

std::shared_ptr に切り替える理由はいくつかあります。

  • Boostへの依存関係を削除します。
  • デバッガー。コンパイラとデバッガによっては、デバッガはstd::shared_ptrについて「スマート」であり、オブジェクトのポイントを直接表示する場合があります（ブーストの実装などではありません）。少なくともVisual Studioでは、std::shared_ptrはデバッガーではプレーンポインターのように見えますが、boost::shared_ptrは多数のブーストの内部を公開します。
  • リンクされた質問で定義されているその他の新機能。
  • Move-semanticsが有効になっていることがほぼ保証されている実装を取得します。これにより、refcountの変更をいくつか保存できます。 （理論的には、私はこれを自分でテストしていません） 少なくとも2014-07-22の時点で、boost::shared_ptrは移動のセマンティクスを理解しています。
  • std::shared_ptrは配列型でdelete []を正しく使用しますが、boost::shared_ptrはそのような場合に未定義の動作を引き起こします（shared_arrayまたはカスタム削除機能を使用する必要があります） （実際、私は修正済みです。 this を参照してください。この特殊化はunique_ptrのみであり、shared_ptrではありません。）

そして、一つの大きな明白な理由：

  • C++ 11コンパイラと標準ライブラリの実装に自分自身を制限することになります。

最後に、実際に選択する必要はありません。 （また、特定のコンパイラシリーズ（MSVCやGCCなど）をターゲットにしている場合は、std::tr1::shared_ptrを使用できるようにこれを簡単に拡張できます。残念ながら、TR1サポートを検出する標準的な方法はないようです）

#if __cplusplus > 199711L
#include <memory>
namespace MyProject
{
    using std::shared_ptr;
}
#else
#include <boost/shared_ptr.hpp>
namespace MyProject
{
    using boost::shared_ptr;
}
#endif
58
Billy ONeal

ブーストの使用量に依存すると思います。私は個人的には非常に控えめにしか使用していません（実際、1つのプロジェクトで乱数ライブラリを使用しています）。最近、他のプロジェクトで-std=c++0xの使用を開始し、共有std ::ライブラリ機能（shared_ptrなど）を使用しています。私は自分のプロジェクトに最小限の依存関係を持たせるのが好きなので、ブーストよりもコンパイラの標準ライブラリの実装に依存したいです。

しかし、私はこの質問に万能の答えがあるとは思わない。

13
Neil Butterworth

ブーストではなく、可能な場合は常に、std::shared_ptrを使用する必要があります。これは基本的に、shared_ptrを使用するすべての新しいインターフェイスが標準共有ptrを使用するためです。

12
Puppy

コンパイラで許可されている場合、std :: shared_ptrを使用する習慣を身に付けることは、おそらく悪い考えではありません。インターフェイスはboostのshared_ptrと同じなので、必要に応じていつでも元に戻すことができます。

7
Chris Mennie

実装の一貫性は別として、boost::shared_ptrは現在、std::shared_ptrに対して少なくとも2つのニッチな利点を保持しています。

4
dhaffey

std::shared_ptrに切り替えるもう1つの理由：std::unique_ptrをサポートします。つまり、コンストラクターがあります。

boost::shared_ptrはサポートしていません。

4
papafi

1つのプラットフォームで構築している場合は問題ありません（切り替えを行います）
（注：後方互換性を検証するための単体テストはありますか？）

複数のプラットフォームでコンパイルする場合、使用するすべてのプラットフォームでg ++ 4.5の機能が使用可能であることを検証する必要があるため、少し厄介になります（つまり、MAC/Linux用に構築するデフォルトのMac g ++コンパイラはまだLinuxのデフォルトコンパイラの背後にあるバージョン）。

4
Martin York

Std :: shared_ptrはboost :: shared_ptrよりも速いことがわかりました。テストを行いました。コードを確認し、ブースト、Qt、およびstd共有ポインターを比較する円グラフの結果を確認できます。

enter image description here

https：//www.osletek.com ...

1
rosewater