mozilla
Your Search Results

    XPCOM ownership guidelines

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    原文書の情報

    • 著者: Scott Collins
    • 最終更新日: May 8, 2003
    • 著作権: Copyright© 1999 by Netscape; use is subject to the NPL. Portions of this content are © 1998–2007 by individual mozilla.org contributors; content available under a Creative Commons license | 詳細

    ドキュメントのタグと貢献者

    タグ: 
    Contributors to this page: kohei.yoshino
    最終更新者: kohei.yoshino,