Discussion :

[diFaenza]

Hello les geeks :-),

Je tente de créer un tableau dynamique de structure.
Il est définit ainsi:

Code :

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

1
2
3
4
5
6
     struct TFile
     {
         signed long Index;
         AnsiString Name;
         int Attribute;
     };

Il est déclaré ainsi :

Code :

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

     TFile *Files

Lorsque j'en modifie la dimension par:

Code :

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

1
2
3
     if ((Files=(TFile *)realloc(Files,Number*sizeof(TFile)))==NULL)
 
// Number = le nombre de struct TFile dans le tableau Files

il ne renvoie jamais de pointeur NULL mais crashe de temps en temps des TFile dans le tableau Files
J'en déduis que mon allocation de mémoire est foireuse mais je ne comprends pas pourquoi.

Merci de m'aider (et non, je ne suis pas tenté par std::vector, je voudrais plutôt comprendre que contourner le problème )

[Fiquet]

Ton code est un code C. En C++ on n'appelle jamais les fonction malloc(), realloc(), free(), etc. Si vraiment tu veux gérer des tableaux dynamiques toi-même fais-le avec new et delete, y compris pour la réallocation (il n'y a pas d'équivalent à realloc() en C++).

(et non, je ne suis pas tenté par std::vector, je voudrais plutôt comprendre que contourner le problème )

Ce n'est pas contourner le problème, juste utiliser la bibliothèque standard au même titre que toi tu utilises des fonctions comme realloc par exemple .

[Médinoc]

En plus, c'est du Borland (AnsiString, TFile...)

PS Fiquet: Par "Il n'y a pas de realloc() en C++", tu viens d'expliquer pourquoi diFaenza emploie malloc(). realloc() est beaucoup plus économique que new/copy/delete, tant en performances qu'en efforts.

Par contre diFaenza, realloc() est très mal utilisé:

1. On ne doit jamais remettre directement la valeur de retour de realloc() dans le pointeur d'origine, car si realloc() retourne NULL le pointeur est toujours valide.
2. Tu utilises des transtypages de type C au lieu d'utiliser static_cast<>().

[diFaenza]

Tout d'abord, où est le problème avec le Builder de Borland (il transmet des MST, le cholera ou il finance le terrorisme ? ;-) )

Mais revenons à mes angoisses diurnes

je garde

Code :

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

1
2
3
4
5
6
7
8
struct TFile
{
     signed long Index;
     AnsiString Name;
     int Attribute;
};
 
TFile *Files;

et je le newise avec

Code :

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

Files= new TFile[Number];

// Number = le nombre de Files dans mon tableau de Files
Jusque là, no problemo, je joue avec et il hoche la queue.

Mais lors du licenciement

Code :

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

delete [] Files;

il fait son vilain et mord.

Où est ma faute?


balises [code] rajoutées par r0d. Merci d'y penser dorénavant.

[koala01]

Salut,

D'abord, il faut se ménager une "porte" de sortie quand tu utilises new (pas de réallocation possible, cela veut dire: garder l'ancien pointeur, copier les valeurs, et libérer l'ancien pointeur)

Ton code doit donc etre du genre de

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
// déclaration de Files (utilisé réellement)
FTile *Files=NULL;
(...)
// création d'un nouveau tableau temporaire
TFile *tempo;
if(!(tempo=new TFile[nouvelle_taille]))
     throw std::bad_alloc("erreur d'allocation");
/* si on a déjà un tableau de TFile, il faut le recopier dans le tableau temporaire */
for(unsigned int i=0;i< ancienne_taille,i++)
{
     tempo[i]->index=File[i]->Index;
     tempo[i]->Name=File[i]->Name;
     tempo[i]->Attribute=File[i]->Attribute;
}
// Maintenant, il faut libérer la mémoire réservée pour File 
delete[] File;
//Et donner a File l'adresse du tableau tempo
File=tempo;

Ceci dit, en espérant te convaincre... Ne trouverais tu pas plus simple un code basé sur

Code :

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

1
2
3
4
5
6
7
 
std::vector<TFile> Files;
//Ajout d'un TFile
File.push_back(lenouveau);
//suppression d'apres l'index)
std::vector<TFile>::iterator it=Files.begin()+index;
Files.remove(it);

[Invité]

di Faenza, ouvre un peu ton esprit; on ne cherche pas a s'opposer a toi, ou te prend la main pour te ramener sur le droit chemin

si tu codes en C++, alors utilise le jusqu'au bout. la bibliotheque standard n'est pas la pour que des intellectuels se possent des questions philosophique sur le bien fondé de son origine. la STL est rodée, elle marche bien, et est la justement pour éviter les fuites de mémoires si faciles à faire avec des allocations dynamiques manuelles...

[Luc Hermitte]

Je tente de créer un tableau dynamique de structure.

Pas vraiment une structure au sens POD du terme. Ta struct contient une AnsiString qui est une classe. En conséquence ta struct est à 100% une classe et à 0% une donnée POD. De fait, tu ne peux pas allouer de TFile avec les fonctions de la famille *alloc du C. Tu oublies donc realloc au passage. Il ne faut pas chercher plus loin si ça plante.

std::vector est LA solution du C++ à ce que tu cherches à faire.

(En vrai, il est toujours possible de feinter avec les new de placement (ce que fait vector en interne), mais tu vas avoir d'autres bases à assimiler avant)



Concernant la question suivante. Si tu plantes entre le new[] et le delete[], c'est que ton programme a fait le cochon sur la mémoire allouée entre ces deux lignes.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
FTile *Files=NULL;
(...)
// création d'un nouveau tableau temporaire
TFile *tempo;
if(!(tempo=new TFile[nouvelle_taille]))
     throw std::bad_alloc("erreur d'allocation");
/* si on a déjà un tableau de TFile, il faut le recopier dans le tableau temporaire */
for(unsigned int i=0;i< ancienne_taille,i++)
{
     tempo[i]->index=File[i]->Index;
     tempo[i]->Name=File[i]->Name;
     tempo[i]->Attribute=File[i]->Attribute;
}

A moins que le BCB utilisé soit aussi à l'ouest que les vieux VC, new est sensé lever une exception par défaut. Pas null s'il n'y a plus de mémoire.
Accessoirement, si l'affectation de l'AnsiString est refusée, une exception partira et de la mémoire sera perdue avec le code montré.
Conclusion, c'est bien les vecteurs.