问题标签 [make-shared]

我正在尝试遵循 Herb Sutter 的 C++ 指南，在这种情况下，我更喜欢unique_ptr原始指针和shared_ptr. 支持的论据之一std::unique_ptr是可兑换为shared_ptr是在某些时候需要

vector在我的情况下，我有一个unique_ptr我需要传递给一个需要一个vector的方法shared_ptr。我希望能够写出类似的东西：

这给我Xcode 7.1配置了基于工具链的以下错误C++11：

错误：字段类型“抽象”是一个抽象类。

当Abstract我使用make_shared. 这似乎使萨特先生的建议在很多情况下都行不通，所以我确定我一定做错了什么！我求助于写作：

有一个更好的方法吗？

我试图理解为什么 std::make_shared 是这样声明/实现的：

我很好奇的是：

• 为什么make_shared只接受右值引用？为什么引用常量（即 ）没有重载const _Args &？
• 打电话的意义_VSTD::forward何在？

好的解释或好的超链接都将受到高度赞赏。

自 C++11 以来，由于多种原因，开发人员倾向于将智能指针类用于动态生命周期对象。并且对于那些新的智能指针类，标准，甚至建议不要使用new他们建议使用make_shared或make_unique避免一些容易出错的运算符。

如果我们喜欢使用智能指针类，like shared_ptr，我们可以构造一个like，

我们还想将自定义删除器传递给智能指针类，

另一方面，如果我们喜欢使用make_shared来分配，例如。int, 而不是 usenew和shared_ptrconstructor ，就像上面的第一个表达式一样，我们可以使用

但是，如果我们还想将自定义删除器传递make_shared给 怎么办，是否有正确的方法来做到这一点？似乎编译器，至少 gcc，给出了一个错误，

如何调用具有模板化构造函数的类make_shared？make_unique这是一个例子：

make_shared<A<T>>()没有意义（也没有编译），因为那宁愿用于模板类，而不是模板构造函数。

既不make_shared<A><T>()也不make_shared<A>(<T>())编译——也不看起来像他们应该的那样。同上make_shared<A, T>()

有没有办法在调用中指定构造函数调用的模板make_shared？我认为答案将适用make_unique；如果不是，请指出。谢谢！

（为了阐明模板是如何工作的，我编辑了代码。）

为了给std::shared_ptr给定的类型创建一个T，有两种方法：std::allocate_shared和std::make_shared。
主要区别（或者至少，我对此问题感兴趣的那个）是前者通过给定分配器的副本进行所有内存分配。

从文档中，std::allocate_shared具有以下签名：

另一方面，std::make_shared被描绘为：

对于他们俩来说，都指出：

args... - 构造 T 实例的参数列表。

从现在开始，一切似乎都是正确的（额外的分配器、参数等）。
无论如何，据我所知，他们都应该将参数声明为通用引用，但事实并非如此（至少，从我在文档中看到的）。

换句话说，签名不std::allocate_shared应该是以下吗？

他们不同是正确的还是那个网站的错误？
如果这是第一种情况，我在推理中遗漏了什么？

我正在建立一个工厂类，我需要将 a 返回unique_ptr到 a BaseClass。返回的指针由一个DerivedClass对象组成，该对象使用以下方法转换为共享指针make_shared，然后转换为所需的BaseClass指针：

我收到此编译器错误std::move

我正在使用VS2012 ...

为什么它使用与声明的 ( std::unique_ptr<BaseClass>) 不同的东西？

不是dynamic_pointer_cast返回一个std::unique_ptr<BaseClass>ret 吗？

帮助您了解发生了什么。

事后看来，如果用 C++11 引入了给定的构造函数，它make_shared会shared_ptr接受一个原始指针吗？

是否有支持此构造函数的有力论据或用例？

它将避免有据可查的异常安全陷阱和使用.make_shared

我相信要求的另一个好处shared_ptr我相信要求构建 viamake_shared是它可以是引擎盖下的单个指针，从而降低其内存使用并使atomic_compare_exchange 之类的事情变得更简单（并且可能更有效）。（参见C++Now 的演示文稿）

我知道一个基本上是 intrusive_ptr（对象和控制块合并）的 shared_ptr 将缺少当前 std::shared_ptr 具有的功能。喜欢：

1. 将对象与控制块分开释放的能力（如果您长期使用weak_ptrs，这很好）

2. 与向您提供原始指针并负责释放它们的库的兼容性

3. 使用自定义删除器（或没有删除器，对于非拥有指针）保存任意资源的能力

4. 在保持父对象活动的同时指向子对象（例如，成员）的能力。

我的建议是，这些功能可能不够常用（或者在将其用作RAII包装器的情况下）可能不是最合适的，以保证额外的成本：

1. 指向控制块的单独指针
2. （可能）更复杂的 atomic_compare_exchange 逻辑，可能不值得。

在C++98世界中（引入了 shared_ptr），make_shared 不太实用且对用户不太友好（缺少完美的转发需要引用包装器，并且缺少可变参数模板使得实现笨拙）。

我对我对 make_shared 性能（boost 或 stl）的理解有点怀疑，所以我想要一些意见。

在使用 C++ 开发应用程序时，我必须进行一些性能测试，最后我比较了 make_shared 和 shared_ptr+new （请注意，这不是提高性能的目的，我不希望在这里获得时间，但我现在只是好奇）

我用

• Debian 杰西 x64
• liboost 1.55
• GCC 4.9.2

我读到 make_shared 效率更高，根据我能找到的解释（分配编号、开销），这对我来说似乎是合乎逻辑的（据我所知）。

但是做一个快速而愚蠢的测试，我不明白我得到了什么

MyUselessClass 是一个简单的类，具有 3 个类属性（sting、bool、int），并且只有构造函数和析构函数。

“结果”（我引用是因为它当然不是一个准确的测试）如下（我将它运行到一个循环中以获得多次迭代，平均给出相同的结果）：

如果我相信我的测试，make_shared 比调用 share_ptr 和新实例稍慢。如果我将任何差异视为纳秒精度，我会预料到，相反......

所以现在我想知道：

• 也许我的测试太愚蠢了，纳秒命令在那些操作中没有重要性？
• 也许我错过了对 make_shared 更好性能的解释？
• 也许我在测试中错过了一些（几个）点？

如果您对以下几点有一些答案，请不要犹豫:)

谢谢

据我了解make_shared<T>(...)，可能会提供一些内存分配优化（它可能会在与 T 类实例相同的内存块内分配引用计数器）。

enable_shared_from_this 是否提供相同的优化？所以：

是相同的：

如果不考虑 sizeof(T)。

有什么区别

需要详细解释。