Questions tagged «smart-pointer»

如今，垃圾收集了许多语言。第三方甚至可以使用C ++。但是C ++具有RAII和智能指针。那么使用垃圾回收有什么意义呢？它在做额外的事情吗？ 在其他语言（例如C＃）中，如果所有引用都被视为智能指针（不考虑RAII），那么按照规范和实现，是否还会需要垃圾收集器？如果否，那为什么不是呢？

67 garbage-collection  smart-pointer 

我只是在观看“ Going Native 2012”流，并且注意到有关的讨论std::shared_ptr。听到Bjarne std::shared_ptr对此持否定态度，以及他的评论是当物体的寿命不确定时应将其用作“最后手段”时，我感到有些惊讶（我认为，他认为这种情况很少见）。 有人愿意进一步解释这一点吗？我们如何std::shared_ptr在没有安全的情况下进行编程并仍然可以安全地管理对象的生命周期？

59 c++  c++11  smart-pointer 

C ++中有很多指针，但是老实说，在5年左右的C ++编程中（特别是Qt Framework），我仅使用旧的原始指针： 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 …

33 c++  programming-practices  pointers  qt  smart-pointer 

问题：Java / C＃为什么不能实现RAII？ 澄清：我知道垃圾收集器不是确定性的。因此，使用当前的语言功能，不可能在范围出口处自动调用对象的Dispose（）方法。但是，可以添加这种确定性功能吗？ 我的理解： 我认为RAI​​I的实现必须满足两个要求： 1.资源的生存期必须绑定到范围。 2.隐式的。必须在没有程序员明确声明的情况下释放资源。类似于垃圾回收器无需显式语句即可释放内存。“隐含性”仅需要在使用该类时发生。当然，类库创建者必须显式实现析构函数或Dispose（）方法。 Java / C＃满足点1。在C＃中，可以将实现IDisposable的资源绑定到“使用”范围： 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 …

29 java  c#  resources  smart-pointer  raii 

说我有一个Foobar使用（取决于）class的类Widget。好的时候，将Widgetwolud声明为中的字段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 ++迫使我们考虑依赖关系的所有权。想到三个解决方案： 唯一指针 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不能共享。 共享指针 class …

16 c++  dependency-injection  smart-pointer 

考虑以下单链表实现： struct node { std::unique_ptr<node> next; ComplicatedDestructorClass data; } 现在，假设我停止使用某个std::unique_ptr<node> head超出范围的实例，从而导致其析构函数被调用。 这会否使我的堆栈大到无法容纳足够大的列表？假设编译器会做一个相当复杂的优化（将inline unique_ptr的析构函数插入node，然后使用尾部递归）是否公平，如果我执行以下操作，这会变得更加困难（因为data析构函数会混淆next's'，使其变得困难）让编译器注意到潜在的重新排序和尾部调用机会）： struct node { std::shared_ptr<node> next; ComplicatedDestructorClass data; } 如果data某种程度上有指向它的指针，node那么尾部递归甚至是不可能的（尽管我们当然应该努力避免这种封装破坏）。 通常，那么应该如何销毁该列表呢？我们无法遍历列表并删除“当前”节点，因为共享指针没有release！唯一的方法是使用自定义删除器，这对我来说真的很臭。

12 c++11  smart-pointer 

我正在开发类似于Cassandra的数据库服务器。 开发从C语言开始，但是没有类，事情变得非常复杂。 目前，我在C ++ 11中移植了所有内容，但我仍在学习“现代” C ++，并对很多事情有疑问。 数据库将使用键/值对。每对都有更多信息-什么时候创建以及何时过期（如果不过期则为0）。每对都是不可变的。 关键是C字符串，值是空*，但至少目前我也使用C字符串作为值。 有抽象IList类。它从三个类继承 VectorList -C动态数组-类似于std :: vector，但使用 realloc LinkList -用于检查和性能比较 SkipList -最终将使用的类。 将来我可能Red Black也会做树。 每个都IList包含零个或多个指向对的指针，并按键排序。 如果IList太长，可以将其保存在磁盘上的特殊文件中。这个特殊文件是的read only list。 如果您需要搜索密钥， 首先在存储器IList中搜索（SkipList，SkipList或LinkList）。 然后将搜索发送到按日期排序的文件 （最新的文件在前，最早的文件在后）。 所有这些文件都在内存中映射。 如果未找到任何内容，则找不到密钥。 我对事情的执行毫无疑问IList。 目前令人困惑的是： 这些对的大小不同，它们由分配，new()并已std::shared_ptr指向它们。 class Pair{ public: // several methods... private: struct Blob; std::shared_ptr<const Blob> _blob; }; struct Pair::Blob{ uint64_t …

9 c++  c++11  pointers  smart-pointer 

据我所知，资源管理有两种普遍形式：确定性破坏和显式破坏。前者的示例是C ++析构函数和智能指针或Perl的DESTROY子例程，而后者的示例将是Ruby的块至管理资源范例或.NET的IDispose接口。 较新的语言似乎选择后者，这可能是使用非引用计数类型的垃圾收集系统的副作用。 我的问题是：鉴于智能指针或引用计数垃圾收集系统的析构函数（几乎是同一件事）允许隐式和透明的资源销毁，它比依赖于显式的非确定性类型的抽象性泄漏少吗？符号？ 我将举一个具体的例子。如果您有一个超类的三个C ++子类，则其中一个实现可能不需要任何特定的销毁。也许它以另一种方式发挥了魔力。它不需要任何特殊的销毁是无关紧要的-所有子类仍然以相同的方式使用。 另一个示例使用Ruby块。两个子类需要释放资源，因此，即使其他特定子类可能不需要它，因为它们不需要特殊的销毁，所以超类会选择在构造函数中使用块的接口。 后者是否泄漏了资源破坏的实施细节，而前者却没有？ 编辑：比方说，将Ruby与Perl进行比较可能更公平，因为其中一个具有确定性的销毁能力，而另一个则没有，但是它们都被垃圾回收了。

9 c++  ruby  perl  garbage-collection  smart-pointer