XPCOM ownership guidelines

もしあなたがそれを作ったのであれば、それを所有している

...自然なことです。もしあなたが一時的なオブジェクトを作ったのであれば、明らかにそれを破壊するのはあなたの責任です。それは確かに所有の徴候です。もしあなたがより長い生存期間を持つオブジェクトを作ったのであれば、あなたは所有権を失うまでそれを所有することになるでしょう。

すべての「factory」と「getter」関数は所有するポインターを作り出す。

そのような関数は、より長い生存期間を持つオブジェクトを作る絶好の例です。そして、(すでに AddRef を実行したポインターをつくり出すことで) 所有権を (この場合は呼び出し元に) 与えます。これはファクトリ関数にとってすばらしいことです。しかし単なる「getter」にとっては問題となりうるかもしれません。しばらくの間しかアクセスが必要ないのであれば、運が悪いということになります。後者の場合、ポインタをキャッシュした場合、あなたはデフォルトの所有者になります。これは、適切でないかも知れません。そして、問題のオブジェクトがあなたのクエリに対して作られのかどうかを知らずに修正するのは大変かもしれません。

それを必要としているかどうかは、それを所有していることの正当な理由にはならない

あなたがオブジェクトを必要としているからと言って、そのオブジェクトを所有しているわけではありません。実際、しばしばオブジェクトがあなたを必要としているために、そのオブジェクトを所有していることがあります。

もしあなたがオブジェクトを所有しているのならば、それはあなたを所有すべきではない。

推移的な意味でもそのことが言えます。【訳注: A が B を所有し、B が C を所有する場合、C が A を所有してはいけない】 違う表現をすると: どんなシステムにおいても所有権のグラフは非循環的でなければなりません。所有権の循環が存在する場合、デストラクターによって自動的に処理されない場合があります。循環を断ち切るには、参加者が個別に解放する前に、特別なコードが提供されて呼ばれなければなりません。

オブジェクトの生存期間があなたより長いことが保証されているのであれば、そのオブジェクトを所有する必要はない

例えば、それがあなたを所有している時です。

親は自分の子を所有する (そして逆ではない)

親は自分の子を所有する必要はないかもしれませんが。例えば、ツリーはその中にあるすべてのノードを所有するかもしれません。ツリーのすべてのノードが、お互いを非所有的なポインターでポイントしているかもしれません。しかしながら、最も単純な枠組では、親は自分の子を所有的なポインターでポイントし、子は自分の親を非所有的なポインターで指し返します。

コンテナは、自分が含むものを所有する (そして逆ではない)

所有するポインターを実装するために、nsCOMPtr を使いなさい

それは、明示的で効果的、かつとても頑丈です。「getter」と「setter」を書くのは簡単です。そしてあなたはデストラクターに何も書く必要がありません。