Discussion :

[devroot]

Bonjour,

Je cherche à comprendre pourquoi un delete qui porte sur un tableau de longs de taille définie et invariable plante alors que je peux jusqu'à ce point effectuer toutes les opérations de lecture et écriture dans ce tableau sans le moindre problème.

Sans m'étendre sur les détails, voici une idée du code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
long *Tablo = new long [100];
 
for(long i=0; i<100; i++) Tablo[i]=i;
 
if(Tablo)	
{
delete[] Tablo;    // Et là, ça plante : "Access Violation"
Tablo=NULL;
}

[Aurelien.Regat-Barrel]

Est-ce que ce code plante? Je ne pense pas.

Que l'équivalent de ce code, noyé au milieu de plusieurs milliers d'autres lignes plante, c'est possible.

Il suffit simplement qu'il y ait un buffer overflow quelque part ou que Tablo ait été modifié par erreur (Tablo++), et voila...

Connais-tu std::vector?
http://cpp.developpez.com/faq/cpp/?page=STL#STL_vector

[poukill]

En C++, on a maintenant des outils pour déléguer la gestion pure de la mémoire à des entités (classes en fait). Ca s'appelle le RAII.
Les tableaux sont dans 99% des cas remplacer par un vector (cf remarque d'Aurélien). Les 1% restant, on utilise boost::array.
En ce qui concerne les pointeurs, on a aussi tout intérêt à les "donner" à une classe qui les gère, comme boost::shared_ptr.

[devroot]

Ouais...

Devant mon impossibilité de trouver pourquoi le delete plante, j'avais déjà pensé à vector que j'utilise un peu (dans d'autres programmes).
C'est juste que ça me turlupine de pas comprendre pourquoi le delete plante alors que je peux je lire / écrire partout dans cette zone mémoire apparemment bien délimitée. Si moi et l'ordinateur on est d'accord sur l'attribution des 100 cases depuis le début, alors pourquoi le delete (qui doit avoir gardé trace du new long [100]) ne marche-t-il-pas ?

Je crois comprendre la théorie du Tablo++ fautif, mais en vérifiant l'adresse de Tablo, au début et à la fin du programme, je constate qu'elle est la même, donc il n'y a pas eu de déplacement erroné de Tablo. Alors quele peut être la cause du problème ?

En tout état de cause, je passe à Vector...

[poukill]

Y'a une explication, mais le code que nous montre est correct. Peut-être qu'avec un peu plus de code on verrait d'où vient le problème...

[koala01]

Salut,

On peut fortement envisager le fait qu'il y ait quelque chose entre la partie

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

for(long i=0; i<100; i++) Tablo[i]=i;

et la partie

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if(Tablo)

Et il y a fort à parier (bien que n'ayant pas vu le code) qu'il y aura l'un ou l'autre appel de fonction

Si l'une de ces fonctions appelées (ou pire, l'une des fonctions éventuellement appelées par une des fonctions qui se trouve entre les deux parties de code) appelle delete[] sur Tablo (ou sur le nom qu'il obtient lors du passage par argument), bien que *sensé* représenter une adresse valide, ce n'est peut être plus le cas.

A ce moment là, toute tentative de refaire un delete[] sur cette adresse - devenue invalide - occasionnera systématiquement une violation d'accès

Si donc, tu as d'autres fonctions qui peuvent vouloir libérer la mémoire de ce pointeur, il est préférable de fournir un pointeur de pointeur comme argument, de libérer la mémoire sur ce qui est pointé par cet argument et de le faire pointer sur NULL.

Cela permettra, au sortir de la fonction, que Tablo valle NULL et donc que le test ne provoque pas cette tentative de nouvelle libération de la mémoire

Ceci dit, on ne peut que t'inciter à envisager l'utilisation des std::vector<un type> aussi souvent que possible