0

私のクラスでは、コンストラクターはプライベートであり、コンストラクターを使用してその share_ptr を返す静的メソッド「CreateMyClassPtr」を追加しました。

それは正しい実装ですか？

それが使用されることを確認する必要さえあると思いますshared_ptrか？決定するのはユーザーに任せるべきでしょうか？

4

4 に答える 4

3

そのコピーを保持していないが、ユーザーに を使用してポイント先のオブジェクトを削除してもらいたい場合は、 by 値deleteを返すことができます。std::auto_ptr依存関係を追加せず（標準の一部です）、オブジェクトをdauto_ptrにする必要があるという要件をインターフェイスに明確に伝えます。delete

ユーザーが望む場合はrelease、ポインターを手動で操作したり、共有スマート ポインター フレームワークに移動したりできます。

于 2010-03-15T08:12:49.933 に答える
2

要素は本当に共有されていますか? つまり、作成後、独自の目的でオブジェクトへのポインタを保持しますか?それとも、ユーザーのメモリ リークを避けるためだけにこれを行っていますか?

メモリが実際に共有されていない場合は、shared_ptr. 戻り値の型として使用shared_ptrすることにより、動的割り当てとスマート ポインターの特定の実装の両方の使用を強制することになりますが、型とより適切な他のスマート ポインター型のスタックの使用を制限することに注意してください (抽出することはできません)。共有ポインターからのメンバーシップ)

呼び出しがリークしないことを本当に確認したい場合 (つまり、ユーザーが関数を呼び出した場合、返されたメモリは「何らかの方法で」処理されます)、 std::auto_ptror boost::unique_ptr(最後のものは C++0x でも非標準です)を使用できます。どちらのソリューションでも、コードを呼び出してスマート ポインターからポインターを抽出し、別の方法でメモリ管理を行うことができます (場合によっては煩雑になる場合もあります)。

struct type {
   std::auto_ptr<type> create(); 
};
std::auto_ptr<type> ap = type::create();
std::shared_ptr<type> sp( type::create().release() );
type::create(); // will not leak memory
type *rp = type::create().release(); // user specifically requested a raw pointer!
于 2010-03-15T08:13:06.033 に答える
1

それはうまくいくでしょう、はい。しかし、本当に必要ですか？これが適切な状況もありますが、そうすると、実際には選択肢が制限されます。コンストラクターをそのように非表示にする場合、オプションとしてスタックベースの割り当てを排除していることは言うまでもなく、ユーザーが利用したいスマート ポインターの他の形式があります。

于 2010-03-15T08:15:52.363 に答える
0

クラスをクライアントに公開する場合は、共有ポインターの使用を強制しないでください。彼らは、オブジェクトを作成し、その削除に責任があることを知っています。

その後、彼らは簡単に書くことができます

myfavorite::api::shared_ptr<Class> object(Class::create());

また

std::auto_ptr<Class> object(Class::create());
于 2010-03-15T08:07:14.250 に答える