タグ付けされた質問 「smart-pointer」

11
スマートポインターが存在する場合にガベージコレクションを行う理由
最近では、非常に多くの言語がガベージコレクションされています。サードパーティによってC ++でも利用可能です。しかし、C ++にはRAIIとスマートポインターがあります。それでは、ガベージコレクションを使用する意味は何ですか?何か特別なことをしていますか? また、C#などの他の言語では、すべての参照が仕様と実装によってスマートポインターとして扱われる場合(RAIIは別として)、ガベージコレクターの必要性はまだありますか?いいえの場合、なぜそうではないのですか?

9
最終手段としてのstd :: shared_ptr?
「Going Native 2012」ストリームを見ているだけで、についての議論に気付きましたstd::shared_ptr。Bjarneのやや否定的な見方std::shared_ptrと、オブジェクトの寿命が不確かな場合の「最後の手段」として使用すべきだという彼のコメントを聞いて、私は少し驚いていました(彼によると、そうではないはずです)。 これをもう少し詳しく説明したい人はいますか?どうすればstd::shared_ptrオブジェクトの寿命を安全な方法で管理し、管理できますか?

1
raw、weak_ptr、unique_ptr、shared_ptrなど…賢明な選択方法は?
C ++には多くのポインタがありますが、C ++プログラミング(具体的にはQt Frameworkを使用)で5年ほど前に正直に言うと、古い生のポインタのみを使用します。 SomeKindOfObject *someKindOfObject = new SomeKindOfObject(); 私は他にも多くの「スマート」ポインターがあることを知っています。 // shared pointer: shared_ptr<SomeKindofObject> Object; // unique pointer: unique_ptr<SomeKindofObject> Object; // weak pointer: weak_ptr<SomeKindofObject> Object; しかし、私はそれらをどうするか、生のポインタの比較で彼らが私に何を提供できるのかについて少しも考えていません。 たとえば、次のクラスヘッダーがあります。 #ifndef LIBRARY #define LIBRARY class LIBRARY { public: // Permanent list that will be updated from time to time where // each items …

5
Java / C#でRAIIを実装できないのはなぜですか?
質問:Java / C#でRAIIを実装できないのはなぜですか? 明確化:ガベージコレクターは決定論的ではないことを認識しています。そのため、現在の言語機能では、オブジェクトのDispose()メソッドをスコープの終了時に自動的に呼び出すことはできません。しかし、そのような決定論的な機能を追加できますか? 私の理解: RAIIの実装は、次の2つの要件を満たす必要があると感じてい ます。1.リソースの有効期間はスコープにバインドされている必要があります。 2.暗黙的。リソースの解放は、プログラマーによる明示的なステートメントなしで行われる必要があります。明示的なステートメントなしでメモリを解放するガベージコレクターに似ています。「暗黙性」は、クラスの使用ポイントでのみ発生する必要があります。もちろん、クラスライブラリの作成者は、デストラクタまたはDispose()メソッドを明示的に実装する必要があります。 Java / C#はポイント1を満たします。C#では、IDisposableを実装するリソースを「using」スコープにバインドできます。 void test() { using(Resource r = new Resource()) { r.foo(); }//resource released on scope exit } これはポイント2を満たしません。プログラマは、オブジェクトを特別な「使用」スコープに明示的に結び付けなければなりません。プログラマーは、リソースをスコープに明示的に結び付けることを忘れる可能性があり(実際にそうします)、リークを作成します。 実際、「使用中」ブロックは、コンパイラーによってtry-finally-dispose()コードに変換されます。try-finally-dispose()パターンと同じ明示的な性質を持っています。暗黙のリリースがなければ、スコープへのフックは構文糖衣です。 void test() { //Programmer forgot (or was not aware of the need) to explicitly //bind Resource to a scope. Resource r …

5
C ++:クラスはその依存関係を所有または観察する必要がありますか?
class Foobarを使用する(依存する)クラスがあるとしWidgetます。Widget古き良き時代では、woludはのフィールドとして宣言されるFoobarか、多態的な動作が必要な場合はスマートポインターとして宣言され、コンストラクタで初期化されます。 class Foobar { Widget widget; public: Foobar() : widget(blah blah blah) {} // or std::unique_ptr<Widget> widget; public: Foobar() : widget(std::make_unique<Widget>(blah blah blah)) {} (…) }; そして、私たちはすべて準備ができて完了です。残念ながら、今日は、Javaの子供たちはカップルとして、当然、彼らはそれを見たら、私たちを笑う、となりますFoobarとWidget一緒に。解決策は一見シンプルです。依存関係の注入を適用して、Foobarクラスから依存関係を構築します。しかし、その後、C ++は依存関係の所有権について考えるように強制します。3つのソリューションが思い浮かびます。 ユニークなポインター class Foobar { std::unique_ptr<Widget> widget; public: Foobar(std::unique_ptr<Widget> &&w) : widget(w) {} (…) } Foobarそれの唯一の所有権がWidgetそれに渡されると主張する これには次の利点があります。 パフォーマンスへの影響はごくわずかです。 FoobarコントロールのライフタイムがWidgetであるため、安全です。そのため、Widget突然消えることはありません。 Widget漏れることはなく、不要になったときに適切に破壊されます。 ただし、これにはコストがかかります。 Widgetインスタンスの使用方法に制限があります。たとえば、スタックに割り当てられたものWidgetsは使用Widgetできず、共有できません。 …

3
大きなリストを破棄すると、スタックがオーバーフローしますか?
次の単一リンクリストの実装を検討してください。 struct node { std::unique_ptr<node> next; ComplicatedDestructorClass data; } 次に、std::unique_ptr<node> headスコープ外になり、デストラクタが呼び出されるインスタンスの使用を停止するとします。 これは十分に大きなリストのスタックを爆破しますか?それは公正なコンパイラが(インラインかなり複雑な最適化を行いますと仮定することであるunique_ptr「内のデストラクタをnode私がしなければ以来、以下の(はるかに困難になっている、そして、s」は末尾再帰を使用)dataデストラクタがわかりにくくなりnext、のハードそれを作りますコンパイラーが再配列の可能性と末尾呼び出しの機会に気付くように) struct node { std::shared_ptr<node> next; ComplicatedDestructorClass data; } dataどういうわけかnodeそれへのポインタがある場合、それはテール再帰が不可能であることさえあるかもしれません(もちろん、私たちはそのようなカプセル化の違反を回避するよう努めるべきです)。 一般的に、そうでない場合、このリストを破棄するにはどうすればよいですか?共有ポインタにはrelease!がないため、リストを走査して「現在の」ノードを削除することはできません。唯一の方法は、カスタムの削除ツールを使用することです。

1
最新のC ++へのキー/バリューストア開発の移植
Cassandraに似たデータベースサーバーを開発しています。 開発はCで始まりましたが、クラスがなければ非常に複雑になりました。 現在、私はすべてをC ++ 11に移植しましたが、まだ「モダンな」C ++を学習しており、多くのことについて疑問があります。 データベースはキー/値のペアで動作します。すべてのペアにはさらに多くの情報があります。いつが作成され、いつ期限切れになるか(期限切れでない場合は0)。各ペアは不変です。 キーはC文字列、値はvoid *ですが、少なくとも今のところ、値をC文字列として操作しています。 抽象IListクラスがあります。3つのクラスから継承 VectorList -C動的配列-std :: vectorに似ていますが、 realloc LinkList -チェックとパフォーマンス比較のために作成 SkipList -最終的に使用されるクラス。 将来はRed Black木も作ろうと思います。 それぞれIListに、キーでソートされた、0個以上のペアへのポインターが含まれています。 IList長くなりすぎた場合は、特殊ファイルとしてディスクに保存できます。この特殊ファイルは一種ですread only list。 キーを検索する必要がある場合は、 最初にメモリ内IListが検索されます(SkipList、SkipListまたはLinkList)。 次に、日付でソートされたファイルに検索が送信されます (最新のファイルが最初、最も古いファイル-最後)。 これらのファイルはすべてメモリにmmapされます。 何も見つからない場合、キーは見つかりません。 私はIList物事の実装に疑いはありません。 現在私を困惑させているのは以下の通りです: ペアは異なるサイズであり、それらはによって割り当てられnew()、それらをstd::shared_ptr指し示しています。 class Pair{ public: // several methods... private: struct Blob; std::shared_ptr<const Blob> _blob; }; struct Pair::Blob{ uint64_t …

4
非決定論的なリソース管理は漏れやすい抽象化ですか?
私が見ることができることから、リソース管理には、決定論的破壊と明示的破壊という2つの一般的な形式があります。前者の例は、C ++デストラクタとスマートポインタまたはPerlのDESTROYサブです。後者の例は、Rubyのブロックから管理リソースへのパラダイムまたは.NETのIDisposeインターフェイスです。 新しい言語は後者を選択しているようです。おそらく、参照カウント以外の種類のガベージコレクションシステムを使用することの副作用としてです。 私の質問はこれです:スマートポインターまたは参照カウントガベージコレクションシステムのデストラクタ-ほとんど同じこと-が暗黙的かつ透過的なリソース破壊を可能にすることを考えると、それは明示に依存する非決定的タイプよりもリークの少ない抽象化です表記? 具体的な例を挙げましょう。単一のスーパークラスのC ++サブクラスが3つある場合、特定の破棄を必要としない実装がある可能性があります。多分それは別の方法でその魔法をします。特別な破棄を必要としないという事実は関係ありません。すべてのサブクラスが同じように使用されます。 別の例では、Rubyブロックを使用しています。2つのサブクラスはリソースを解放する必要があるため、スーパークラスはコンストラクターでブロックを使用するインターフェースを選択します。ただし、他の特定のサブクラスは特別な破棄を必要としないため、ブロックを必要としない場合もあります。 後者はリソース破壊の実装の詳細をリークしますが、前者はリークしませんか? 編集:たとえば、RubyとPerlの比較は、一方は確定的破壊を持ち、もう一方はそうではないため、より公平である可能性がありますが、両方ともガベージコレクションされます。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.