tableau trop grand ?

Salut

J'ai une classe CObjet qui contient un int*. Dans mon programme je remplie ce int* et j'alloue dynamiquement la mémoire avec realloc et avec cette fonction (je stocke des coordonnées de point d'une image):

Code:

---

1 2 3 4 5 6 7 8

void CObjet::Add(int* point) { p = (int *)realloc(p, (nb_elt*2+2)*sizeof(int));   *(p+(nb_elt*2)) = *point; *(p+(nb_elt*2)+1) = *(point+1); nb_elt++; }

---

Ca marche très bien mais ca foire quand il y a trop de valeur à insérer dans le tableau (vers 12000 int). Il met en mode debug "Unhandled exception in X.exe : acces violation" et se plante après le realloc de trop.
C'est le pointeur p retourné par realloc qui vaut NULL, mais je ne comprend pas pourquoi !? Je n'ai quand même pas atteind la taille limite de mémoire ?

Merci d'avance


[Balises CODE rajoutées par Loulou24, merci d'y penser à l'avenir]

Hmm... On ne devrait plus voir ce genre de code en C++

http://c.developpez.com/faq/cpp/?page=STL#STL_vector

Merci, mais je viens d'essayer la et je retombe sur le même problème. En plus c'est carément plus long avec des vectors en temps d'excécution (ou alors je m'y prend mal)

Oui effectivement c'est bizarre, tu peux préciser ton environnement ?

Sinon je pense que tu t'y prends mal avec les vector, car ça ne devrait pas être plus lent. Au pire montre nous les bouts de code qui seraient plus lent, on pourra te donner un avis.

Je suis sous VC++ 6 et c'est un projet en mfc.
Donc ma fonction ajouter d'en haut donne ca :

Code:

---

1 2 3 4 5 6

void CObjet::Add(int* point) { p.push_back(*point); p.push_back(*(point+1)); nb_elt++; }

---

Je pense que c'est celle la qui fait tout ramer car j'y fais appel moulte fois pendant l'execution.
Et d'ailleurs j'ai une question en passant, un push_back ca rempli le tableau par la fin, mais est ce qu'il faut inverser l'indice entre [] quand on veut avoir accès à une valeur avec l'opérateur [] (quand on fait MonVecteur[i]) ?

Ah oui, j'ai essayé avec un pointeur sur des short int (2 octets au lieu de4 pour les int) et c'est exactement pareil .... :cry:


[Balises CODE rajoutées par Loulou24, merci d'y penser à l'avenir]

pour le code C realloc qui renvoie un pointeur NULL signifie sans doute que l'allocation a échoué.
serait-il possible qu'il y ait un problème de contiguité de la mémoire ?

:tagcode: http://arb.developpez.com/smileys/panpanculcul.gif

push_back va au pire faire un realloc comme tu le faisais, au mieux il ne fera qu'ajouter l'élément (la mémoire est allouée exponentiellement, càd pas à chaque fois). Donc difficile de se dire que c'est plus lent.

Pour ce qui est des indices... Forcément, si tu stockes un élément à la fin avec push_back il n'aura pas 0 comme indice.

Désolé pour les balises je ne recommencerai plus :oops:
Merci pour ces éclaircissements sur les vectors.
Mais expliquez vous que j'ai le même problème avec un pointeur de short int ? Normalement il devrait y avoir 2 fois moins de mémoire alloué qu'avec des int ? Mais le truc bloque toujours au même endroit (après 12000 coordonnées environ).
Et quand tu parles de contiguité de la mémoire, ca veut dire quoi exactement, que la mémoire est dispersée ?

Un vector ou un tableau dynamique classique alloue sa mémoire de manière contigüe. Donc s'il n'y a pas un tel espace contigüe disponible en mémoire, l'allocation echoue.
Mais ne pas avoir 48000 octets libres contigüs en mémoire, c'est tout de même rare...

Surtout que ça n'a pas l'air d'être lié à l'espace mémoire, mais plutôt au nombre d'éléments. Peut-être que l'erreur vient d'ailleurs ? Un ocmportement indeterminé qui viendrait empiéter sur ton espace mémoire ?

En fait je me demandais si ça venait pas du fait que le CObjet que je rempli (et qui explose la mémoire) est déclaré en variable globale (oui c'est pas top top mais je suis obligé de faire come ça). Est ce que ça change quelque chose dans le gestion de la mémoire ?

Non cela n'a a priori rien à voir, car même si ton CObjet est déclaré en global, le pointeur p lui pointe bien sur un espace alloué sur le tas.

Burk c'est pas beau un realloc....

Il faut remplacer par quelque chose d'autre, et penser autrement...

J'espère que tu ne mélanges pas new, delete et realloc...

Code:

---

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

// p doit être initialisé au départ à size_max void CObjet::Add(int* point) { nb_elt++; if(nb_elt>=size_max) { size_max*=2; // peut être remplacer par une valeur comme "size_max+=5000;"   int *t_p = new int[size_max]; memcpy(t_p,p,nb_elt); delete [] p; p=t_p; pt_p=p+nb_elt-1; // à vérifier si c’est bien -1 :) }   *(pt_p++) = *point; *(pt_p++) = *(point+1); }

---

Bon et bien c'est un code à vérifier je pense, mais tu devrais augmenter les performances et ne plus avoir de bugs.

Personnellement je préférais ce code-ci

Code:

---

1 2 3 4 5 6

void CObjet::Add(int* point) { p.push_back(*point); p.push_back(*(point+1)); nb_elt++; }

---

Mais apparemment cela n'a pas résolu le problème.

Disons que c'est plus propre, mais cela n'assure forcément pas la vitesse d'exécution..., si besoin de vitesse il y a... Dans le meilleur des cas, cela fait quasiment la même chose dans l’allocation, un coût supérieur pour l’accès, mais le parcours du tableau ne peut être que de vitesse inférieure de toute façon.

Enfin c'est le côté C de ma personne qui ressort :roll:

Il ne sert à rien de réinventer des roues qui ne résistent pas aux exceptions aujourd'hui :P

Citation:

---

Envoyé par Ti-R

Disons que c'est plus propre, mais cela n'assure forcément pas la vitesse d'exécution..., si besoin de vitesse il y a... Dans le meilleur des cas, cela fait quasiment la même chose dans l’allocation, un coût supérieur pour l’accès, mais le parcours du tableau ne peut être que de vitesse inférieure de toute façon.

Enfin c'est le côté C de ma personne qui ressort :roll:

---

Bah... Déjà comme le dit Luc ce sera bien plus fiable et sécurisé comme code. Ensuite, cela fera beaucoup mieux au niveau de l'allocation (la plupart des gens utilisent une stratégie de réallocation naïve -- en temps linéaire), et l'accès se ne se fera pas plus lentement (fonctions inlines). Pareil pour le parcours, un compilo qui optimise un minimum ne verra pas la différence.

Enfin bref, c'était juste pour dire... :D

Code:

---

1 2 3 4 5 6 7

void CObjet::Add(int* point) { p.push_back(*point); p.push_back(*(point+1)); nb_elt++; }

---

Je trouve que c'est pas terrible comme fonction... (Pointeur null, point[1] alloué ?, etc)

En C++, on définirait un type point et on paserait le paramètre par référence. (Apparemment, les deux éléments de ton tableau sont deux coordonnées.)

Code:

---

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

struct point {   int x, y;   point ( int a, int b ) : x(a), y(b) { }   }     typedef std::vector<point> CObject;   // Que l'on utilise simplement ainsi:   CObject a; a.push_back( point( 1, 5 ) );

---

Ceci a l'avantage d'être rapidement fait et de disposer de toutes les fonctions de la STL: itérateurs, algorithmes, etc.

Si std::vector n'est pas suffisant pour tes besoins et si CObject est intrinsèquement un conteneur, tu aura intérèt à faire dériver CObject de std::vector.

Ok merci tout le monde. J'ai pu (enfin !) résoudre mon problème.
Ce que j'ai fait c'est alloué au départ un gros tableau démesuré de short int au départ. Une fois rempli, je construit un nouvel objet en allouant cette fois la bonne taille de short int vu que je connais le nombre d'élément. Ensuite je libère la mémoire du gros tableau avec un delete. J'ai rencontré aussi un problème de stack overflow (à cause d'une fonction récursive) que j'ai résolu. Alors je sais pas si ca a joué dans mon problème de mémoire mais toujours est il que ca marche !!! :D :D :D :D :D
Selenite, j'avais fais ça au départ avec la classe point mais j'ai changé car je croyais que mon problème venait de ça. Mais je vais peut etre y revenir car c'est carément plus lisible !
En tout merci infiniment à tous ! :lol: