Version imprimable
Bonjour à tous,
dans le cadre d'un projet, j'utilise à plusieurs reprises des tableaux de chaînes de caractères, qui n'ont pas de tailles prédéfinies. Le mieux serait que leurs tailles dépendent du besoin. Mais j'hésite entre utiliser un realloc (qui pourrait etre couteux en appel systeme, etc?) ou définir une taille maximale, donc élevée (auquel cas on réserve souvent une mémoire qui ne sera pas utile)...
Qqun saurait ce qui est le mieux à faire?!
Merci d'avance.
L.
Salut,
Le meilleur moyen que j'ai vu, est de doubler la taille allouée quand la taille initiale est trop petite, tout en ayant une taille de début suffisante pour les cas les plus courants.
Taille de départ 250
Chaine de 251 -> doubler la taille avec realloc -> 500
Chaine de 501 -> 1000
Etc
ah oui... c'est bien pensé ça :)
Bonjour,
8O
Si tu connais la taille de ta chaine et que tu fais un realloc, alors autant faire un realloc ajusté à la bonne taille !!!!!!Citation:
Envoyé par KiLVaiDeN
Ca me parrait évident, si c'était trop simple je ne pense pas qu'il aurait posé la question :)Citation:
Envoyé par ToTo13
J'imagine qu'il parse un fichier ou autre, et qu'il génère une chaine dynamiquement, en tout cas c'est ce que j'ai imaginé..
he bien, c'est simple:
j'ai besoin d'un char** tab_chaines pour un tableau de chaines.
Mais je ne sais pas à l'avance cb je vais y ranger de chaines (mais qd je les range, je connais la taille des chaine donc pas de pb pr le malloc du tab_chaine[n]). Le pb c le malloc du tab_chaines. Si je n'ai plus assez de place il faut bien que je réalloue, donc je pense que doubler à chaque fois est une bonne idée oui...
(au fait, je sais que c'est rare ici mais c'est "elle" :) )
Question : pourquoi ne sais-tu pas combien de chaines tu vas y ranger dès le départ ?
PS : Désolé pour l'erreur, Mademoiselle ;)
ben par exemple ds la cas ici présent, je liste le contenu d'un répertoire, et je place les noms de fichiers ds le tableau...
oui bon, ici je le connais, pas initialement mais je peux faire un realloc avec le bon nombre d'element (valeur retour de scandir)
MAIIIIIIIIS
dans d'autres cas... je ne le connais pas:
exemple: lister des arguments entrés par un utilisateur au clavier.
En effet, le realloc() est necessaire dans ton cas. L'idee est d'un faire le moins possible, pour des raisons de performance et de fragmentation de la memoire. C'est pourquoi doubler la taille est une bonne solution.
merci bien..
dernière question: une fonction qui reçoit en argument un char** tab_chaines ne peut pas modifier (ici réallouer donc) ce tab_chaines?
Non, garde en tête que tout paramètre ne peut pas être modifié par une fonction C (du moins, ce ne sera pas visible de la fonction appelante).Citation:
Envoyé par ellow
On peut modifier la valeur de la zone pointée (dans le cas de pointeurs) ou les éléments d'un tableau mais c'est tout.
Ainsi, tu pourrais appeler un realloc sur le pointeur mais la nouvelle valeur ne serait pas prise en compte par la fonction appelante (à moins de retourner la nouvelle addresse).
Jc
Il faut lui envoyer un char ***tab - c'est un niveau d'indirection un peu eleve, il faut bien l'admettre. J'avais ecrit une fonction similaire a la tienne, et j'avais mis tous les noms de fichier a la queue-leu-leu dans un char *tab, separes par des '\0'. On bouclait sur le contenu de ce tableau a coup de strlen()... C'est moins efficace qu'un char **tab, mais on ne se perd pas dans les indirections.
oui, ça me parait moins lourd aussi...
en tt k merci pr vos réponses
c'est rapide ici !
Le probleme, c'est que c'est moins facile d'utilisation. Pour afficher le contenu d'un repertoire, par exemple, au lieu deCitation:
Envoyé par ellow
on doit faireCode:
2
3
4
5
6
7
8
9
10
11
Mais on peut toujours cacher les details dans une fonction display_directory()...Code:
2
3
4
5
6
7
8
9
10
11
12
13
moi j'utilise scandir, et y'a pas de pb pr lister ni afficher ...
sauf que là je commence à péter à énorme cable..
voici la part de code qui semble poser pb:
Avec: ist_file un char* initialisé à NULL, retour le nombre de fichiers listés dans le répertoire concerné (renvoyé par scandir), et [I]namelist->d_name le nom du fichier listé...Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
MAIS! déjà j'ai un seg fault incurable (enfin, je l'espère pas) et voici ce qui s'affiche:
(j'affiche file_list au fur et à mesure de sa construction juste pr voir ce que ça donne );
list_file=libShell.o
list_file=libShell.olibStack.o
list_file=libShell.olicStack.oline.o
list_file=libShell.olicStack.oline.oliste.o
list_file=libShell.olicStack.oline.oliste.opile.o
Segmentation fault
bon alors, le segfault, je pense pvr y remédier, mais le fait que "libStack.o"se transforme en "licStack.o" là je n'vois pas c'qui peut bien spasser ..
oui bon prr le realloc c'est pe mieux: list_file = (char*)realloc( list_file, size_name ); mais ça ne change rien à rien :(
Tu ne fais que changer la taille de ton tableau de caractere en fonction de la longueur du nouveau fichier. Il faut augmenter la taille et utiliser strncpy(), pas strncat() [afin d'include le '\0' terminal]).
Ensuite, il faut verifier le retour de malloc() et realloc(). Dans ton exemple, si realloc() echoue, tu provoques une fuite memoire (le list_file original n'est pas libere mais sa valeur est perdue). Il faut utiliser une variable temporaire. Enfin, on ne caste pas le retour de malloc() et realloc() en C (en C++, oui).
aha! tout le problème vient de mon realloc (évidemment quand on lit mal les pages man, on ne risque pas d'aller bien loin). Je pensais que le nombre à passer à realloc était la taille du bloc qu'on rajoutait à la fin de celui déjà alloué... Bref, j'étais à coté de la plaque.
1000 merci