问题标签 [destruction]

Consider the following function:

How can I set a equal to 1 and b equal to 2, assuming a and b are variables?

Please don't recommend a=1 and b=2, the point is to understand how to access what the function has returned.

我目前遇到的问题是必须释放一个经常被两个不同线程访问的对象（实例）。对我来说，两个线程中的哪一个正在破坏实例并不重要，但我更喜欢那个也创建它的线程，尽管我认为这根本不重要。

因此，在应该销毁对象的线程检测到它应该被删除，并且在调用析构函数时，另一个线程正在访问该对象的成员（函数）的情况下，可能会发生某种运行时错误.

我对这个主题做了一些研究，但我只能弄清楚人们说：“为什么要删除仍然需要存在的对象”。但在我的情况下，在一个线程正在执行的一段代码决定销毁它之后，它应该不再需要了。

我将不胜感激，例如对涵盖该主题的好书或文章的提示，但请随意写下您将如何解决此问题。

我有3节课

当我将类C用作类的任何子级的容器A并尝试删除C实例时。A，B没有调用析构函数是正常的吗？解决方案是什么？

我听说Qt中的对象会自动删除他们的孩子，我想知道在那些情况下会发生什么。

这在 Qt 中是否允许？Qt 在销毁孩子时会做什么？

顺便说一句，我考虑使用诸如 shared_ptr 之类的智能指针。但我认为Qt也会删除已经被智能指针破坏的对象。

我知道您想使用 new 为对象分配动态内存。但是我不放心，请告诉我在依赖Qt的对象树处理动态内存时，是否有任何情况（例如异常）会导致内存泄漏？

如果我使用对象而不是指针来动态分配对象，我必须考虑对象的销毁顺序，只要它们具有所有权，这很繁琐。我不知道在 Qt 中使用动态内存是否是一种好习惯。

您有什么建议或更好的解决方案吗？

考虑一个具有以下签名的函数：

将映射传递给函数的最佳方法是什么，例如：

或者

我目前想到的是 via ，vec例如：flattenapply

我坚信有更好的方法来做到这一点。你能考虑一个吗？

我们如何在 Visualworks Smalltalk 中初始化一个类变量并在使用后销毁它？我想了解 ClassVariables。不是 ClassInstanceVariables。

我正在实现单例模式，这是我的代码

创建变量后，我无法销毁它。即下次我运行我的代码时，我看到类变量保留了它以前的值。我怎样才能避免这种情况？

我试过这个： MyClass allInstances do: [:inst | 实例变为：无]。但是没有用。

我有三个类的类结构，其中两个是第三个的基类，如下所示：

当要销毁的实例时，基类和销毁C的顺序是什么？这有什么规则吗？AB

假设我想构建一个向量容器，与 std::vector 不同，它允许未初始化的存储。容器的用法，比如说vec <T>，大概是这样的：

• 用户明确指出向量应该分配 N 个未初始化的元素，如下所示：

  vec <T> a(N, no_init);

• 在数据已知的某个时刻，用户n使用参数显式初始化位置处的元素args...：

  a.init(n, args...);

• 或者，等效地，手动构造元素：

  new (&a[n]) T(args...);

• 其他操作可能会更大规模地初始化或复制（如std::uninitialized_copy），但这只是为了方便；基本的底层操作是相同的。

• 完成某些任务后，向量可能会留下一些已初始化的元素，而另一些则没有。该向量不包含任何额外信息，因此最终，在释放内存之前，它要么销毁所有元素，要么仅根据T.

我很确定这是可以做到的，只是我不确定后果。自然地，我们希望这个结构对所有类型都是安全的，T假设用户在构造它之前没有尝试使用未初始化的元素。这听起来像是一个强有力的假设，但仅访问向量范围内的元素并没有太大的不同，而且它很常见。

所以我的问题是：

1. 对于哪些类型，允许这种未初始化的操作是安全的vec <T> a(no_init)？我想is_pod会没问题，而且很可能is_trivial也是如此。我不想施加不必要的限制。

2. 应该始终执行销毁还是仅针对某些类型执行销毁？与上面相同的约束可以吗？怎么样is_trivially_destructible？这个想法是破坏尚未构造的元素，反之亦然（不破坏构造的元素）应该没有害处。

3. 除了给用户带来更多责任的明显风险之外，这种尝试是否存在重大缺陷？

重点是，当用户确实需要此类功能以提高性能时，较低级别的解决方案std::get_temporary_buffer（如手动分配（例如 with operator new()））在泄漏方面可能更具风险。我知道，std::vector::emplace_back()但这真的不是一回事。

enter code here我在我的代码的一个奇怪部分看到了段错误，并且在使用 valgrind 之后，问题似乎是在构造孩子的过程中调用了父母的析构函数。这很奇怪，所以启动了 gdb，实际上，我看到调用了子对象的构造函数，调用了父对象的构造函数，然后在子构造函数退出之前调用了父对象的析构函数。我做了一个新的构建，看到了同样的事情。

我认为这是不可能的，并且正在发生一些有趣的事情，但我不知道那可能是什么，也不知道如何使用 gdb 来确定它是什么。Valgrind 只是在稍后告诉我，当我尝试使用父对象时，我正在执行无效读取，因为相关内存在子对象的构造过程中被删除！

很难打破有问题的代码来给出一个工作示例，但我可以尝试提供任何其他有用的细节。使用 gcc 4.7.2。

* 编辑 * 这是继承链的草图：

*进一步编辑* 我还要提到没有显式调用，deletegdb回溯显示父析构函数正上方的调用是子构造函数，所以我不认为这是其他一些代码以某种方式清理它。

我一直在迁移我的代码以使用 std::unique_ptr。

当我必须决定一个具有树层次结构的类时，我决定让对象拥有它们的孩子，这样从树中删除一个对象就会删除它。但是我注意到，在成千上万个元素的复杂层次结构中，破坏它真的很慢。就像，难以置信的慢。

那么是否只是建议不要嵌套唯一指针的向量，我应该切换到 unique_ptr 的平面布局，并在树中保留常规指针吗？我在想，这可能是一个众所周知的事实，这是不可行的，但这让我感到困惑，因为我很难找到关于这个具体细节的文献。

更新：在犹豫是否要删除我的问题之后，我注意到我的问题与这个问题非常相似： 删除指针的 STL 向量条目的快速方法

此外，树结构的过程甚至更慢。unique_ptr毕竟这里似乎不负责任。

我写了一段代码来调查它

• 销毁 60 000 个元素，unique_ptr平面布局大约需要 5 秒

• 销毁 60 000 个元素，unique_ptr树布局大约需要 8 秒

如果没有 unique_ptr，时间只会稍微低一些。

所以我面临的实际问题是连续删除 60 000 个东西很慢。然后我想我的解决方案与链接问题中的解决方案相似：

• 我知道我要批量删除的元素的池内存，但据说它非常麻烦并且容易出现严重错误

• 让一个工作线程来做，它会保持缓慢但不会再阻碍主线程

我对如何正确执行两者在技术上不了解，但我想它会教育我。