Je me demandais s'il est possible d'attraper des erreurs comme celle-ci en C ++: Je sais que je pourrais définir le pointeur
p code> sur
null code> après la suppression du premier objet. Mais imaginez que vous ne le feriez pas. P> p>
4 Réponses :
Je ne pense pas que vous puissiez attraper ce genre d'erreur parce que je pense que le résultat est un comportement indéfini. Cela pourrait ne rien faire, cela pourrait tomber, cela pourrait simplement corrompre la mémoire et causer un problème plus tard dans la ligne. P>
Si vous avez trouvé que cela a fait quelque chose de spécifique avec votre compilateur actuel, vous pourriez essayer de gérer cela, mais cela pourrait faire différentes choses dans le débogage et la libération, ainsi que différez lorsque vous mettez à niveau la version du compilateur. P>
Réglage du pointeur sur NULL a été suggéré, mais je pense que vous seriez mieux à utiliser des pointeurs intelligents et ne les supprimez pas du tout. P>
Malheureusement, je ne peux pas parler pour le monde de Windows, mais je sais qu'il y a des outils dans le monde UNIX qui le fait pour vous (en runtime) p>
L'idée est d'implémenter les fonctions d'allocation de mémoire avec quelques contrôles supplémentaires. La bibliothèque peut être dit d'abandonner le processus lorsqu'un problème est trouvé et que vous pouvez trouver le problème en regardant la trace de la pile. Libumem sur Solaris en est un exemple. P>
Je suis sûr qu'il doit y avoir des choses similaires sur la plate-forme Windows. P>
Il existe d'autres outils qui utilisent une analyse de code statique qui vous aidera à trouver les problèmes avant d'exécuter le code. Coverity est un exemple, et je pense que cela fonctionne également sur Windows. Nous avons réussi à trouver des problèmes potentiels potentiels avec une couverture. Malheureusement, ce n'est pas gratuit. Les versions d'évaluation doivent être possibles cependant. P>
Un autre outil utile (non libre) est purifié. C'est un vérificateur d'accès à la mémoire d'exécution et cela fonctionne vraiment bien, ramassant toutes sortes de problèmes potentiels. Si vous êtes sur Linux, il y a aussi Valgrind et Efence.
Pourquoi personne ne veut utiliser des pointeurs intelligents tels que Boost :: partagé_ptr code>? Si vous l'utilisez, vous pouvez oublier
Supprimer code> -Oprateur. ;) p>
Vous pouvez attraper ces erreurs avec tout débogueur de mémoire telle que limiteChecker ou purifie sous Windows et avec
La question ne se pose pas de la manière de récupérer de telles erreurs, la question est de savoir comment ne pas les faire en premier lieu. (Il en va de même pour définir les pointeurs sur
null code>. Pourquoi un pointeur dans la portée qui ne fait pas référence à quelque chose?) C ++ est livré avec de nombreuses constructions qui vous empêchent de gérer manuellement des pointeurs (et d'autres ressources). Au cours de la dernière décennie de faire C ++, je devais rarement à manuellement supprimer code> n'importe quoi.
@Job à droite vous êtes - auriez-vous dû arracher la référence.