問題タブ [boost-smart-ptr]

scoped_ptrやshared_ptrなどのboost::smart_ptrをポリモーフィズムで使用できますか？

Boost スマート ポインターはポリモーフィズムで使用できますが、サブクラスをポインターに戻すにはどうすればよいでしょうか?

最後の行はコンパイルされず、error C2440: 'type cast' : cannot convert from 'boost::shared_ptr<T>' to 'boost::shared_ptr<T>'

私はC ++の初心者であるため、 shared_ptrドキュメントを理解するのに問題がありました。私のサンプルコードで私を助けてくれることを願っています:

次のエラーが表示されます。

よろしく

編集

@Space_C0wb0y の提案を適用した後:

次のエラーが表示されます。

私はそれを少しデバッグし、問題が原因であることがわかりました

また、関数内にない場合open_file、同じエラーが発生します

boost :: scoped_ptrではoperator*、operator->宣言されたconst関数ですが、これらは戻りT&、T*クライアントが基になるデータを変更できる可能性があります。これは論理的恒常性の概念に違反します（Myers、Effective C ++）

const関数にシグネチャが必要ではありませんか？

コピーオンライトを作成したいコンテナーでboost::scoped_arrayを使用していますが、scoped_arrayが機能しないのではないかと心配しています。どのboost::smart_ptrコンテナが、牛に安全なスコープアレイに最も近いですか？

私はいくつかのBoostコンポーネントで遊んでいますが、私が取り組んでいるプロジェクトで直接必要と思われるのはですboost::shared_ptr。

に必要なファイルだけを含めるのは難しいでしょうかshared_ptr、それとも少なくともBoost smart_ptrディレクトリのファイルだけをプロジェクトに含めるのは難しいでしょうか？それらはBoostの他の部分に外部依存関係があるようですが、Boostライブラリの特定のコンポーネントを使用する簡単な方法があると思いますが、それが欠けています。

必要なパーツを教えていただければ、良いチュートリアルを教えていただければ幸いです。

これはコンパイルされません。

しかし、これは：

この ：

私はそれがSFINAEと関係があると思います（私はまだ理解していません）？フレンド修飾子は、定義された関数を囲まれた名前空間の自由関数として配置しますか?

編集

投稿を削除した人は誰でも、メンバー関数は友人ではなくadd_ref、release(これらの特定のメンバー関数はドキュメントには記載されていません...) 問題を解決しました。friend修飾子でネストされた定義はどうなりますか?

私のプログラムは短くシンプルで、PCA 回帰クラスをテストするように設計されています。

これが生成する出力の末尾は次のとおりです。

ご覧のとおり、最後の出力は、スタック上にregressionPCAのインスタンスを作成する直前に設定したフラグからのものです。

これがそのクラスの宣言です。

出力を生成せずに終了するのではなく、boost の shared_array を含めたときにコア ダンプが表示されて、プログラムが最も不自然に終了したことに注意してください。理由がわかりません。

以下は、regressionPCA クラスの実装です。

「std::cout << "Flag ALPHA" << std::endl;」という行があるため、実行パスがコンストラクターに入らないことはわかっています。出力を生成しません。

それで、いくつかの謎。

1) なぜ単にブーストの shared_array を含めるだけでコア ダンプが発生するのですか? 2) 裸の配列ポインターに頼るとき (はい、メモリ リークについては知っていますが、それは今のところ私のトラブルの中で最も少なく、boost の共有配列が機能していれば回避できたはずです)、なぜ実行が開始されないのですか?私のコンストラクタ？

任意の洞察をいただければ幸いです。

ところで: 私の問題が GSL に関連していないように見えても、私が GSL でばかげたことをしていることに気づいたら、それについて知っていただければ幸いです。

そのため、これを処理するための最良のスマートポインターがあるかどうかを判断しようとして、かなりのグーグル検索を行いましたが、良い選択に落ち着くことができませんでした.

私はいくつかのクラス Car を持っているとしましょう。ジャンクヤードも持ってstd::map<int carkey, Car*>います。

Car* は、一部の Driver によって JunkYard に追加される可能性があります。Driver 自身が Car を新規作成しますが、Driver は Car* のすべての責任を即座に失います。

私はジャンクヤードがすべての車に責任を持つことを望みます.

1 日の終わりに、JunkYard はすべての Car を破壊し、シャットダウンします。

--

A) これがマルチスレッド アプリで、ドライバーが同時に車にアクセスでき、JunkYard が車を破壊できる場合、おそらく shared_ptr が最適ではないかと考えていました。これはやり過ぎですか？他のスレッドが車にアクセスすることはできますが、その車を長期間所有することはなく、常に JunkYard に属している必要があります。

B) これがシングル スレッドの場合、最良の選択は何か - まだ map< some_smart_car_ptr> であると仮定します。車自体を削除するコンテナを車に乗せたいと思います。たとえば、 map.erase(...) を呼び出すと、ポインターがマップから削除されるだけでなく、ポインターも削除されます。

ここでの簡単な質問:boost::shared_ptr自分自身を明示的に削除することは許可されていますか? あなたは今までにすべきですか？

明確にするために、私は、によって保持されているポインターを削除するという意味ではありませんshared_ptr。私は実際shared_ptrそのものを意味しました。ほとんどの人がそれをしないように提案していることを知っているので、明示的に実行しても問題ないかどうか疑問に思っていました.