[C++ 11] Combinaison des mots-clés auto et new, puis delete : secure ?

Bonjour à tous :)

J'ai un fort désir de me mettre à jour en apprenant le C++ moderne (au moins jusqu'au 14 si possible : car il me semble qu'il est très supporté par les divers compilateurs).
J'ai donc fait l'acquisition de ce qui me paraît déjà une excellente introduction en tant qu'ebook : modern c++ programming cookbook.

Nénamoins, dès le départ, il y a un point qui ne me semble pas clair : l'utilisation du mot clé auto avec la création d'objets sur le Heap (par l'intermédiaire de new).

Je m'explique.

Soit le 1er snippet suivant

Code:

---

1 2 3

auto p1 = new int{5}; delete p1;

---

Et le 2e suivant

Code:

---

1 2 3

auto p2 = new int [] {10,20,30}; delete p2;

---

Peut-être aurez-vous deviné que ma question portera sur la bonne utilisation du mot-clé delete dans le 2e snippet : en effet, ce qui m'inquiète c'est que je ne sais pas si je dois écrire

Code:

---

delete p2;

---

ou carrément

Code:

---

delete [] p2;

---

(à l'ancienne).

Qu'est-ce qui est correct ?

Merci d'avance :)

Bonjour,

Tout ce qui est alloué avec new Type[] doit être désalloué avec delete[]. Si tu désalloues avec delete, le comportement est indéterminé et dépend du compilateur.

Cela dit, désallouer manuellement avec delete ou delete[] n'est pas du C++ moderne.
L'inconvénient de désallouer manuellement est que ça oblige à encombrer le code de try-catch pour éviter les fuites mémoires :

Code:

---

1 2 3 4 5 6 7 8

auto p2 = new int[3] {10,20,30}; try { codeQuiPeutLeverUneException(); } catch(...) { delete[] p2; throw; } delete[] p2;

---

A la place de p2, il vaut mieux utiliser une autre variable dont le destructeur libère la mémoire.
Tu as le choix :

Code:

---

1 2	std::array<int, 3> tab1 = {10,20,30}; std::vector<int> tab2 = {10,20,30};

---

• std::array<T, Size> est un tableau de taille fixe. Il encapsule un T[Size] donc contient tout sur place. Il offre aussi les fonctions habituelles des conteneurs de la STL.
• std::vector est un tableau redimensionnable qui utilise la mémoire dynamique.

Jette aussi un œil à la notion de RAII.

PS : auto p2 = new int[3] {10,20,30}; ne compile pas sans le 3.

Merci beaucoup :)

Cela confirme à la fois mes doutes, et m'éclaire correctement sur la voie à suivre : effectivement je pense que le mieux est de passer par la STL.
Je ne pense pas que la réflexion (RAII) soit la meilleure des pratique : déjà quand je codais en Java, je faisais le maximum pour ne pas y avoir recours.

Merci aussi pour mon erreur de syntaxe (la taille du tableau omise) : je pense que cela vient de mon habitude à Java.

Citation:

---

Envoyé par tails

Je ne pense pas que la réflexion (RAII) soit la meilleure des pratique : déjà quand je codais en Java, je faisais le maximum pour ne pas y avoir recours.

---

Parce que JAVA le permet ? Ce n'est plus du pointeur partout et on laisse faire le GC ?
RAII c'est un des concepts les plus importants et puissants, si ce n'est le plus, du C++. Ne pas l'utiliser c'est au mieux stupide, et pour ainsi dire plus difficile que d'y avoir recours tant c'est au coeur du langage.
Et qu'entends-tu par réflexion RAII ??

Btw, auto n'a rien à voir avec l'utilisation de new ou delete. C'est juste pour laisser le compilateur décider du type quand il compile le programme. Que ton objet soit sur la pile ou le tas n'a aucune incidence. Si tu veux une référence il faut le préciser, auto ne déduit que le type, éventuellement la constance, pas la référence et fera une copie.

Citation:

---

Envoyé par Bousk

Parce que JAVA le permet ? Ce n'est plus du pointeur partout et on laisse faire le GC ?
RAII c'est un des concepts les plus importants et puissants, si ce n'est le plus, du C++. Ne pas l'utiliser c'est au mieux stupide, et pour ainsi dire plus difficile que d'y avoir recours tant c'est au coeur du langage.
Et qu'entends-tu par réflexion RAII ??

---

En fait je me suis mal exprimé, par réflexion je voulais simplement dire créer une classe à partir d'une référence de type Class<T>, voire même exécuter l'une de ses méthodes. Edit : oui effectivement j'ai lu l'article dont on m'a pointé le lien plus haut sur la RAII : et je suis tout à fait d'accord pour dire que c'est indispensable. Je ne sais pas pourquoi je me suis mis en tête qu'il s'agit de réflexion de classes.

Citation:

---

Envoyé par Bousk

Btw, auto n'a rien à voir avec l'utilisation de new ou delete. C'est juste pour laisser le compilateur décider du type quand il compile le programme. Que ton objet soit sur la pile ou le tas n'a aucune incidence. Si tu veux une référence il faut le préciser, auto ne déduit que le type, éventuellement la constance, pas la référence et fera une copie.

---

Donc mon tout premier snippet était correct (pas de fuite mémoire) ?

Code:

---

1 2 3

auto p2 = new int [] {10,20,30}; delete p2;

---

Sinon pour le mot-clé auto, je suis conscient effectivement que l'aspect référence est à déclarer pour pouvoir en bénéficier.

Merci d'avance

Citation:

---

Envoyé par tails

Donc mon tout premier snippet était correct (pas de fuite mémoire) ?

Code:

---

1 2 3

auto p2 = new int [] {10,20,30}; delete p2;

---

---

Non parce que comme l'a dit Pyramidev, new[] doit être libéré par delete[]. auto ou pas.

Merci :)

Quand tu es dans le doute:
En C++11, la bonne utilisation de delete consiste à ne jamais y avoir recours -> propriété RFID du RAII, en particulier unique_ptr, shared_ptr, make_shared
En C++14, le bonne utilisation de new consiste à ne jamais y avoir recours -> on rajoute make_unique (RAII sur toute la ligne: depuis l'acquisition de la ressource jusqu'à la finalisation)
(après, je n'ai pas encore regardé l'apport de l'inférence de type sur les constructeurs relativement aux pointeurs intelligents standard)

Quand tu ne seras plus dans le doute, tu pourras potentiellement déroger à la règle, mais n'étant plus dans le doute, tu sauras alors pourquoi la règle est pertinente.

Ce qui veut dire que si `grep -R -E "new|delete" src/` dans ton répertoire de code source te donne des entrées, alors ton code sera perfectible.

Salut,

Citation:

---

Envoyé par tails

Merci beaucoup :)

Cela confirme à la fois mes doutes, et m'éclaire correctement sur la voie à suivre : effectivement je pense que le mieux est de passer par la STL.
Je ne pense pas que la réflexion (RAII) soit la meilleure des pratique : déjà quand je codais en Java, je faisais le maximum pour ne pas y avoir recours.

Merci aussi pour mon erreur de syntaxe (la taille du tableau omise) : je pense que cela vient de mon habitude à Java.

---

RAII N'a absolument rien à voir avec la réflexion (la réflexion, c'est RTTI pour Run Time Type Information)!!!

RAII est l'acronyme de Ressource Acquisition Is Initialization (l'acquisition d'une ressource provoque l'initialisation), et, surtout, de son pendant RFID (Ressource Freing Is Destruction).

Autrement dit, ce principe insiste sur le fait que toutes les données internes d'une variable doivent être correctement acquises dés que tu crées cette variable, et sur l'effet "miroir" de ce fait, à savoir : quand une donnée est détruite, toutes les données internes à cette données doivent aussi être correctement détruites.

Pour des exemples, il y a toute la STL:

• vector et son pointeur vers un tableau
• string et son pointeur vers un tableau
• unique_ptr et son pointeur
• fstream et leur FILE* interne
• et plein d'autres.

Merci :)

Je pense effectivement que je devrais me contenter des static_ptr.

J'ai regardé une partie de conférence de Herb Sutter qui était donné à la CppCon 2014, parlant des "default" : il avait l'air de dire que les static_pointer/shared_pointer sont utilisés abusivement, mais pour ma part c'est précisément ce que je dois faire. En effet, je ne suis pas assez expérimenté pour savoir à quel moment il faut passer par les "naked pointer".

Utilise des unique_ptr. C'est la bonne solution.
Quand ca ne suffit plus, alors, et seulement alors tu peux passer à un shared_ptr.

Il peut arriver qu'on utilise un pointeur nu, mais c'est à redouter.

En gros, un unique_ptr, c'est un pointeur nu sécurisé. Ca ne coûte rien de plus, c'est sûr et c'est fiable.

A l'opposé, un shared_ptr, c'est toute une machinerie pour que la donnée soit partagée entre plusieurs pointeurs (compteur de référence, par exemple). C'est plus gros qu'un pointeur, plus lent, et il y a un risque de dépendence cyclique

Très bien merci :)