`std::make_shared` est-il plus efficace que de construire directement `std::shared_ptr` ?

Efficacité de std::make_shared

Lors de la conception d'un pointeur partagé à partir d'un pointeur brut à l'aide de la fonction std::make_shared, il y a une différence en efficacité par rapport à la création directe d'un std::shared_ptr à l'aide d'un constructeur. Voici une explication étape par étape :

std::make_shared:

1. Allouez de la mémoire pour le bloc de contrôle (qui gère le comptage de références et d'autres métadonnées ) et l'objet.
2. Construisez l'objet std::shared_ptr avec l'objet alloué mémoire.

Direct std::shared_ptr Constructeur:

1. Allouer de la mémoire pour l'objet à l'aide de new.
2. Allouer de la mémoire pour le bloc de contrôle.
3. Construisez l'objet std::shared_ptr avec l'objet alloué mémoire.

Comme vous pouvez le voir, std::make_shared effectue une seule allocation (pour le bloc de contrôle et l'objet), tandis que la méthode constructeur direct effectue deux allocations (une pour l'objet, une autre pour le bloc de commande). Cette différence dans les allocations conduit à une plus grande efficacité lors de l'utilisation de std::make_shared.

Exception-Safety

Avant C 17, l'utilisation de std::make_shared était également plus d'exception- sûr. Considérez le code suivant :

void f(const std::shared_ptr<Object1>& obj1, const std::shared_ptr<Object2>& obj2) {
  // ...
}

int main() {
  f(std::shared_ptr<Object1>(new Object1()), std::shared_ptr<Object2>(new Object2()));
  return 0;
}

Sans std::make_shared, l'ordre d'évaluation des arguments n'est pas spécifié, et si l'allocation d'Object1 échoue, la mémoire d'Object2 serait divulguée. Avec std::make_shared, ce problème de sécurité des exceptions est résolu.

Inconvénient de std::make_shared

Un inconvénient potentiel de std::make_shared est qu'il peut empêcher une désallocation précoce de la mémoire de l'objet. Contrairement à la méthode du constructeur direct, std::make_shared crée un seul bloc mémoire pour le bloc de contrôle et l'objet. Cela signifie que la mémoire de l'objet et du bloc de contrôle ne peut pas être libérée indépendamment. S'il existe des pointeurs faibles pointant vers l'objet, ils peuvent maintenir le bloc de contrôle en vie même après que l'objet lui-même n'est plus utilisé, conduisant potentiellement à une rétention de mémoire.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!