Dynamic casting for unique_ptr

Question

As it was the case in Boost, C++11 provides some functions for casting shared_ptr:

std::static_pointer_cast
std::dynamic_pointer_cast
std::const_pointer_cast

I am wondering, however, why there are no equivalents functions for unique_ptr.

Consider the following simple example:

class A { virtual ~A(); ... }
class B : public A { ... }

unique_ptr<A> pA(new B(...));

unique_ptr<A> qA = std::move(pA); // This is legal since there is no casting
unique_ptr<B> pB = std::move(pA); // This is not legal

// I would like to do something like:
// (Of course, it is not valid, but that would be the idea)
unique_ptr<B> pB = std::move(std::dynamic_pointer_cast<B>(pA));

Is there any reason why this usage pattern is discouraged, and thus, equivalent functions to the ones present in shared_ptr are not provided for unique_ptr?

Solution 1

The functions you refer to each make a copy of the pointer. Since you can't make a copy of a unique_ptr it doesn't make sense to provide those functions for it.

Solution 2

In addition to Mark Ransom's answer, a unique_ptr<X, D> might not even store an X*.

If the deleter defines the type D::pointer then that's what is stored, and that might not be a real pointer, it only needs to meet the NullablePointer requirements and (if unique_ptr<X,D>::get() is called) have an operator* that returns X&, but it isn't required to support casting to other types.

unique_ptr is quite flexible and doesn't necessarily behave very much like a built-in pointer type.

As requested, here is an example where the stored type is not a pointer, and therefore casting is not possible. It's a bit contrived, but wraps a made-up database API (defined as a C-style API) in a C++ RAII-style API. The OpaqueDbHandle type meets the NullablePointer requirements, but only stores an integer, which is used as a key to lookup the actual DB connection via some implementation-defined mapping. I'm not showing this as an example of great design, just as an example of using unique_ptr to manage a non-copyable, movable resource which is not a dynamically-allocated pointer, where the "deleter" doesn't just call a destructor and deallocate memory when the unique_ptr goes out of scope.

#include <memory>

// native database API
extern "C"
{
  struct Db;
  int db_query(Db*, const char*);
  Db* db_connect();
  void db_disconnect(Db*);
}

// wrapper API
class OpaqueDbHandle
{
public:
  explicit OpaqueDbHandle(int id) : id(id) { }

  OpaqueDbHandle(std::nullptr_t) { }
  OpaqueDbHandle() = default;
  OpaqueDbHandle(const OpaqueDbHandle&) = default;

  OpaqueDbHandle& operator=(const OpaqueDbHandle&) = default;
  OpaqueDbHandle& operator=(std::nullptr_t) { id = -1; return *this; }

  Db& operator*() const;

  explicit operator bool() const { return id > 0; }

  friend bool operator==(const OpaqueDbHandle& l, const OpaqueDbHandle& r)
  { return l.id == r.id; }

private:
  friend class DbDeleter;
  int id = -1;
};

inline bool operator!=(const OpaqueDbHandle& l, const OpaqueDbHandle& r)
{ return !(l == r); }

struct DbDeleter
{
  typedef OpaqueDbHandle pointer;

  void operator()(pointer p) const;
};

typedef std::unique_ptr<Db, DbDeleter> safe_db_handle;

safe_db_handle safe_connect();

int main()
{
  auto db_handle = safe_connect();
  (void) db_query(&*db_handle, "SHOW TABLES");
}


// defined in some shared library

namespace {
  std::map<int, Db*> connections;      // all active DB connections
  std::list<int> unused_connections;   // currently unused ones
  int next_id = 0;
  const unsigned cache_unused_threshold = 10;
}

Db& OpaqueDbHandle::operator*() const
{
   return connections[id];
}

safe_db_handle safe_connect()
{
  int id;
  if (!unused_connections.empty())
  {
    id = unused_connections.back();
    unused_connections.pop_back();
  }
  else
  {
    id = next_id++;
    connections[id] = db_connect();
  }
  return safe_db_handle( OpaqueDbHandle(id) );
}

void DbDeleter::operator()(DbDeleter::pointer p) const
{
  if (unused_connections.size() >= cache_unused_threshold)
  {
    db_disconnect(&*p);
    connections.erase(p.id);
  }
  else
    unused_connections.push_back(p.id);
}

Solution 3

To build on Dave's answer, this template function will attempt to move the contents of one unique_ptr to another of a different type.

• If it returns true, then either:
  • The source pointer was empty. The destination pointer will be cleared to comply with the semantic request of "move the contents of this pointer (nothing) into that one."
  • The object pointed to by the source pointer was convertible to the destination pointer type. The source pointer will be empty, and the destination pointer will point to the same object it used to point to. The destination pointer will receive the source pointer's deleter (only when using the first overload).
• If it returns false, the operation was unsuccessful. Neither pointer will have changed state.

 

template <typename T_SRC, typename T_DEST, typename T_DELETER>
bool dynamic_pointer_move(std::unique_ptr<T_DEST, T_DELETER> & dest,
                          std::unique_ptr<T_SRC, T_DELETER> & src) {
    if (!src) {
        dest.reset();
        return true;
    }

    T_DEST * dest_ptr = dynamic_cast<T_DEST *>(src.get());
    if (!dest_ptr)
        return false;

    std::unique_ptr<T_DEST, T_DELETER> dest_temp(
        dest_ptr,
        std::move(src.get_deleter()));

    src.release();
    dest.swap(dest_temp);
    return true;
}

template <typename T_SRC, typename T_DEST>
bool dynamic_pointer_move(std::unique_ptr<T_DEST> & dest,
                          std::unique_ptr<T_SRC> & src) {
    if (!src) {
        dest.reset();
        return true;
    }

    T_DEST * dest_ptr = dynamic_cast<T_DEST *>(src.get());
    if (!dest_ptr)
        return false;

    src.release();
    dest.reset(dest_ptr);
    return true;
}

Note that the second overload is required for pointers declared std::unique_ptr<A> and std::unique_ptr<B>. The first function will not work because the first pointer will actually be of type std::unique_ptr<A, default_delete<A> > and the second of std::unique_ptr<A, default_delete<B> >; the deleter types won't be compatible and so the compiler will not allow you to use this function.

Solution 4

This isn't an answer to why, but it is a way to do it...

std::unique_ptr<A> x(new B);
std::unique_ptr<B> y(dynamic_cast<B*>(x.get()));
if(y)
    x.release();

It's not entirely clean since for a brief moment 2 unique_ptrs think they own the same object. And as was commented, you'll also have to manage moving a custom deleter if you use one (but that's very rare).

Solution 5

How about this for a C++11 approach:

template <class T_SRC, class T_DEST>
inline std::unique_ptr<T_DEST> unique_cast(std::unique_ptr<T_SRC> &&src)
{
    if (!src) return std::unique_ptr<T_DEST>();

    // Throws a std::bad_cast() if this doesn't work out
    T_DEST *dest_ptr = &dynamic_cast<T_DEST &>(*src.get());

    src.release();
    return std::unique_ptr<T_DEST>(dest_ptr);
}

View more solutions

Comments

[Jonathan Wakely]

It's more complicated if you have a unique_ptr<A, Deleter> as you need to move the deleter.

[betabandido]

So, given there is a possible implementation, can you think of any reason why dynamically casting a unique_ptr would be bad praxis? I agree that using move on unique_ptr may not be an example of good coding, but in some circumstances it may actually prove useful to do so.

[betabandido]

That is true, but what if the only intention is to move the pointer? In that case, the casting functions for unique_ptr would not make a copy, just move (or transform) the pointer.

[cdhowie]

I can't say that I find it to be any worse than dynamically casting any other pointer. There's just the special "what happens if the cast fails" problem that you have to address (as I do in these functions) when you are dealing with exclusive-ownership pointers.

[betabandido]

Thank you for your answer. It really looks as if it is more complicated than what I initially thought. Could you give an example of how to build a unique_ptr that does not store a pointer, please?

[Puppy]

@betabandido: And what if the dynamic cast fails?

[betabandido]

+1 I never thought about using unique_ptr to implement a RAII approach for a database :) Thank you for the example.

[betabandido]

I finally decided to accept this answer, since even if it is possible, it seems there are a significant number of issues when trying to downcast a unique_ptr.

[Arne Vogel]

Though there is no problem with having two instances temporarily: std::unique_ptr<A> x(new B); const auto yp = dynamic_cast<B*>(x.get()); std::unique_ptr<B> y(yp != nullptr ? (x.release(), yp) : nullptr);

[user2746401]

May want to check out some similar code stackoverflow.com/a/26377517/2746401

[cdhowie]

@user2746401 Thanks for the link. I edited my answer to use std::move() when transferring the deleter as that answer does.

[Giel]

I like that it throws on cast failure (for some use cases). But I think it's bad that it still returns a NULL/empty pointer when the source is empty. It creates an API inconsistency where you still return NULL in some cases where casting is impossible, but not in others. So maybe: if (!src) throw std::bad_cast()?

[IceFire]

@betabandido there are only issues, when you dynamic_cast... static_casting should be fine, but there is no function

[jaba]

Thanks, really nice snippet. I've posted a refined version.

[Morty]

This leaks memory if the dynamic_cast fails. You must only call release after checking that the cast was successful. See stackoverflow.com/a/26377517/1012586

[jaba]

Thanks for pointing that out. But because there is a dynamic_cast to a reference the will be a std::bad_cast exception and release() will never be reached. The calling code must take care of the exception though. I've added a non throwing version though.

[Morty]

My bad! I missed the two ampersands in the cast.