Anyone know of any plans to make ^ a shorthand for shared_ptr<T>?

For example:

shared_ptr<const shared_ptr<const int> > pp;

is fairly intimidating... wh开发者_运维问答ereas

const int ^ const ^ pp;

is instantly reminiscent of the raw pointer equivalent

const int * const * pp;

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_ptr is just one way; others include auto_ptr, unique_ptr (from C++0x), and intrusive_ptr and scoped_ptr (from Boost).

Many other libraries have their own smart pointer classes. It doesn't make a whole lot of sense to make shared_ptr the "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.

On top of what the existing answers have pointed out, one reason why this is a Bad Idea(tm) is that shared_ptr isn'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_ptr to some special status where it is more important than std::vector, std::unique_ptr, std::weak_ptr and 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_ptr a 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 using shared_ptr. Bjarne Stroustrup has said something similar about shared ownership in general. Ideally, your code should have stricter ownership semantics. shared_ptr is 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_ptr would 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_ptr can be implemented perfectly well as a library component. There'd be very little to gain from elevating it to the core language.

Probably won't be done, if nothing else because Microsoft already uses ^ in C++/CLI.

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

T^ --> T const^

If you take ^ as *, this will work. However by default for a template:

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

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:

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

just for example. If you want a real type system it has to be designed my mathematicians not compiler writers.

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.