C++ (14) et gestion manuelle de la mémoire

Question

Je viens de recevoir un commentaire, comme

Le problème est la gestion manuelle de la mémoire. delete n'a pas sa place dans le code utilisateur et, à partir de C++14, il n'a pas non plus sa place dans le code utilisateur. new

Quelqu'un peut-il m'expliquer pourquoi ?

Answer 1

Caveat : Je maintiens cette réponse car je pense qu'elle présente une meilleure pratique qui améliorera ~95% du code C++ - probablement même plus. Cela dit, veuillez lire le complet pour une discussion de certaines mises en garde importantes.

Puisque c'était mon commentaire, voici ma présentation en expliquant ça.

En un mot :

Pointeurs [Raw] ne doivent pas. posséder. ressources.

C'est une source d'erreurs et c'est inutile, car nous disposons de meilleures méthodes de gestion des ressources qui permettent de réduire le nombre d'erreurs, d'obtenir un code plus court et plus lisible et d'améliorer la qualité de l'information. confiance dans l'exactitude du code. En termes économiques : ils coûtent moins cher.

Pour être plus précis en ce qui concerne le commentaire que j'ai fait :

Depuis C++11 (sorti depuis deux ans et implémenté, dans les parties concernées, par tous les compilateurs modernes), la suppression manuelle de la mémoire est totalement inutile (sauf si vous écrivez très code de gestion de la mémoire de bas niveau) parce que vous pouvez toujours utiliser des pointeurs intelligents à la place, et n'en avez généralement même pas besoin (voir la présentation). Cependant, C++11 exige toujours l'utilisation de new lors de l'instanciation d'un nouveau std::unique_ptr . En C++14, la fonction std::make_unique rend cette utilisation de new inutile. Par conséquent, il n'est plus nécessaire non plus.

Il y a sans doute encore une place pour le placement new dans le code, mais c'est (a) un cas entièrement différent de la normale new même si la syntaxe est similaire, et (b) peut être remplacée dans la plupart des cas par l'utilisation de l'attribut allocator::construct fonction.

---

James a signalé une exception à cette règle que j'avais honnêtement oubliée : lorsqu'un objet gère son propre temps de vie. Je vais me risquer à dire que ce n'est pas un idiome courant dans la plupart des scénarios, parce que la durée de vie d'un objet est plus longue que celle d'un autre. peut toujours être gérés en externe. Cependant, dans certaines applications, il peut être avantageux de découpler l'objet du reste du code et de le laisser se gérer lui-même. Dans ce cas, vous devez allouer dynamiquement l'objet et le désallouer à l'aide de la fonction delete this .

Answer 2

Smart pointers et à son tour std::make_shared y std::make_unique doit être utilisé à la place car le traitement des new/delete etc. est plus sujet à des erreurs lorsque les applications lèvent des exceptions, etc.

Les pointeurs intelligents suppriment automatiquement (en utilisant RAII ) lorsqu'il est utilisé même lorsque des exceptions sont levées, contrairement à new/delete qui peut provoquer des fuites de mémoire.

Ver ce y ce pour plus d'informations

Answer 3

La seule chose que la déclaration citée dit est que la personne qui l'a dit ne comprend pas vraiment la conception de programmes ou la façon dont C++ (et la façon dont la mémoire dynamique est utilisée en C++). La déclaration de déclaration définit un anti-modèle, plus qu'autre chose.

Il y a sont types particuliers d'applications où il pourrait être L'application sur laquelle je travaille actuellement en est une. Mais ce n'est pas général, et dans la plupart des applications sur lesquelles j'ai travaillé dans le passé, la plupart des suppressions se faisaient dans le code utilisateur. (Celles ceux qui ne l'étaient pas étaient dans des classes de base comme std::vector .)