Bonjour,
 
je voudrais savoir comment faire pour allouer un tableau dynamiquement lorsque l'on doit augmenter la taille d'un tableau au fur et à mesure des besoins.
 
Merci

malloc et realloc

mais bon un tableau c'est pas dynamique par définition

Bonjour,
 
Est-ce que quelqu'un pourrait m'écrire un exemple pour que ça me serve de model ?
 
Merci

int * tab;
tab = (int*) calloc (10,sizeof(int));
 
alloue un tableau de 10 cases de la taille d'un entier

+ realloc pour changer sa taille

pour répondre très précisément au titre :
 

ouai, voila une allocation dynamique d'un tableau
 
a mon avis Gattuso voulais plutot savoir comment on peut faire si la taille du tableau est inconnue à la compilation et qui peut en plus changer au cours de l'execution

Pour compléter la réponse de Taz, un type d'utilisation pourrait-être :
Lecture de ligne dans un fichier(ce n'est pas la taille du buffer de lecture qui est l'intérêt ici, ni non plus,  
le fait de virer le '\n' à la fin de la ligne)
 

Ah ? Il n'existe pas de tableaux dynamiques, selon toi ?
 
Intéressant. Tu peux développer ?

Pourquoi le cast ? Assure toi plutôt que <stdlib.h> est bien inclus.
 
http://mapage.noos.fr/emdel/notes.htm#malloc
 

 
c'est un bloc mémoire que tu alloues enfin bin c'était histoire de faire le lourd  

Et un tableau, c'est pas un bloc mémoire ? C'est quoi alors ? Un bloc de glace ?
 

bon allez spa grave
(dla glace à la poire avec de la bannane flambée)

question stupide (j'ai la flemme de tester aussi!)

Si 'p' pointe vers une zone memoire contenant deja des données, ces données sont elle recopiées automatiquement dans tmp lors de la reallocation ou c'est a nous de reremplir?
 
Si elle ne sont pas recopiés, quel est l'interet du realloc par rapport a un second appel a malloc/calloc?

tout ca est dit dans la doc    
 

 
tu veux faire de la retro ingenierie sur une fonction documentée ?
 

 
ca veut dire quoi ?

Ah oui effectivement c'est dans la doc, j'avais mal lu desolé.
il y a conservation des données si taille realloc superieure et tronquation des données sinon.

Aucune donnée n'est copiée dans tmp. Uniquement l'adresse du nouveau bloc alloué.

En fait, on peut n'utiliser que realloc. Si le pt passé à realloc est NULL, le realloc fait lui-même le malloc initial...
 

Ben aucun donc forcément elles sont recopiées. Mais si elles n'étaient pas recopiées (ou si realloc n'existait pas), on pourrait quand-même faire du stockage dynamique d'éléments en utilisant une liste chaînée évidemment plus lourd (j'en connais qui font ça )
 

Tiens ? Je croyais que realloc ne faisais rien si la nouvelle taille était inférieure à l'ancienne pour optimiser ?

 
Totalement dépendant de l'implé

Merci    

C'est malheureusement le cas dans des langages comme Fortran90  

 
Fortran90, langage ?  

 
le cas de quoi ? tu peux etre plus precis ?

En fortran90, il y a des fonctionalités d'allocation dynamique (en gros un équivalent de calloc), mais on ne dispose malheureusement pas d'un équivalent de realloc. Donc si tu veux faire du stockage dynamique les deux possibilités sont :
1- quand tu débordes, tu alloues un nouveau tableau plus grand, tu copies les valeurs et tu désalloue le premier tableau
2- tu implémentes une liste chainée ou une variante du même genre (par exemple j'utilise des liste chainées de tableaux de 1000 éléments pour éviter d'avoir trop d'allocations dynamiques tout en ne surdimensionnant pas trop la place utilisée)
 
inutile de préciser que la première méthode est plus facile à implémenter mais pas terrible niveau performances.

 
oui, ok, mais c'est loin d'etre specifique à fortran 90, c'est le cas dans tout les langages.
 
En générale on choisie la premiere solution avec une strategie de reallocation pour eviter de reallouer à chaque demande d'agrandissement de la zone memoire, c'est ce que fait realloc en C dans ton dos (mais les details dependent de l'implementation, on sait juste que realloc n'implique pas un deplacement de la zone memoire) et std::vector en C++. Fortran 90 n'offre pas ce support intrinsequement mais tu peux toujours le developper toi meme (a moins qu'il existe une bibliotheque qui le gere).
 
En ce qui concerne le choix d'une liste chainée, il y a beaucoup d'autre facteur à considérés, autres que la vitesse d'ajoue d'element en fin de sequence (le choix d'un type de conteneur c'est un autre probleme).

 
??

Je sais bien. Je  ne dis pas que c'est spécifique à F90, c'était juste pour donner un exemple de langage qui ne fournit pas de realloc.
 

Effectivement on peut toujours réimplémenter des fonctionnalités semblables à realloc (comme dans la solution 1). La différence avec le C c'est qu'en fortran tu es *toujours* obligé de recopier tes données. Il n'y a pas à ma connaissance de bibliothèque qui gère ce genre de chose mais c'est de toutes façons assez simple pour pouvoir être réimplémenté à la main au cas par cas.
 

Dans le cas qui me concerne, je n'utilise une liste chainée que temporairement. Lorsque j'ai fini de remplir toutes les valeurs, je recopie la liste dans un tableau. Ceci me permet de disposer ensuite d'un espace mémoire contigu pour faire des calculs efficaces.

Ben non. Pourquoi realloc() retournerait-il une adresse si c'était vrai ?
 

Il me semble bien (comme skelter, si j'ai bien compris) que realloc ne déplace pas toujours la mémoire. S'il est possible d'allouer l'espace supplémentaire juste derrière le tableau déjà alloué, il me semblait que realloc se contentait juste d'allouer cet espace et de laisser la première partie du tableau en place (en renvoyant l'adresse inchangée). Il est quand même nécessaire que realloc() renvoie un pointeur pour le cas où il y a quand même eu un déplacement.

oui,
 

 
je faisais la négation de "implique un deplacement" qui est fausse, enfin peut etre que c'est mal dit  

Non.
Il ne le fait que s'il a à le faire.
D'ailleurs, il est amusant de noter qu'il peut déplacer les données même lorsqu'on réduit la taille.
 

Aïe.
Ce n'est pas un tableau qui est alloué, c'est une zone de mémoire.
 
Un tableau n'a rien à voir avec un pointeur sur une zone allouée par malloc, si c'est ce que tu sous-entends.
 
Par exemple, tu obtient la taille dun tableau par sizeof(tab)
Si tu fais ça sur un pointeur, il va te renvoyer la taille du pointeur, soit généralement 4 byte.
Y'a pas de façon portable de récupérer la taille du bloc alloué.

 
c'est bien ce que franceso dit    
 

 
detail d'implementation, par exemple si malloc gere de facon differente les petites allocations et les grandes allocations le passage d'une tranche à l'autre peut entrainer un deplacement meme si ce n'est pas necessaire. (pas sur)

Je pense qu'il voulait signifier "n'implique pas forcément...".
De toute façon, malloc dépend de la stratégie de gestion mémoire par l'OS, donc c'est forcément dépendant de l'implémentation.