Différence entre delete et delete []

Bonjour

On sait tous que quand on fait une allocation dynamique,

Code:

---

int *o=new int[100];

---

Il faut désallouer avec delete [] et non delete. Alors moi, j'ai essayé en débug de voir ce qu'il se passe avec visual studio. J'ai tout d'abord linké le programme avec la version release de la CRT. Ensuite, j'ai fait ceci:

Code:

---

1 2 3 4 5

int *o=new int[100]; for(int j=0;j<100;j++) o[j]=3; delete o;

---

Ce qui est pas bon. Quand j'alloue le tableau de 100 int de valeur 3, je vois ceci:
Pièce jointe 77973
On voit bien le tableau avec les 100 int. Ensuite, quand je fais le delete, je vois que tous les int sont désalloués. Moi, je m'attendais à ce que seule la première adresse, celle pointée par o soit désallouée.
Une fois le delete executée, voila ce que je vois:
Pièce jointe 77974

Ensuite, j'ai fait le truc correct:

Code:

---

1 2 3 4 5

int *o=new int[100]; for(int j=0;j<100;j++) o[j]=3;   delete [] o;

---

Et dans la première image, on voit l'allocation, et dans la deuxième, on voit la désallocation.

Pièce jointe 77975


Pièce jointe 77976

On voit qu'il n'y a aucune différence. Je ne comprends pas. Comment faire pour voir la différence entre delete et delete[] ?

Merci

Hello

A mon avis, c'est juste une optimisation qui détecte ton erreur et la corrige.

salut ,

sur un type simple (ADT) tu ne verras pas la différence, car dans les deux cas ça ne fait que libéréer la mémoire allouée

par contre sur un type avec constructeur/destructeur là il y a différence

dans delete : seul le premier destructeur est appelé ensuite la mémoire est libérée

dans delete[] : les destructeurs sont appelée et la mémoire libérée

Cdt

:koi: détail d'implémentation du compilateur. Cela n'a que peu de sens de regarder.
Tu invoques un comportement non défini. Donc le compilateur peut faire comme si de rien était, générer une exception, planter ou faire le café. Je ne vois vraiment pas l'intérêt de cette question :koi:

Citation:

---

sur un type simple (ADT) tu ne verras pas la différence, car dans les deux cas ça ne fait que libéréer la mémoire allouée

---

J'ai testé avec une classe contenant un int et un double. Pas vu de différence entre delete et delete [].

Citation:

---

Tu invoques un comportement non défini. Donc le compilateur peut faire comme si de rien était, générer une exception, planter ou faire le café. Je ne vois vraiment pas l'intérêt de cette question

---

Hé oui, mais c'est bien facile de dire que l'on provoque une exception, on dit ce que raconte la norme.
Encore faut il le démontrer et/ou l'expérimenter. C'est comme ca que je comprends.

Citation:

---

Envoyé par deubelte

Hé oui, mais c'est bien facile de dire que l'on provoque une exception, on dit ce que raconte la norme.
Encore faut il le démontrer et/ou l'expérimenter. C'est comme ca que je comprends.

---

J'ai pas dit que ça provoque une exception. J'ai dit que tu évoques un comportement indéterminé (l'exception pouvant être une réponse comme une autre). Pour le reformuler autrement, tu écris un code faux et buggé et tu regardes comment ça marche ... au cas où quoi ? Au cas où ça tomberait en marche ? Et quelle(s) serai(en)t ta(tes) conclusion(s) alors ?? Aucune car tu invoques un comportement indéterminé. Tu ne peux donc rien conclure sur ce comportement.

Citation:

---

J'ai pas dit que ça provoque une exception. J'ai dit que tu évoques un comportement indéterminé (l'exception pouvant être une réponse comme une autre).

---

Peux tu me donner un cas où ca renverrait une exception? Enfin, un truc qui plante?

Merci

Citation:

---

Envoyé par kessoufi

salut ,

sur un type simple (ADT) tu ne verras pas la différence, car dans les deux cas ça ne fait que libéréer la mémoire allouée

---

ADT, pour moi c'est Abstract Data Type. Peut-être pensais-tu à POD (Plain Old Data) ? En fait, dans l'implémentation de Microsoft Visual C++ 2010 en mode débug et avec les options de compilations (XXX) cela a plus à voir avec la nécessité ou non d'appeler un constructeur ou un destructeur. (la présence d'un destructeur rend en C++98 un type non POD mais pas la seule présence d'un constructeur).
Pour reprendre, new/new[] fait deux choses : allouer un espace mémoire suffisant et appeler le constructeur qu'il faut. delete/delete[] à l'inverse appelle les destructeurs nécessaires et libère la mémoire.
Un new int[]/delete [] ou un new int[]/delete semblent identique car j'imagine que l'implémentation la plus facile pour un compilateur est d'appeler juste la fonction d'allocation et de libération de la mémoire. MAIS CA RESTE UN COMPORTEMENT INDETERMINE

Citation:

---

Envoyé par deubelte

Peux tu me donner un cas où ca renverrait une exception?

---

Bon une exception non car un delete ne devrait pas en générer.

Citation:

---

Envoyé par deubelte

Enfin, un truc qui plante?

Merci

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

#include <memory>   void *operator new[](std::size_t) throw(std::bad_alloc) { static int my_buffer[100]; return &my_buffer[0]; }   void operator delete[](void *ptr) throw() {}   #include <iostream> int main() { int *p = new int[0]; delete []p; // ok   int *q = new int[0]; delete p; // plantage     std::cout<<"bye\n"; return 0; }

---

Ceci dit, tu invoques un comportement indéterminé. Quelles conclusions tu peux en tirer ??? J'aimerais bien comprendre :koi:

Yo,
j'ai essayé un nouveau truc, avec cette classe non POD.

Code:

---

1 2 3 4 5 6 7 8

class S{ public: S(){}; S(int y,std::string d):o(y),e(d){}; private: int o; std::string e; };

---

quand je fais ca:

Code:

---

1 2 3 4

S* o=new S[100]; for(int j=0;j<100;j++) o[j]=S(1,"ee"); delete [] o;

---

ça marche, alors si je fais delete o;

ca me renvoie comme erreur:

Citation:

---

Windows has triggered a breakpoint in cac.exe.

This may be due to a corruption of the heap, which indicates a bug in cac.exe or any of the DLLs it has loaded.

This may also be due to the user pressing F12 while cac.exe has focus.

The output window may have more diagnostic information.

---

Citation:

---

Envoyé par deubelte

...

---

:bravo::bravo::bravo:


Et moi, et moi, quand je fais ça :

Code:

---

1 2 3 4 5 6

int main() { int bug = 0; bug = 1/bug; return 0; }

---

Ben j'ai un bug (ou pas car là aussi c'est un comportement indéterminé)

ça me fait pareil avec cette classe ( ça déclenche un breakpoint) :

Code:

---

1 2 3 4 5 6

struct a { int i; ~a() {} };

---

mais lorsque je commente le destructeur ça passe (comme pour un int*), et pourtant ce n'est pas du POD,

oui, mais il fallait le savoir que en mettant que des integrales, ca marche, alors que quand on mets des string, ca renvoie une erreur!!
:ccool:

Citation:

---

mais lorsque je commente le destructeur ça passe (comme pour un int*), et pourtant ce n'est pas du POD,

---

idem pour moi. Alors ca c'est marrant. Pourquoi quand on déclare un destructeur, ca marche pas, alors que quand on le déclare, ca marche??

Il n'y a pas de raison. Comme l'a dit 3DArchi, tu utilise un fonctionnalité à un endroit où tu n'es pas censé l'utilisé. Si ça marche, c'est grâce à l'opération du saint esprit. Et ce n'est pas dit que ça remarchera une autre fois.

Citation:

---

Envoyé par pyros

Il n'y a pas de raison. Comme l'a dit 3DArchi, tu utilise un fonctionnalité à un endroit où tu n'es pas censé l'utilisé. Si ça marche, c'est grâce à l'opération du saint esprit. Et ce n'est pas dit que ça remarchera une autre fois.

---

+100000

Citation:

---

Envoyé par deubelte

oui, mais il fallait le savoir que en mettant que des integrales, ca marche, alors que quand on mets des string, ca renvoie une erreur!!
:ccool:

---

uh? C'est un comportement indéterminé... cherche pas, fait le sur un autre pc, un autre jour, à la pleine lune, etc et sa sera pas pareil. C'est le propre même d'un comportement indéterminé... tu te poses des questions réellement inutile là, y'a des choses bien plus intéressantes à comprendre et à apparendre.

pour répondre a ta question, lorsque delete[] est forcé d'appeler des destructeurs, new[] ajoute 4 octets (pit-être 8 en 64 bits :) ) avant les objets et y met le nombre d'objet.

delete[] lit alors ce qui se trouve avant les objets, appelle X fois le destructeur, et libère en appelant free(array-4)
delete (sans le []) appelle le destructeur une fois, et ensuite appèle free(array) => d'où un crash puisque ce n'est pas le début du bloc mémoire.

si il n'y a pas de destructeur a appeler, new[] n'ajoute pas le nombre d'objet et delete[] ne fait que liberer la mémoire, ce qui est le même comportement que delete sans [].

MAIS ca c'est un détail d'implémentation, si c'est différent sur un autre compilo personne n'ira regarder. C'est grossièrement valable sur GCC et visual studio, sans doute partout mais aucune garantie.

Salut,

Il faut surtout comprendre que l'appel de delete (respectivement delete[] ) sur quelque chose créé par new[] (respectivement new) provoque un comportement indéterminé (selon la norme)!!!

A partir de là, et quoi que puisse te dire ton compilateur, il s'agit de prendre toutes les dispositions pour éviter d'en arriver à un tel état de fait, à savoir:

• invoquer impérativement delete[] sur quelque chose créé par new[]
• invoquer impérativement delete sur quelqeu chose créé par new

N'oublie pas, non plus, que l'existence des différentes collections (tant issues du standard que celles rajoutées par boost) et des pointeurs intelligents devraient le plus souvent te permettre d'éviter le recours à delete[] ;)

En fait, je me suis posé cette question, car dans le livre de Sutter, exceptionnal C++, page 144, on a:

Consider the following code:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

class B { virtual ~B(); void operator delete (void*,size_t) throw(); void operator[] delete (void*,size_t) throw(); void f(void*,size_t) throw(); }; class D: public B { public: void operator delete (void*)throw(); void operator delete[] (void*)throw(); };

---

Or, dans le livre de Scott Meyers, il nous dit qu'il ne faut jamais traiter des tableau de manière polymorphe.
(Never treat array polymorphically). mais dans le code ci-dessus, cela laisse penser qu'on va utiliser des tableaux d'objets dérivés.

Il y a comme un petit problème, ou du moins, une incohérence dans la question de Sutter.

Tu remarqueras que tes opérateurs delete ne sont pas virtuels, ce qui implique que... leur utilisation ne sera pas polymorphique ;) : tu te trouve dans une situation dans laquelle l'operateur delete de D cache celui de B, pour autant que tu ait la certitude de travailler avec un pointeur sur D.

!!! si tu appelle delete sur un pointeur sur B qui pointe vers un objet de type D, ce sera l'operateur B::delete qui sera appelé, et non l'opérateur D::delete, avec tous les dangers que cela peut représenter !!!

Je croyais que l'operator delete ne pouvait être virtuel, m'aurait-on mentis ?

Citation:

---

Envoyé par koala01

Tu remarqueras que tes opérateurs delete ne sont pas virtuels, ce qui implique que... leur utilisation ne sera pas polymorphique ;) : tu te trouve dans une situation dans laquelle l'operateur delete de D cache celui de B, pour autant que tu ait la certitude de travailler avec un pointeur sur D.

!!! si tu appelle delete sur un pointeur sur B qui pointe vers un objet de type D, ce sera l'operateur B::delete qui sera appelé, et non l'opérateur D::delete, avec tous les dangers que cela peut représenter !!!

---

Non, non.

Les opérateurs new et delete d'une classe sont toujours static même s'ils ne sont pas explicitement définis comme tel (de toute façon à quelle instance s'appliquerait un new??). Ils ne peuvent donc être virtuels.

delete p utilise le type statique de p pour savoir si l'appel est valide et utilise l'opérateur delete du type dynamique de p si le destructeur du type statique est virtuel.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

struct B { virtual ˜B(); void operator delete(void*, size_t); }; struct D : B { void operator delete(void*); }; void f() { B* bp = new D; delete bp; //1: uses D::operator delete(void*) }

---

Sinon, c'est indéterminé

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

struct B { ˜B(); void operator delete(void*, size_t); }; struct D : B { void operator delete(void*); }; void f() { B* bp = new D; delete bp; //undefined behaviour }

---

delete []p sur un type statique et dynamique différent est un comportement indéterminé.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

struct B { virtual ˜B(); void operator delete[](void*, size_t); }; struct D : B { void operator delete[](void*, size_t); }; void f(int i) { D* dp = new D[i]; delete [] dp; // uses D::operator delete[](void*, size_t) B* bp = new D[i]; delete[] bp; // undefined behavior }

---

pour être précis, delete appelle le destructeur de la classe (dynamique donc) avec un paramètre caché, 1
ce paramètre dit "libère la mémoire après l'appel"
le destructeur appelle les destructeurs des classes parentes avec le paramètre 0, puis libère la mémoire avec operator delete qui correspond le mieux (celui de la classe si possible, sinon celui du parent, etc etc)
comme c'est le destructeur qui libère la mémoire, il appelle toujours le delete correct.


En gros lorsque tu fais delete a; il se passe:

Code:

---

1 2	push 1 call vtable(a)->0

---

et le destructeur:

Code:

---

1 2 3 4 5

...blablabla destruction push 0 call parentdestructor if parametrecaché call operator delete

---

(encore une fois c'est du détail d'imlémentation et on est pas sensé savoir, hein, c'est juste pour expliquer comemnt ca marche et c'est pas par magie)

Merci pour toutes vos réponses, mais ca m'enmèle un peu. Doit on utiliser ou non un tableau sur des objets dynamiques?


Dans les classes données par Sutter, estce que vous pouver me donner des exemples d'implémentation des delete et des new qui sont déclarés?

merci

Citation:

---

Envoyé par screetch

(encore une fois c'est du détail d'imlémentation et on est pas sensé savoir, hein, c'est juste pour expliquer comemnt ca marche et c'est pas par magie)

---

Quel compilateur ? Quelle version ? ;)

Ceci dit, quand tu es codeur C++, c'est undefined behaviour qui est important. Ce que tu décris concerne le développeur de compilateur.

Citation:

---

Envoyé par deubelte

Merci pour toutes vos réponses, mais ca m'enmèle un peu. Doit on utiliser ou non un tableau sur des objets dynamiques?

---

objet dynamique :koi: La réponse est : la sémantique de copie est rarement compatible avec la sémantique d'entité qui est souvent celle d'un héritage publique. Alors syntaxiquement, pfff... C'est tout de suite le souk.

Citation:

---

Envoyé par deubelte

Dans les classes données par Sutter, estce que vous pouver me donner des exemples d'implémentation des delete et des new qui sont déclarés?

merci

---

Bonne lecture de la traduction dvp de Penser en C++, 13.5.2. Surcharger new & delete pour une classe de Bruce Eckel

Citation:

---

Envoyé par 3DArchi

Quel compilateur ? Quelle version ? ;)

Ceci dit, quand tu es codeur C++, c'est undefined behaviour qui est important. Ce que tu décris concerne le développeur de compilateur.

---

Oui c'etait juste pour expliquer comment les compilateurs appellent la méthode "delete" correcte en fonction du type dynamique. Ca n'a aucun autre but qu'être éducatif.

sinon, quel compilo: Visual studio et GCC au moins :)

Citation:

---

La réponse est : la sémantique de copie est rarement compatible avec la sémantique d'entité qui est souvent celle d'un héritage publique. Alors syntaxiquement, pfff... C'est tout de suite le souk.

---

.

C'est quoi la sémantique de copie ?

C'est quoi la sémantique d'entité?

Citation:

---

Envoyé par screetch

sinon, quel compilo: Visual studio et GCC au moins :)

---

Ah, OK. C'était pour savoir si tu avais regardé que visual ou d'autres compilo.

Citation:

---

Envoyé par deubelte

.

C'est quoi la sémantique de copie ?

C'est quoi la sémantique d'entité?

---

F.A.Q. à partir d'ici et à partir d'ici

Ou dans une approche connexe : Fonctions virtuelles et L'operateur d'affectation : operator=

Citation:

---

Envoyé par deubelte

En fait, je me suis posé cette question, car dans le livre de Sutter, exceptionnal C++, page 144, on a:

Consider the following code:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

class B { virtual ~B(); void operator delete (void*,size_t) throw(); void operator[] delete (void*,size_t) throw(); void f(void*,size_t) throw(); }; class D: public B { public: void operator delete (void*)throw(); void operator delete[] (void*)throw(); };

---

Or, dans le livre de Scott Meyers, il nous dit qu'il ne faut jamais traiter des tableau de manière polymorphe.
(Never treat array polymorphically). mais dans le code ci-dessus, cela laisse penser qu'on va utiliser des tableaux d'objets dérivés.

Il y a comme un petit problème, ou du moins, une incohérence dans la question de Sutter.

---

As-tu lu la question (et surtout l'explication) jusqu'au bout ?

Car justement il se sert de ce bout de code pour montrer qu'on ne doit pas traiter polymorphiquement des tableaux (c'est dans la partie 2 de l'item en question). Je cite :

Citation:

---

Envoyé par Exceptional C++ (item 36)

B* pb2 = new D[10];
delete[] pb2;

This is undefined behavior. The language requires that the static type of the pointer that is passed to operator delete[]() must be the same as its dynamic type. For more information on this topic, see also Scott Meyers' section, "Never Treat Arrays Polymorphically" in Meyers99.

Guideline

Never treat arrays polymorphically.

---

Citation:

---

Envoyé par deubelte

Merci pour toutes vos réponses, mais ca m'enmèle un peu. Doit on utiliser ou non un tableau sur des objets dynamiques?

---

Non : Never treat arrays polymorphically.

Citation:

---

Envoyé par gl

Non : Never treat arrays polymorphically.

---

Ceci dit cette formulation ne doit pas être lue trop vite. Le problème n'est pas qu'on ne doit pas allouer dynamiquement des objets polymorphes. Ce que dit la phrase est que le tableau dynamique ne doit pas être traité de façon polymorphe, i.e. le pointeur sur le tableau doit avoir type statique et type dynamique qui coïncident.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

struct B { virtual ˜B(); void operator delete[](void*, size_t); }; struct D : B { void operator delete[](void*, size_t); }; void f(int i) { D* dp = new D[i]; delete [] dp; // uses D::operator delete[](void*, size_t) }

---

==> OK dp n'est pas traité de façon polymporphe : le tableau est bien un tableau de D

Code:

---

1 2 3 4 5

void f(int i) { B* bp = new D[i]; delete[] bp; // undefined behavior }

---

==> KO pp est traité de façon polymporphe : le tableau bp de type B* alors que ce sont des D

Citation:

---

Envoyé par 3DArchi

Ceci dit, quand tu es codeur C++, c'est undefined behaviour qui est important. Ce que tu décris concerne le développeur de compilateur.

---

Disons qu'il y a certaines personnes qui ont besoin de comprendre la motivation derrière une règle pour comprendre et retenir la règle. Pour ma part, je sais que si j'accepte sans soucis le "c'est comme ça pour des raisons qu'on verra plus tard", j'ai du mal avec le "c'est comme ça parce que c'est comme ça".

Citation:

---

Envoyé par 3DArchi

Ceci dit cette formulation ne doit pas être lue trop vite. Le problème n'est pas qu'on ne doit pas allouer dynamiquement des objets polymorphes. Ce que dit la phrase est que le tableau dynamique ne doit pas être traité de façon polymorphe, i.e. le pointeur sur le tableau doit avoir type statique et type dynamique qui coïncident.

---

Effectivement ma réponse était un peu lapidaire[1]. Tu as eu raison de compléter et préciser.


[1] Je m'étais placé dans le contexte du questionnement initial, et non dans le cadre de la formulation directe de la réponse que j'ai citée. Mon intervention est du coup assez confusante.

Citation:

---

Envoyé par gl

Effectivement ma réponse était un peu lapidaire. Tu as eu raison de compléter et préciser.

---

C'est pas tant ta réponse que la phrase de Sutter qui doit bien être lue en dégustant chaque mot. Le problème avec ces gens là c'est qu'ils pensent qu'on a tous un esprit aussi rapide et affuté qu'eux. Moi, ca me demande souvent de relire plusieurs fois cette pauv' phrase de 4 mots et je suis pas sur d'avoir tout compris :aie:

Citation:

---

Bonne lecture de la traduction dvp de Penser en C++, 13.5.2. Surcharger new & delete pour une classe de Bruce Eckel

---

J'ai lu. C'est un bon exemple d'allocation sur la stack (si j'ai bien compris). On crée une variable statique de la classe, qui sert d'allocation globale, et on alloue au fur et a mesure des objets de cette classe.
C'est la première fois que je vois un exemple de l'opérateur new qui n'alloue pas sur le tas.

Citation:

---

Envoyé par deubelte

J'ai lu. C'est un bon exemple d'allocation sur la stack (si j'ai bien compris). On crée une variable statique de la classe, qui sert d'allocation globale, et on alloue au fur et a mesure des objets de cette classe.
C'est la première fois que je vois un exemple de l'opérateur new qui n'alloue pas sur le tas.

---

Pas de bol. Ce n'est ni sur la pile, ni sur le tas ;)

Les variables statiques sont dans des zones dédiées et ne sont donc ni sur la pile ni sur le tas.

Petite remarque : le C++ en soi ne contient aucune notion de pile, de tas, de zone code, de zone données, etc. Le langage ne parle que de la durée de vie d'une variable. Les notions de pile, de tas, et des zones données ou de code relèvent du cours de système :D

oK,
mais pour répondre à la question initiale de l'exo, sur pourquoi size_t est présent dans la déclaration de delete dans B et pas dans D, je dirais que B ne connait à priori pas la taille de l'objet D. Il est donc nécessaire de lui indiquer la taille de l'objet à supprimer.


C'est quoi d'ailleurs la différence entre le heap, et ce qu'on appelle "free store"?