les vérifications nulles ne sont pas requises pour const unique_ptr renvoyé par la méthode d'usine?

Un unique_ptr peut toujours être nullptr , cela signifie simplement que cet objet gère la ressource sous-jacente, pas qu'il y a une ressource acquise.

Vous devez donc toujours vérifier si l'objet existe ou non, comme vous l'avez fait auparavant.

Remarque: qu'est-ce qui interdit à quelqu'un d'appeler votre usine et de ne pas stocker le résultat dans un unique_ptr ? Tant que cela est autorisé, vous devrez vérifier.

Vous pouvez le faire même s'il ne s'agissait pas d'un const unique_ptr, à condition de ne jamais le réinitialiser à null.

Sur votre fonction d'usine,

        auto device = unique_ptr<T>{ new T{ id, status } };
        if (!device) throw DeviceCreationException("device couldn't be created");

la vérification dans la ligne deux devrait être supprimé car le simple new ne renvoie jamais null (enfin, à moins que vous ne fassiez quelque chose de vraiment horrible avec les valeurs par défaut de l'implémentation, je suppose).

Tout d'abord le test:

template<typename T>
static T create(int id, std::string status)
{
    auto device = T{ id, status };

    return device;
}

n'a pas beaucoup de sens, car au moment où cette clause if est atteinte, ce ne serait pas possible pour device code> être nullptr (du moins pas pour le code donné)

Du point de vue de l'utilisateur, on sait que la fonction renvoie un code unique_ptr > en raison de la signature, mais vous devez lire la documentation, si l'appel DeviceFactory::create garantit qu'il ne contient pas nullptr . Et même si la documentation le garantissait, cela pourrait être une bonne idée de le tester vous-même, car vous ne le savez pas, ce sera toujours le cas à l'avenir.

La question est donc de savoir si vous enregistrez-le toujours sous const unique_ptr alors pourquoi avez-vous besoin d'un pointeur au lieu d'écrire:

if (!device) throw DeviceCreationException("device couldn't be created");

Mais revenons à votre question. Si const auto sensorX = ... est initialisé avec un unique_ptr qui ne contient pas nullptr , alors il est garanti qu'il ne sera pas nullptr pour sa durée de vie.

Une fois que nous aurons notre objet créé en usine - sensorX - pouvons-nous l'utiliser dans le reste du code sans autres vérifications nulles?

Comme d'autres réponses l'ont indiqué, la réponse est "non". Mais ce que vous pouvez faire, c'est utiliser le modèle owner<> ( Implémentation MS ), décrit dans les directives:

• Celui que vous avez établi un pointeur (brut) vers l'objet créé en usine est non nul, enveloppez-le dans un owner ;
• Demandez aux méthodes de prise de possession de prendre owner plutôt que T * comme paramètres.

Cela garantira, statiquement , que vous vous êtes assuré d'être propriétaire avant de passer l'appel - vous n'avez donc pas besoin de vérifier

On dirait que vous avez écrit votre propre version de std :: make_unique avec une API moins flexible. Je recommanderais d'aligner l'API car cela facilitera les mises à niveau.

Cela dit, votre question concerne le contrôle nul. Comme indiqué à plusieurs reprises dans les commentaires, vous n'avez pas besoin de vérifier après avoir obtenu un pointeur, car std :: bad_alloc devrait être lancé. Cependant, supposons que vous ayez une autre vérification qui lève une telle exception personnalisée, que la question principale est: quelle est votre API, y compris les conditions préalables et postérieures.

Dans la base de code sur laquelle nous travaillons, std :: unique_ptr n'est pas autorisé à être nullptr à moins d'être documenté. Dans ce cas: pas besoin de contrôle nul. Vous pouvez le documenter comme étant nullptr, ou renvoyer un optionnel à la place, ce qui pourrait indiquer l'état non valide.

Mon habitude serait de m'affirmer sur le pointeur avant utilisation ou après création. Cependant, vous pouvez automatiser ce travail en utilisant les désinfectants de Clang / Gcc. Le GSL a également des vérifications disponibles pour cette utilisation de nullptr.

Ma suggestion: affirmer après avoir créé la variable (ou utiliser des désinfectants), qui devrait trouver le bogue lors des tests si les post-conditions devaient changer. Bien qu'avec vos collèges, vous devriez convenir que unique_ptr ne devrait pas être autorisé à contenir null à moins d'être documenté ce que nullptr représente.