Aviso C26409
Evite chamar
new
edelete
, explicitamente, usestd::make_unique<T>
(r.11).
Mesmo que o código esteja limpo de chamadas para malloc
e free
, ainda sugerimos que você considere opções melhores do que o uso explícito de operadores new
e delete
.
Diretrizes Principais do C++:
R.11: evitar chamar explicitamente nova e excluir
A correção final é usar ponteiros inteligentes e funções de fábrica apropriadas, como std::make_unique
.
Comentários
- O verificador avisa sobre chamadas para qualquer tipo de operador
new
oudelete
: escalar, vetor, versões sobrecarregadas (global e específicas de classe) e versões de posicionamento. O caso de posicionamentonew
pode exigir alguns esclarecimentos nas Diretrizes Principais para correções sugeridas e pode ser omitido no futuro.
Nome da análise de código: NO_NEW_DELETE
Exemplos
Este exemplo mostra que C26409 é gerado por new
e delete
explícitos. Em vez disso, considere o uso de funções de fábrica de ponteiro inteligente, como std::make_unique
.
void f(int i)
{
int* arr = new int[i]{}; // C26409, warning is issued for all new calls
delete[] arr; // C26409, warning is issued for all delete calls
auto unique = std::make_unique<int[]>(i); // prefer using smart pointers over new and delete
}
Há um idioma C++ que dispara esse aviso: delete this
. O aviso é intencional, pois as Diretrizes Principais do C++ desencorajam esse padrão. Você pode suprimir o aviso usando o atributo gsl::suppress
, conforme mostrado neste exemplo:
class MyReferenceCountingObject final
{
public:
void AddRef();
void Release() noexcept
{
ref_count_--;
if (ref_count_ == 0)
{
[[gsl::suppress(i.11)]]
delete this;
}
}
private:
unsigned int ref_count_{1};
};
Comentários
https://aka.ms/ContentUserFeedback.
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulteEnviar e exibir comentários de