有人知道有计划让 ^ 成为 shared_ptr 的简写吗？
例如：
shared_ptr
相当吓人...而
const int ^ const ^ pp;
立即让人想起原始指针等价
const int * const * pp;
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
不;这将是一个坏主意。
C++ 的最大优点之一是有不同的方法来管理内存和其他资源，您可以在每种情况下选择最佳的方法。
shared_ptr只是一种方式；其他包括auto_ptr、unique_ptr（来自 C++0x）以及intrusive_ptr和scoped_ptr（来自 Boost）。许多其他库都有自己的智能指针类。让
shared_ptr成为“首选”智能指针并没有多大意义。^符号已被 C 和 C++ 派生的其他几种语言使用。 C++/CLI 将其用于托管句柄，而 Objective C 将其用于块。No; this would be A Bad Idea.
One of the greatest advantages of C++ is that there are different ways to manage memory and other resources and you get to choose the best way in each situation.
shared_ptris just one way; others includeauto_ptr,unique_ptr(from C++0x), andintrusive_ptrandscoped_ptr(from Boost).Many other libraries have their own smart pointer classes. It doesn't make a whole lot of sense to make
shared_ptrthe "preferred" smart pointer.The
^symbol is already used by several other languages derived from C and C++. C++/CLI uses it for managed handles and Objective C uses it for blocks.除了现有答案所指出的之外，这是一个坏主意的原因之一是
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可以完美地实现为一个库组件。将其提升为核心语言几乎没有什么好处。On top of what the existing answers have pointed out, one reason why this is a Bad Idea(tm) is that
shared_ptrisn't really something to be encouraged.It is one type of smart pointer among several, and it has some critical shortcomings (it is far slower than any other widely used smart pointer, and using it can lead to memory leaks if you're not careful), and it is grossly overused.
What should be encouraged is the use of RAII in general: whether that is done through the use of various smart pointer classes (including, but certainly not limited to,
shared_ptr), or through your own RAII wrappers around resources or by using the standard library containers is irrelevant. They key is to rely on RAII for resource management.But a syntax such as this would elevate
shared_ptrto some special status where it is more important thanstd::vector,std::unique_ptr,std::weak_ptrand all the other extremely useful examples of RAII in the standard library.That would be misleading, and is only going to exacerbate the ridiculous over-reliance many people already have on
shared_ptr.I generally consider
shared_ptra last resort only. When possible, I prefer any of the other smart pointer classes, and only if none of them will do the job, do I consider usingshared_ptr. Bjarne Stroustrup has said something similar about shared ownership in general. Ideally, your code should have stricter ownership semantics.shared_ptris just there to take the last few cases where shared ownership really is the best (or least bad) option.Another, more objective, reason, is that C++ draws a clean line between "core language" and "library". For something like
int ^to be valid,^must be given special treatment in the core language, the same way that*is.So
shared_ptrwould no longer be a library component, but a core language feature.The standard committee tries to avoid that as much as possible, using the rule of thumb that anything that can be implemented as a library should be implemented as a library. And if it can't be implemented as a library, perhaps, instead of adding it as a core language feature, it'd be better to add something more general to the language which would allow it to be implemented as a library.
But
shared_ptrcan be implemented perfectly well as a library component. There'd be very little to gain from elevating it to the core language.如果不出意外的话，可能不会这样做，因为 Microsoft 已经在 C++/CLI 中使用了
^。Probably won't be done, if nothing else because Microsoft already uses
^in C++/CLI.每个人都错过了真正的原因:)
漂亮的符号 T^ 建议像真正的指针一样进行操作，这表明转换将以相同的方式工作。事实并非如此。模板不支持转换。例如，考虑
如果将 ^ 视为 *，这将起作用。但是，默认情况下，对于模板：
将不起作用：模板的参数不协变。据我所知，在 C++ 中不可能修复这个问题。您可以处理该一种转换，但不要忘记其他转换：
仅作为示例。如果你想要一个真正的类型系统，它必须由我的数学家而不是编译器作者来设计。
Everyone missed the real reason :)
The nice notation T^ suggests action like a real pointer, which suggests conversions would work the same way. This is not the case. Templates can't support conversions. For example consider
If you take ^ as *, this will work. However by default for a template:
will not work: templates are not covariant in their arguments. It is not possible to fix this in C++ AFAIK. You can handle that one conversion, but don't forget the others:
just for example. If you want a real type system it has to be designed my mathematicians not compiler writers.
不太可能。 C++ 已经是一种极其复杂的语言，并且添加了一项可能存在歧义的功能（已使用 XOR 运算符）+ 事实上，Microsoft 的 CLI 版本的 C++ 使用此语法进行托管引用 ->这种情况发生的可能性几乎为零。
Very unlikely. C++ is already an intimidatingly complex languages and adding one more feature with potential ambiguities (XOR operator already used) + the fact that Microsoft's CLI version of C++ uses this syntax for managed references -> chances for it happening are close to zero.