Dynamique de casting pour unique_ptr

En plus de Marquer la Rançon du réponse, un unique_ptr<X, D> pourrait même ne pas stocker une X*.

Si la deleter définit le type D::pointer alors que c'est ce qui est stocké, et qui pourrait ne pas être un vrai pointeur, il suffit de répondre à la NullablePointer exigences et (si unique_ptr<X,D>::get() est appelé) ont un operator* qui renvoie X&, mais il n'est pas nécessaire à l'appui de la conversion d'autres types.

unique_ptr est très flexible et ne pas forcément se comporter comme un construit-dans le type de pointeur.

Comme demandé, voici un exemple où la stockées type n'est pas un pointeur, et donc le casting n'est pas possible. C'est un peu tiré par les cheveux, mais encapsule une API de base de données (défini comme un style C API) en C++ RAII-API de style. Le OpaqueDbHandle type aux NullablePointer exigences, mais seulement les magasins un entier, qui est utilisé comme une clé pour la recherche de la réelle connexion DB, par l'intermédiaire de la mise en œuvre définies par la cartographie. Je ne suis pas en montrant un exemple d'une excellente conception, comme un exemple de l'utilisation de unique_ptr pour gérer un non-copiable, meubles de ressources qui n'est pas allouée dynamiquement pointeur, où le "deleter" ne les appelez pas un destructeur et de libérer de la mémoire lors de la unique_ptr est hors de portée.

#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);
}

Ce n'est pas une réponse à pourquoi, mais c'est une façon de le faire...

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

Il n'est pas entièrement propre, car pour un bref instant 2 unique_ptrs pense qu'ils possèdent le même objet. Et comme l'a commenté, vous aurez également à gérer le déplacement d'un personnalisé deleter si vous en utilisez un (mais c'est très rare).

Si vous allez seulement l'être à l'aide de la triste pointeur dans un petit périmètre, une alternative est tout simplement abattu le référence de l'objet géré par le unique_ptr:

auto derived = dynamic_cast<Derived&>(*pBase);
derived.foo();