Question

例如：

shared_ptr<const shared_ptr<const int> > pp;

相当令人生畏......而

const int ^ const ^ pp;

立即让人联想到原始指针等效

const int * const * pp;

Answer 1

没有;这将是一个坏主意。

C ++最大的优势之一是管理内存和其他资源有不同的方法，您可以在每种情况下选择最佳方式。 shared_ptr只是一种方式;其他包括auto_ptr，unique_ptr（来自C ++ 0x），以及intrusive_ptr和scoped_ptr（来自Boost）。

许多其他库都有自己的智能指针类。将shared_ptr作为“首选”智能指针并不是很有意义。

^符号已被其他几种源自C和C ++的语言使用。 C ++ / CLI将其用于托管句柄，而Objective C将其用于块。

Answer 2

除了现有的答案所指出的，这是一个坏主意（tm）的一个原因是shared_ptr并不是真正值得鼓励的。

它是几种智能指针中的一种，它有一些关键的缺点（远比任何其他广泛使用的智能指针慢，如果你'使用它会导致内存泄漏'不小心），它被严重过度使用。

应该鼓励使用RAII 一般：是否通过使用各种智能指针类（包括但不限于shared_ptr）来完成，或通过您自己的RAII包装资源或使用标准库容器是无关紧要的。他们的关键是依靠RAII进行资源管理。

但是这样的语法会将shared_ptr提升到一些特殊状态，其中更多比std::vector，std::unique_ptr，std::weak_ptr重要以及标准库中RAII的所有其他非常有用的例子。

这会产生误导，只会加剧许多人对shared_ptr已经存在的荒谬过度依赖。

我通常认为shared_ptr只是最后的手段。如果可能的话，我更喜欢其他智能指针类的任何，并且只有当它们都不能完成工作时，我才考虑使用shared_ptr。 Bjarne Stroustrup总体上谈到了共享所有权的相似之处。理想情况下，您的代码应具有更严格的所有权语义。 shared_ptr就是在最后几个案例中，共享所有权确实是最好（或最不好）的选择。

另一个更客观的理由是，C ++在“核心语言”和“库”之间划清界限。要使int ^有效，^必须以核心语言进行特殊处理，与*的方式相同。

因此shared_ptr将不再是库组件，而是核心语言功能。

标准委员会试图尽可能地避免这种情况，使用经验法则可以实现为库的任何内容应该实现为库。如果不能实现为库，也许不是将其作为核心语言功能添加，而是最好添加一些更通用的语言，这样就可以了作为图书馆实施。

但是shared_ptr可以很好地实现为库组件。将它升级为核心语言几乎没有什么好处。

Answer 3

可能不会这样做，因为Microsoft已经在C ++ / CLI中使用了^。

Answer 4

每个人都错过了真正的原因：）

漂亮的符号T ^建议动作像真正的指针，这表明转换将以相同的方式工作。不是这种情况。模板无法支持转化。例如，考虑

T^ --> T const^

如果你把^作为*，这将有效。但是，默认情况下，模板：

p<T> --> p<T const>

不起作用：模板的参数不协变。在C ++ AFAIK中修复此问题不。您可以处理这一次转换，但不要忘记其他转换：

derived --> base
T ** --> T const * const*

仅举例。如果你想要一个真正的类型系统，我必须设计我的数学家而不是编译器编写者。

Answer 5

非常不可能。 C ++已经是一种令人生畏的复杂语言，并且添加了一个具有潜在歧义的特性（已经使用了XOR运算符）+ Microsoft的CLI版本的C ++使用这种语法进行托管引用 - ＆gt;它发生的可能性接近于零。

任何人都知道有任何计划让^是shared_ptr <t>的简写吗？</t>

5 个答案: