Utiliser RAII
- Oubliez la collecte des ordures (utilisez plutôt RAII). Notez que même le garbage collector peut également fuir (si vous oubliez de "null" certaines références en Java / C #), et que le garbage collector ne vous aidera pas à disposer des ressources (si vous avez un objet qui a acquis un handle pour un fichier, le fichier ne sera pas libéré automatiquement lorsque l'objet sortira de la portée si vous ne le faites pas manuellement en Java, ou utilisez le modèle «disposer» en C #).
- Oubliez la règle «un retour par fonction» . C'est un bon conseil en C pour éviter les fuites, mais il est obsolète en C ++ en raison de son utilisation d'exceptions (utilisez plutôt RAII).
- Et bien que le "Sandwich Pattern" soit un bon conseil en C, il est obsolète en C ++ en raison de son utilisation d'exceptions (utilisez plutôt RAII).
Ce message semble être répétitif, mais en C ++, le modèle le plus basique à connaître est RAII .
Apprenez à utiliser des pointeurs intelligents, à la fois de boost, TR1 ou même du modeste (mais souvent assez efficace) auto_ptr (mais vous devez connaître ses limites).
RAII est à la fois la base de la sécurité des exceptions et de l'élimination des ressources en C ++, et aucun autre modèle (sandwich, etc.) ne vous donnera les deux (et la plupart du temps, il ne vous en donnera aucun).
Voir ci-dessous une comparaison du code RAII et non RAII:
void doSandwich()
{
T * p = new T() ;
// do something with p
delete p ; // leak if the p processing throws or return
}
void doRAIIDynamic()
{
std::auto_ptr<T> p(new T()) ; // you can use other smart pointers, too
// do something with p
// WON'T EVER LEAK, even in case of exceptions, returns, breaks, etc.
}
void doRAIIStatic()
{
T p ;
// do something with p
// WON'T EVER LEAK, even in case of exceptions, returns, breaks, etc.
}
À propos de RAII
Pour résumer (après le commentaire d' Ogre Psalm33 ), RAII repose sur trois concepts:
- Une fois l'objet construit, ça marche! Acquérez des ressources dans le constructeur.
- La destruction d'objets suffit! Libérez des ressources dans le destructeur.
- Tout est question de lunettes! Les objets scoped (voir l'exemple doRAIIStatic ci-dessus) seront construits à leur déclaration, et seront détruits au moment où l'exécution quitte la portée, peu importe comment la sortie (retour, rupture, exception, etc.).
Cela signifie que dans un code C ++ correct, la plupart des objets ne seront pas construits avec newet seront déclarés sur la pile à la place. Et pour ceux construits en utilisant new, tout sera en quelque sorte limité (par exemple attaché à un pointeur intelligent).
En tant que développeur, c'est en effet très puissant car vous n'aurez pas besoin de vous soucier de la gestion manuelle des ressources (comme cela se fait en C, ou pour certains objets en Java qui utilisent intensivement try/ finallypour ce cas) ...
Modifier (12/02/2012)
"les objets à portée ... seront détruits ... peu importe la sortie" ce n'est pas tout à fait vrai. il existe des moyens de tromper RAII. toute saveur de terminate () contournera le nettoyage. exit (EXIT_SUCCESS) est un oxymore à cet égard.
- wilhelmtell
wilhelmtell a tout à fait raison à ce sujet: il existe des moyens exceptionnels de tromper RAII, qui mènent tous à l'arrêt brutal du processus.
Ce sont des moyens exceptionnels car le code C ++ n'est pas jonché de terminate, exit, etc., ou dans le cas d'exceptions, nous voulons qu'une exception non gérée plante le processus et vider son image mémoire telle quelle, et non après le nettoyage.
Mais nous devons toujours être au courant de ces cas car, s'ils se produisent rarement, ils peuvent toujours se produire.
(qui appelle terminateou exiten code C ++ occasionnel? ... Je me souviens avoir dû faire face à ce problème en jouant avec GLUT : Cette bibliothèque est très orientée C, allant jusqu'à la concevoir activement pour rendre les choses difficiles pour les développeurs C ++ comme ne pas s'en soucier sur les données allouées à la pile , ou avoir des décisions "intéressantes" pour ne jamais revenir de leur boucle principale ... je ne commenterai pas à ce sujet) .