Por que usar std :: make_unique em C ++ 17?

Pelo que entendi, C ++ 14 foi introduzido std::make_uniqueporque, como resultado da ordem de avaliação dos parâmetros não ser especificada, isso não era seguro:

f(std::unique_ptr<MyClass>(new MyClass(param)), g()); // Syntax A

(Explicação: se a avaliação primeiro alocar a memória para o ponteiro bruto, em seguida, chamar g()e uma exceção for lançada antes da std::unique_ptrconstrução, a memória será perdida.)

Chamar std::make_uniqueera uma forma de restringir a ordem da chamada, tornando as coisas seguras:

f(std::make_unique<MyClass>(param), g());             // Syntax B

Desde então, C ++ 17 esclareceu a ordem de avaliação, tornando Sintaxe Um cofre também, então aqui está a minha pergunta: existe ainda uma razão para usar std::make_uniqueao longo std::unique_ptrdo construtor em C ++ 17? Voce pode dar alguns exemplos?

A partir de agora, a única razão que posso imaginar é que ele permite digitar MyClassapenas uma vez (supondo que você não precise confiar no polimorfismo com std::unique_ptr<Base>(new Derived(param))). No entanto, esse parece um motivo muito fraco, especialmente quando std::make_uniquenão permite especificar um deleter enquanto std::unique_ptro construtor de faz.

E só para ficar claro, não estou defendendo a remoção std::make_uniqueda Biblioteca Padrão (mantê-la faz sentido, pelo menos para compatibilidade com versões anteriores), mas sim me perguntando se ainda há situações em que é fortemente preferidostd::unique_ptr

Você está certo de que o principal motivo foi removido. Há ainda os motivos de não usar novas diretrizes e que são menos digitadores (não precisa repetir o tipo ou usar a palavra new). Admito que esses não são argumentos fortes, mas eu realmente gosto de não ver newno meu código.

Também não se esqueça da consistência. Você absolutamente deveria estar usando, make_sharedentão o uso make_uniqueé natural e se encaixa no padrão. Então, é trivial mudar std::make_unique<MyClass>(param)para std::make_shared<MyClass>(param)(ou o contrário) onde a sintaxe A requer muito mais reescrita.

make_uniquedistingue Tde T[]e T[N], unique_ptr(new ...)não.

Você pode obter facilmente um comportamento indefinido passando um ponteiro que foi new[]ed para a unique_ptr<T>, ou passando um ponteiro que foi newed para a unique_ptr<T[]>.

O motivo é ter um código mais curto sem duplicatas. Comparar

f(std::unique_ptr<MyClass>(new MyClass(param)), g());
f(std::make_unique<MyClass>(param), g());

Você salva MyClass, newe chaves. Custa apenas um caráter mais na composição , em comparação com o PTR .

Cada uso de newtem que ser cuidadosamente auditado para verificar a exatidão ao longo da vida; ele é excluído? Apenas uma vez?

Cada uso de make_uniquenão faz essas características extras; contanto que o objeto proprietário tenha vida útil "correta", ele recursivamente faz com que o ponteiro exclusivo tenha "correto".

Agora, é verdade que unique_ptr<Foo>(new Foo())é idêntico em todas as maneiras ¹ a make_unique<Foo>(); requer apenas um simples "grep seu código-fonte para todos os usos de newpara auditá-los".

¹ , na verdade, um, em geral o caso. O encaminhamento perfeito não é perfeito, {}init padrão, arrays são exceções.

Desde então, C ++ 17 esclareceu a ordem de avaliação, tornando a Sintaxe A segura também

Isso realmente não é bom o suficiente. Contar com uma cláusula técnica recentemente introduzida como garantia de segurança não é uma prática muito robusta:

• Alguém pode compilar este código em C ++ 14.
• Você estaria encorajando o uso de raw new's em outro lugar, por exemplo, copiando e colando seu exemplo.
• Como o SM sugere, uma vez que há duplicação de código, um tipo pode ser alterado sem que o outro seja alterado.
• Algum tipo de refatoração automática de IDE pode mover isso para newoutro lugar (ok, certo, não há muita chance disso).

Geralmente, é uma boa ideia que seu código seja apropriado / robusto / claramente válido sem recorrer a camadas de linguagem, procurando por cláusulas técnicas menores ou obscuras no padrão.

(este é essencialmente o mesmo argumento que apresentei aqui sobre a ordem de destruição da tupla.)

Considere a função void (std :: unique_ptr (new A ()), std :: unique_ptr (new B ())) {...}

Suponha que new A () seja bem-sucedido, mas new B () lance uma exceção: você o captura para retomar a execução normal do seu programa. Infelizmente, o padrão C ++ não exige que o objeto A seja destruído e sua memória desalocada: a memória vaza silenciosamente e não há como limpá-la. Ao envolver A e B em std :: make_uniques, você tem certeza de que o vazamento não ocorrerá:

void function (std :: make_unique (), std :: make_unique ()) {...} O ponto aqui é que std :: make_unique e std :: make_unique são agora objetos temporários, e a limpeza de objetos temporários é especificada corretamente em o padrão C ++: seus destruidores serão acionados e a memória liberada. Então, se você puder, sempre prefira alocar objetos usando std :: make_unique e std :: make_shared.