Question

I don’t really understand the difference between a shared_ptr and the new handle notation (^) in C++/CX. From what I’ve read they seem to do the same thing regarding reference counting and memory management. What am I missing?

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

Answer 1

Solely considering lifetime management, these are the same: a shared_ptr<T> holds a strong (owning) reference to a T object; a T^ does the same. make_shared<T> is roughly equivalent to ref new T in C++/CX.

If everywhere you see a T^ you think shared_ptr<T> or ComPtr<T> or CComPtr<T>, then that’s okay–the lifetime management is roughly the same.

How lifetime management works under the hood is different, though: every T type for which T^ is well-formed is a Windows Runtime reference type that implements the IUnknown interface, so the T object is internally reference counted^(*). shared_ptr<T> supports arbitrary types and uses external reference counting (i.e., it allocates its own reference counting mechanism to control the lifetime of the object).

For weak references, shared_ptr<T> has weak_ptr<T>, and T^ has WeakReference. WeakReference is not strongly-typed, but you can easily write a strongly-typed reference wrapper around it. Otherwise, weak references work as you would expect them to. Support for weak references is optional: not all reference types support weak references, but most do.

^{(*) There is one exception: Platform::String^, which is not a Windows Runtime reference type, but is handled specially for a variety of reasons. You can think of it as being the same as any other T^ with respect to lifetime management, though.}

---

So, why do Windows Runtime types wear hats in C++/CX? Why isn’t a library solution like shared_ptr<T> or ComPtr<T> used?

It’s because you never really have a pointer (or a hat) to a concrete runtime type: you can only interact with an object via a pointer to one of the interfaces that its type implements. Windows Runtime also does not support interface or class inheritance: every interface must derive directly from IInspectable, and class inheritance is emulated through the use of COM aggregation.

In short, there’s no library solution that would result in natural looking C++ code with static type safety. Function calls, derived-to-base conversions, and interface conversions usually require a call to QueryInterface to get the right interface pointer.

You can do this with a library solution (see, for example, the WRL library, or pretty much any COM code), but you can’t support C++ language features like implicit conversions or dynamic_cast. Without the hats, you’re stuck dealing solely with interface pointers and having to call QueryInterface yourself.

---

(If you’re interested in the rationale behind why the C++/CX language extension were developed and how the C++/CLI syntax ended up being selected for reuse, I’d recommend Jim Springfield’s post on this blog from last year, “Inside the C++/CX Design”. Also of note is episode 3 of GoingNative, in which Marian Luparu discusses C++/CX.)