原文書の情報もしあなたがそれを作ったのであれば、それを所有している...自然なことです。あなたが一時的なオブジェクトを作ったのであれば、明らかにそれを破壊するのはあなたの責任です。それは確かに所有の徴候です。あなたがより長い生存期間を持つオブジェクトを作ったのであれば、あなたは所有権を失うまでそれを所有することになるでしょう。すべての「factory」と「getter」関数は所有するポインターを作り出す。そのような関数は、より長い生存期間を持つオブジェクトを作る絶好の例です。これはファクトリ関数にとってすばらしいことです。単なる「getter」にとっては問題となりうるかもしれません。間しかアクセスが必要ないのであれば、運が悪いということになります。後者の場合、ポインタをキャッシュした場合、あなたはデフォルトの所有者になります。これは、適切でないかも知れません。問題のオブジェクトがあなたのクエリに対して作られのかどうかを知らずに修正するのは大変かもしれません。それを必要としているかどうかは、それを所有していることの正当な理由にはならないあなたがオブジェクトを必要としているからと言って、そのオブジェクトを所有しているわけではありません。実際、しばしばオブジェクトがあなたを必要としているために、そのオブジェクトを所有していることがあります。あなたがオブジェクトを所有しているのならば、それはあなたを所有すべきではない。推移的な意味でもそのことが言えます。どんなシステムにおいても所有権のグラフは非循環的でなければなりません。所有権の循環が存在する場合、デストラクターによって自動的に処理されない場合があります。循環を断ち切るには、参加者が個別に解放する前に、特別なコードが提供されて呼ばれなければなりません。オブジェクトの生存期間があなたより長いことが保証されているのであれば、そのオブジェクトを所有する必要はない例えば、それがあなたを所有している時です。(そして逆ではない)親は自分の子を所有する必要はないかもしれませんが。ツリーはその中にあるすべてのノードを所有するかもしれません。ツリーのすべてのノードが、お互いを非所有的なポインターでポイントしているかもしれません。単純な枠組では、親は自分の子を所有的なポインターでポイントし、子は自分の親を非所有的なポインターで指し返します。使いなさいそれは、明示的で効果的、かつとても頑丈です。「getter」と「setter」を書くのは簡単です。あなたはデストラクターに何も書く必要がありません。inbox.現在、ニュースレターは英語でのみ提供されています。従って私の個人情報を扱うことに同意します。