Pergunta

Eu sei que, de acordo com o padrão C ++ no caso da nova falha ao alocar memória que é suposto para jogar exceção std :: bad_alloc. Mas ouvi dizer que alguns compiladores, como VC6 (ou implementação CRT?) Não aderir a ela. Isso é verdade ? Estou perguntando isso porque a verificação de NULL após cada nova declaração torna o código olhar muito feio.

Foi útil?

Solução

VC6 não conforme, por padrão a este respeito. new de VC6 voltou 0 (ou NULL).

Aqui está KB artigo da Microsoft sobre esta questão, juntamente com sua solução sugerida usando um manipulador new personalizado:

Se você tem um código antigo que foi escrito para o comportamento VC6, você pode obter esse mesmo comportamento com compiladores mais recentes MSVC (algo como 7.0 e posterior), ligando em um arquivo objeto nothrownew.obj nomeado. Há realmente um conjunto bastante complicado de regras na 7.0 e 7.1 compiladores (VS2002 e VS2003) para determinar se eles padronizado para não-arremesso ou jogando new.

Parece que MS limpas isso em 8,0 (VS2005) -agora ele sempre o padrão é um jogando novo a menos que você ligar especificamente para nothrownew.obj.

Note que você pode especificar que deseja new para 0 retorno em vez de jogar std::bad_alloc usando o parâmetro std::nothrow:

SomeType *p = new(std::nothrow) SomeType;

Esta parece trabalho em VC6, assim que poderia ser uma maneira de mais ou menos mecanicamente corrigir o código para trabalhar o mesmo com todos os compiladores para que você não tem que refazer o tratamento de erros existente.

Outras dicas

Eu gostaria de adicionar a opinião (um tanto controverso) que a verificação de NULL após uma tentativa de alocação é praticamente um exercício de futilidade. Se o seu programa de sempre corre para essa situação, as chances são que você não pode fazer muito mais do que sair rápido. É muito provável que qualquer tentativa posterior atribuição também irá falhar.

Sem verificar para NULL, o seu código subseqüente iria tentar excluir a referência um ponteiro NULL, o que tende a sair do programa rápido, com uma condição de saída relativamente único (e facilmente debuggable).

Eu não estou tentando falar com você de verificação de NULL, é certamente programação consciente. Mas você não ganhar muito com isso, a não ser em casos muito específicos, onde talvez você possa armazenar algumas informações de recuperação (sem alocar mais memória), ou memória livre menos importante, etc. Mas esses casos será relativamente raro para a maioria das pessoas.

Diante disso, eu tinha acabado de confiar o compilador para jogar bad_alloc, pessoalmente -. Pelo menos na maioria dos casos

Com base na especificação C ++, ele irá sempre jogar std :: bad_alloc quando você usa simplesmente nova, sem parâmetros, mas é claro que não pode haver alguns compiladores não conformes.

Eu não iria código para ser compatível com compiladores não c ++ compatíveis embora. VC6 sendo um deles a este respeito.

É uma boa prática que para sempre definir o ponteiro para NULL depois de excluí-los. Então, por causa disso, a verificação de NULL ainda é necessária.

Dito isto, aqui estão algumas opções para limpar o seu código:

Opção 1: Definir o seu próprio novo manipulador

A maneira segura de limpar o seu código seria chamar: set_new_handler primeiro.

Em seguida, você pode verificar para NULL no seu manipulador e jogar std :: bad_alloc lá se NULL é retornado.

Se você gosta exceções melhor, então este é o seu melhor aposta. Se você gostaria de voltar melhor NULL, então você também pode fazer isso fazendo uma captura dentro do seu novo manipulador.

Opção 2: Uso sobrecarregado novo

O ficheiro de cabeçalho C ++ padrão define uma nothrow estrutura que está vazio. Você pode usar um objeto deste struct dentro de novo para obter a sua versão sobrecarregada que sempre retorna NULL.

void* operator new (size_t size, const std::nothrow_t &);
void* operator new[] (void *v, const std::nothrow_t &nt);

Assim, no seu código:

 char *p = new(std::nothrow) char[1024];

Aqui está uma boa refrence para leitura

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top