Is unique_ptr to unique_ptr up-casting automatic?

Question

I know it is possible that a derived class unique_ptr can take place where base class unique_ptr is required for polymorphic types. For example, while returning from function

unique_ptr<Base> someFunction()
{
     return make_unique<Derived>(new Derived());
}

or passing to function as argument.

// Function taking unique pointer
void someOtherFunction(unique_ptr<Base>&& ptr)
// Code calling this function
someOtherFunction(std::move(ptrToDerived));

My question is: Is this upcasting always automatic? Or do we need to explicitly perform it using dynamic_cast?

It seems automatic conversion is working for you so far. Why do you think you might need anything else? If you suspect you might need something else, why not check the documentation? — n. m. could be an AI, Apr 04 '16 at 12:05
@HumamHelfawi Do you mean to say at run-time? Cause it compiles on VS2015 — Chadwick Robbert, Apr 04 '16 at 12:07
@HumamHelfawi I also tried it on g++ 4.9.2 and it's working. To be specific `someFunction` is a pure virtual function declared in base class and I'm using exactly this line in all its derived classes `return make_unique(*this)` — Chadwick Robbert, Apr 04 '16 at 12:27
@n.m. So as both the compilers are not cribbing and not giving any warnings should I assume that automatic conversion works perfectly fine? Actually I would appreciate someone giving me exact reason (may be a specific clause in standard) why it works. That's why I'm waiting — Chadwick Robbert, Apr 04 '16 at 12:54
Yes, it's designed to work just like with regular built-in pointers, and it does work just like with built-in pointers. Pointer-to-derived automatically converts to pointer-to-base. — n. m. could be an AI, Apr 04 '16 at 13:09
It works because ´..._ptr` has a templatized constructor that accepts a `..._ptr`, and it works precisely when `B*` is convertible to `A*`. — n. m. could be an AI, Apr 04 '16 at 13:12
@n.m. Thanks a lot. Would you mind writing it as an answer? So that I can mark it. — Chadwick Robbert, Apr 04 '16 at 13:17

score 8 · Accepted Answer · answered Apr 04 '16 at 14:02

The (draft) standard says:

// 20.8.1.2.1, constructors
...
template <class U, class E>
  unique_ptr(unique_ptr<U, E>&& u) noexcept;
template <class U>
  unique_ptr(auto_ptr<U>&& u) noexcept;

Those are constructors from any unique_ptr. The standard further restricts their usage by clauses like this:

24 Remarks: This constructor shall not participate in overload resolution unless U* is implicitly convertible to T* and D is the same type as default_delete<T>

The effect of this remark is that unique_ptr<T> is constructible from unique_ptr<U> precisely U* is convertible to T* (and all deleter requirements are met). In particular, when T is an unambiguous public base class of U.

Since the constructor is not explicit, it serves as an implicit converter from unique_ptr<U> to unique_ptr<T>.

can you provide a source for where you cite from? – theV0ID Jun 01 '21 at 09:52 — theV0ID, Jun 01 '21 at 09:52

Is unique_ptr to unique_ptr up-casting automatic?

1 Answers1

Linked