std :: shared_ptr <Type>和Type^

Question

之间的区别我不明白shared_ptr和C++/CX中新句柄符号（^）之间的区别。从我读过的内容看，他们似乎在引用计数和内存管理方面做了同样的事情。我错过了什么？

std::shared_ptr<Type> 
//vs 
Type^ 

Answer 1

单独考虑终身管理，这些都是一样的：一个shared_ptr<T>拥有对T对象的强大（拥有）引用;一个T^也是这样。 make_shared<T>大致相当于C++/CX中的ref new T。

如果你到处看到T^你认为shared_ptr<T>或ComPtr<T>或CComPtr<T>，那也没关系 - 生命周期管理是大致相同的。

如何寿命管理工作引擎盖下是不同的，虽然：每T类型为其T^是公形成是实现IUnknown接口一个Windows运行时引用类型，所以T对象在内部参考计数^（*）。 shared_ptr<T>支持任意类型并使用外部引用计数（即，它分配自己的引用计数机制来控制对象的生存期）。

对于弱引用，shared_ptr<T>有weak_ptr<T>，并T^有WeakReference。 WeakReference不是强类型的，但您可以轻松地在其周围编写强类型的引用包装。否则，弱引用就像您期望的那样工作。对弱引用的支持是可选的：并非所有引用类型都支持弱引用，但大多数都是。

^{（*）有一个例外：Platform::String^，它不是Windows运行时引用类型，但由于各种原因专门处理。不过，您可以将其视为与生命周期管理方面的任何其他T^相同。}

---

那么，为什么Windows运行时类型在C++/CX中戴帽子？为什么不使用shared_ptr<T>或ComPtr<T>这样的库解决方案？

这是因为您从来没有真正拥有指向具体运行时类型的指针（或帽子）：只能通过指向其类型实现的某个接口的指针与对象进行交互。 Windows Runtime也不支持接口或类继承：每个接口必须直接从IInspectable派生，并且通过使用COM聚合来模拟类继承。

总之，没有任何库解决方案会导致自然的C++代码与静态类型安全。函数调用，派生到基础转换和接口转换通常需要调用QueryInterface才能获得正确的接口指针。

您可以使用库解决方案（例如，参见WRL库或几乎任何COM代码）执行此操作，但不能支持C++语言功能，如隐式转换或dynamic_cast。如果没有这些帽子，你就会陷入仅仅处理接口指针而不得不自己致电QueryInterface。

---

（如果你有兴趣在背后的理由，为什么的C++/CX语言扩展，开发和C++/CLI语法如何最终被选取为重复利用，我就建议吉姆·斯普林菲尔德的职务这个博客从去年开始，"Inside the C++/CX Design"。另外值得注意的是episode 3 of GoingNative，其中Marian Luparu在讨论C++/CX。）

Answer 2

至于我可以告诉大家，因为后者缺乏对 弱引用和 定制释放函数的支持。

请注意，前者更普遍，接受任何类型（原则上），以及安全和清洁要求使用助手功能make_shared。后者在语言层面得到支持。这意味着这样的代码是C++/CX安全：

some_function(ref new foo(), ref new bar()); 

虽然在C++中，你需要这样做：

比

// bad: if foo is allocated but bar's allocation throws, you leak! 
some_function(new foo(), new bar()); 

// good: both never make it anywhere but into a shared_ptr, no leaks 
some_function(make_shared<foo>(), make_shared<bar>()); 

其它，当然，他们实现了相同的概念。如果你在C++/CX领域，使用后面的语法来简化和一致;如果您试图坚持使用标准C++，或者将现有的资源管理方案封装为引用计数方案，那么您就需要前者。