Est-ce nouveau NULL de retour dans tous les cas?

Question

Je sais que, selon C ++ standard dans le cas où le nouveau ne parvient pas à allouer de la mémoire, il est censé jeter exception std :: bad_alloc. Mais je l'ai entendu dire que certains compilateurs tels que VC6 (ou la mise en œuvre du CRT?) Ne respectent pas. Est-ce vrai ? Je demande cela parce que la vérification des NULL après chaque nouvelle déclaration rend le code très laid regarder.

Answer 1

VC6 était non conforme par défaut à cet égard. La new de VC6 retourné 0 (ou NULL).

Voici l'article KB de Microsoft sur cette question ainsi que leur solution proposée à l'aide d'un gestionnaire de new personnalisé:

• opérateur new ne jette pas une exception bad_alloc en cas d'échec dans Visual C ++

Si vous avez l'ancien code qui a été écrit pour le comportement VC6, vous pouvez obtenir ce même comportement avec les nouveaux compilateurs MSVC (quelque chose comme 7.0 et versions ultérieures) en liant dans un fichier objet nommé nothrownew.obj. Il y a en fait un ensemble assez complexe de règles dans la 7.0 et 7.1 compilateurs (VS2002 et VS2003) pour déterminer si elles par défaut à la non-lancer ou de lancer new.

Il semble que MS nettoyé cette à 8,0 (VS2005) -Maintenant il toujours par défaut à un lancer nouvelle à moins que vous liez spécifiquement nothrownew.obj.

Notez que vous pouvez spécifier que vous voulez new pour revenir 0 au lieu de jeter std::bad_alloc en utilisant le paramètre std::nothrow:

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

Cela semble travailler dans VC6, il pourrait être un moyen de fixer plus ou moins mécaniquement le code pour la même chose avec tous les compilateurs afin que vous n'avez pas à retravailler la gestion des erreurs existantes.

Answer 2

Je voudrais ajouter l'opinion (quelque peu controversé) que la vérification de la valeur NULL après une tentative d'allocation est à peu près un exercice futile. Si votre programme se déroule toujours dans cette situation, il est probable que vous ne pouvez pas faire beaucoup plus que la sortie rapide. Il est très probable que toute tentative d'attribution ultérieure échouera également.

Sans vérifier NULL, votre code subséquent tenterait de déréférencer un pointeur NULL, ce qui a tendance à quitter rapidement le programme, avec une condition de sortie relativement unique (et facilement débogable).

Je ne veux pas vous parler de vérifier la valeur NULL, il est certainement la programmation consciencieuse. Mais vous ne gagnez pas beaucoup de celui-ci, à moins que dans des cas très spécifiques où vous pouvez peut-être stocker des informations de récupération (sans allouer plus de mémoire), ou sans mémoire moins importante, etc. Mais ces cas sont relativement rares pour la plupart des gens.

Compte tenu de cela, je venais de confiance au compilateur de lancer bad_alloc, personnellement -. Au moins dans la plupart des cas

Answer 3

Basé sur la spécification C ++, il sera toujours jeter std :: bad_alloc lorsque vous utilisez tout simplement nouveau sans params, mais bien sûr, il peut y avoir des compilateurs non conformes.

Je ne voudrais pas le code pour être conforme aux non c ++ compilateurs compatibles cependant. VC6 étant l'un d'entre eux à cet égard.

Il est bon que pour définir toujours votre pointeur NULL après leur suppression. Donc, à cause de cela, la vérification de la valeur NULL est toujours nécessaire.

Cela étant dit, voici quelques options à nettoyer votre code:

Option 1: Réglage de votre nouveau gestionnaire

Un moyen sûr de nettoyer votre code serait d'appeler: un bon refrence pour aller plus loin