Dites c'est très laid ça ?
 

 
ca marche po ..
 
j'obtiens :
 
E:\BTS\pti\greper\grep.c(137) : warning C4101: 'TotalOccur' : unreferenced local variable
E:\BTS\pti\greper\grep.c(147) : warning C4700: local variable 'temp' used without having been initialized

Pour moi c'est correct.
 
Seul problème, le type de TotalOccur ne peut plus être utilisé pour d'autres créations de variables.
 
warning1: tu ne te sert pas de ta variable
warning2: ça doit concerner autre chose

Les tableaux de structure c pas forcément top d'u npoint de vue place mémoire (gros enplacement contigü utilisé). Mieu vaux le tableau de pointeur vers des structures à mon avis. si non la déclaration est bonne.

 
et ça donne quoi ce que tu dis ?
 
En fait ji réécris la chose ...
 
 typedef struct {  
 char* table;  
 double occur;  
} TotalOccur;
 
TotalOccur TabTotalOccur[2000];
 
donc ça c'est nickel ?
 
 
 
MErci

J'écrirai plutôt:

 
Et quand tu veux rajouter une structure dans ton tableau:
 

 
Ne pas oublier de libérer la mémoire ensuite:

pas besoin de se prendre la tete autant.
 

 
Pour le free j'ai un doute

Quel doute?

 
 
free(tab); c'est faux!!!!  
 
faut parcourir chaque case de ton tab et freeer chaque cases  
mais avant de freeer la case pas oublier de freeer son contenus (style le char *)  
 
la tu free que la 1er case de ton tableau (meme pas con contenus et tu zap 19999 elements (qui eux sont encore la)
 
fuites memoire POWWWAAAAA
 
et le 2000 ca aussi c'st coton pour les fuites memoires (je sait qu'a lheure actuel nos pc sont bourés de ram) mais c'est pas un raison pour faire du mass malloc
 
par contre pour le C++ je sait pas si le delete sufit ...ou faut il faire comme le c freer toute les structures + contenus  avant (ca devrais aps si ses destructeurs son ok mais bon )

koulip31 a écrit a écrit :       free(tab); c'est faux!!!!     faut parcourir chaque case de ton tab et freeer chaque cases   mais avant de freeer la case pas oublier de freeer son contenus (style le char *)     la tu free que la 1er case de ton tableau (meme pas con contenus et tu zap 19999 elements (qui eux sont encore la)   fuites memoire POWWWAAAAA   et le 2000 ca aussi c'st coton pour les fuites memoires (je sait qu'a lheure actuel nos pc sont bourés de ram) mais c'est pas un raison pour faire du mass malloc

 
FAUX.
 
Il alloue l'espace pour 2000 structures disposées de façon contigue en mémoire, et place un pointeur vers cet espace dans tab.
 
Lorsqu'il fait free(tab) il libère TOUT cet espace.

 
 
C'est la que j'ai un doute.

Faire un free su chaque unité était nécessaire que s'il avait fait:
 

 
Car là pour chaque case du tableau il devrait faire:
 

koulip31 a écrit a écrit :

 
thooo jai capiche  
 
(c'est comme pour une string la koi )  
c'est dut a son tab[300]  
 
mais les char * de ses struct eux faut bien les freer???

Moi j'ai pas de doute et si je me plante c que j'ai mal lu et qu'il fait pas ce que je pense.

Par contre c un delete[] qu'il doit faire dans la version c++ (faute de frappe sans doute).
 

pour le C faut bien quil free ses strings avant (car en fesant un free tab) il vas detruire le tableau mais pas son contenus  
 
surtout le char *

Pour le delete[]    
 
Pour le tab je sais plus, j'utilise que des listes chainees (ou la faut freer link par link)

Voyons voir...
Taille du pointeur: 4 octets
Taille du double: 8 octets
Taille de la structure: 4+8=12 octets
Taille d'un tableau de 2'000 structures: 2'000*12 = 24'000 octets, soit 23,4375 Ko.
 
Oulàla... c'est que je ne sait pas si ça tient dans la mémoire du PC, qui doît être au moins de 32 Mo, soit 33'554'432 octets.
Sans parler du risque d'épuiser l'espace d'adressage vituel limité à 4 Go (soit 4294967296 octets) sur nos pauvres machines 32 bits.
 
Avec la solution d'un tableau de pointeurs sur des structures allouées par new, on rajoute pour chaque structure crée un pointeur (4 octets), plus ce que new mémorise pour s'y retrouver (au moins un int), plus les risques de bogues accrus, plus un ralentissement de l'exécution...
Franchement, ça ne servirait à rien !
 
 

Pour que ce soit libéré, il suffit de doter la structure d'un destructeur, c'est fait pour ça.
Et comme un char* n'a pas de destructeur, il est logique que ce qu'il pointe ne soit pas libéré.
 
Un peu de bon sens, quoi !

 
sauf rien indique que c du C++ dans lexemple de base (pas les solution apporte)
et moi quand je free un tablea j'ai lhabitde bien le freer (sans laisser de char *)  
mis bon c'ettais une question a part

 
Ouai un destructeur en C bravo, quant à la mémoire le jour où il bossera avec des données plus volumineuses ou sur une bécanne un tant soit peu chargée d'un point de vue mémoire le tableau de pointeur sera peut être bien apréciable.

Pardonnez-moi, j'avais perdu de vue que c'était du C.
Tout ces malloc et free m'ont fait irrésistiblement penser à new et delete.
Le problème de la surconsommation de mémoire reste le même...
 
Pour des tableaux plus grands je dis pas...
Mais là, ce serait vraiment du masochisme !

J'oubliais de dire :
Si on a des allocations/désallocations bien complexes, je trouve que les constructeurs/destructeurs du C++ sont très bien pour s'en occuper.

C'est aussi mon avis:
Pour les tableaux plus grands, soit ils sont creux et il y a des algos adaptés, soit ils occupent de toute facon autant de memoire, simplement au lieu d'avoir adressé une zone virtuelle contigue de grande taille, on adresse de multiples zones plus petites, mais c'est exactement ce qu'un allocateur bien foutu va faire dans le premier cas.  
L'interet d'un tableau de pointeurs serait la si on ne savait pas la borne du tableau, et qu'on alloue par tranches de n structures au fur et a mesure des besoins.
A+,

Et puis même si on a un très grand tableau...
 
On a la mémoire virtuelle qui s'en occupera très bien si on n'accède pas à tout en même temps.

 
Pourquoi faire une allocation memoire de 2000x la structure à la place de TotalOccur tableau[2000] ?
 
Au moins avec le tableau déclaré dés le départ y'a pas de problème, on est sûr qu'il sera bien créé. (Ca fait pas mal de temps que je fais du C et je me suis aperçu que plus y'a de "malloc" dans un programme plus y'a de "coredump" !!! alors des que je peux eviter j'evite (Quand je connais la taille et la quatite des donnees bien sûr)).

J'aurais plutôt mis ça sur le compte des free, moi...

A+,

 
Mouai, la grosse raison pour faire ça plutôt qu'une allocation dynamique c plutôt que new ou malloc c vachement lent, donc si on a besoin de vitesse vaut mieux éviter.

euh dites juste une question la, ca fait combien de temps que vous faites de la programmation(c pas pour me vanter mais au contraire parce que je suis impressionné)
merci de me repondre.

bailly33: Tu as posé la question beaucoup d'endroits ?
Tu peux en faire un topic séparé, c'est plus poli et mieux pour ceux que ça intéresse aussi.

gilou a écrit a écrit :   J'aurais plutôt mis ça sur le compte des free, moi... A+,

 
Euh ben c'est les deux en fait mais j'ai déjà quelques prolèmes avec des mallocs (ils étaient plus nombreux que les frees ... et à la fin une variable qui n'avait rien demandee etait effacee malgré elle).