Pour autant que je sache, C ++ 14 a été introduit std::make_unique
car, en raison de la non-spécification de l'ordre d'évaluation des paramètres, ce n'était pas sûr:
f(std::unique_ptr<MyClass>(new MyClass(param)), g()); // Syntax A
(Explication: si l'évaluation alloue d'abord la mémoire pour le pointeur brut, puis appelle g()
et une exception est levée avant la std::unique_ptr
construction, alors la mémoire est perdue.)
L'appel std::make_unique
était un moyen de contraindre l'ordre des appels, assurant ainsi la sécurité:
f(std::make_unique<MyClass>(param), g()); // Syntax B
Depuis lors, C ++ 17 a clarifié l'ordre d'évaluation, rendant la syntaxe A sûre également, alors voici ma question: y a-t-il encore une raison d'utiliser le constructeur std::make_unique
over std::unique_ptr
en C ++ 17? Peux-tu donner quelques exemples?
À partir de maintenant, la seule raison que je peux imaginer est qu'il ne permet de taper MyClass
qu'une seule fois (en supposant que vous n'ayez pas besoin de vous fier au polymorphisme avec std::unique_ptr<Base>(new Derived(param))
). Cependant, cela semble être une raison assez faible, surtout quand std::make_unique
il ne permet pas de spécifier un suppresseur alors que std::unique_ptr
le constructeur de le fait.
Et pour être clair, je ne préconise pas la suppression std::make_unique
de la bibliothèque standard (le garder a du sens au moins pour la compatibilité descendante), mais je me demande plutôt s'il existe encore des situations dans lesquelles il est fortement préféré àstd::unique_ptr
std::unique_ptr
? Ce n'est pas un argument contremake_unique