la création d'un shared_ptr de unique_ptr

Mise à JOUR 2: Ce bug a été corrigé dans Clang dans r191150. GCC rejette le code avec un message d'erreur approprié.

---

Mise à JOUR: j'ai présenté une rapport de bug. Le code suivant sur ma machine avec clang++ 3.4 (tronc 191037)

#include <iostream>
#include <memory>

int main()
{
   std::unique_ptr<int> u_ptr(new int(42));

   std::cout << " u_ptr.get() = " <<  u_ptr.get() << std::endl;
   std::cout << "*u_ptr       = " << *u_ptr       << std::endl;

   auto s_ptr = std::make_shared<int>(std::move(u_ptr));

   std::cout << "After move" << std::endl;

   std::cout << " u_ptr.get() = " <<  u_ptr.get() << std::endl;
   std::cout << "*u_ptr       = " << *u_ptr       << std::endl;
   std::cout << " s_ptr.get() = " <<  s_ptr.get() << std::endl;
   std::cout << "*s_ptr       = " << *s_ptr       << std::endl;
}

imprime ce:

 u_ptr.get() = 0x16fa010
*u_ptr       = 42
After move
 u_ptr.get() = 0x16fa010
*u_ptr       = 42
 s_ptr.get() = 0x16fa048
*s_ptr       = 1

Comme vous pouvez le voir, le unique_ptr n'a pas été déplacé de. La norme garanties qu'il devrait être à null après qu'il a été déplacé à partir. Le shared_ptr points pour une valeur incorrecte.

La chose étrange est qu'il compile sans avertissement et valgrind ne pas signaler tous les problèmes, pas de fuite, pas de corruption de segment. Bizarre.

Le bon comportement est montré si je créer s_ptr avec le shared_ptr ctor prendre une rvalue ref à un unique_ptr au lieu de make_shared:

#include <iostream>
#include <memory>

int main()
{
   std::unique_ptr<int> u_ptr(new int(42));

   std::cout << " u_ptr.get() = " <<  u_ptr.get() << std::endl;
   std::cout << "*u_ptr       = " << *u_ptr       << std::endl;

   std::shared_ptr<int> s_ptr{std::move(u_ptr)};

   std::cout << "After move" << std::endl;

   std::cout << " u_ptr.get() = " <<  u_ptr.get() << std::endl;
   //std::cout << "*u_ptr       = " << *u_ptr       << std::endl; //<-- would give a segfault
   std::cout << " s_ptr.get() = " <<  s_ptr.get() << std::endl;
   std::cout << "*s_ptr       = " << *s_ptr       << std::endl;
}

Il imprime:

 u_ptr.get() = 0x5a06040
*u_ptr       = 42
After move
 u_ptr.get() = 0
 s_ptr.get() = 0x5a06040
*s_ptr       = 42

Comme vous le voyez, u_ptr est nulle après le déménagement tel que requis par la norme et s_ptr points à la valeur correcte. C'est le comportement correct.

---

(L'original de la réponse.)

En tant que Simple a souligné: "À moins que Toto a un constructeur qui prend un std::unique_ptr, il ne devrait pas compiler."

Pour développer un peu: make_shared transmet ses arguments pour T de constructeur. Si T n'ont pas ctor qui pourrait accepter que unique_ptr<T>&& c'est une erreur de compilation.

Cependant, il est facile de corriger ce code et obtenir ce que vous voulez (démo en ligne):

#include <memory>
using namespace std;

class widget { };

int main() {

    unique_ptr<widget> uptr{new widget};

    shared_ptr<widget> sptr(std::move(uptr));
}

Le point est: make_shared est la mauvaise chose à utiliser dans cette situation. shared_ptr a un ctor qui accepte un unique_ptr<Y,Deleter>&&, voir (13) à l'ctors de shared_ptr.

Voici un exemple qui réduit clang compile de façon incorrecte:

struct ptr
{
  int* p;

  explicit operator bool() const { return p != nullptr; }
};

int main()
{
  ptr u{};
  int* p = new int(u);
}

Clang utilise l'explicite bool opérateur de conversion pour initialiser le int (et le compilateur Intel ne trop.)

Clang 3.4 ne permet pas:

int i = int(u);

mais il ne permet pas de:

int* p = new int(u);

Je pense que les deux doivent être rejetées. (Clang 3.3 et ICC permettent à la fois.)

J'ai ajouté cet exemple à la rapport de bug.