Réallocation dynamique qui ne marche pas?
Résolu
Mr zlem
Messages postés
23
Date d'inscription
Statut
Membre
Dernière intervention
-
Char Snipeur Messages postés 9813 Date d'inscription Statut Contributeur Dernière intervention -
Char Snipeur Messages postés 9813 Date d'inscription Statut Contributeur Dernière intervention -
Bonjour,
Je suis sur un code qui rempli un tableau (dynamique) avec des valeur entré par un utilisateur.
On suppose que l'utilisateur rentre plein de valeurs(genre des milliers).
Je ne sais donc pas la taille que va faire mon tableau c'est pourquoi il est dynamique.
J'utilise donc une boucle pour demander à l'utilisateur de rentrez sa valeur et j'agrandis mon tableau pour ajouter cette valeur.
Le problème c'est que je n'arrive pas à ré-allouer une 2 em fois, mon tableau.
La première fois ça marche mais pas la 2em. D'ailleurs 2em fois l'adresse de mon tableau vaux NULL. C'est très embêtant car mon tableau est perdu au moindre problème avec la fonction realloc.
Je vous donne un résumé de se que je veux faire; c'est du langage C :
/*initalisation tableau, malloc OK*/
taille=0;
do{
/*saisie utilisateur*/
tableau = realloc(tableau, sizeof(int) * taille);
tableau[taille];
taille++;
}while(/*fin de saisie*/);
Y a t'il une autre solution?
Je suis sur un code qui rempli un tableau (dynamique) avec des valeur entré par un utilisateur.
On suppose que l'utilisateur rentre plein de valeurs(genre des milliers).
Je ne sais donc pas la taille que va faire mon tableau c'est pourquoi il est dynamique.
J'utilise donc une boucle pour demander à l'utilisateur de rentrez sa valeur et j'agrandis mon tableau pour ajouter cette valeur.
Le problème c'est que je n'arrive pas à ré-allouer une 2 em fois, mon tableau.
La première fois ça marche mais pas la 2em. D'ailleurs 2em fois l'adresse de mon tableau vaux NULL. C'est très embêtant car mon tableau est perdu au moindre problème avec la fonction realloc.
Je vous donne un résumé de se que je veux faire; c'est du langage C :
/*initalisation tableau, malloc OK*/
taille=0;
do{
/*saisie utilisateur*/
tableau = realloc(tableau, sizeof(int) * taille);
tableau[taille];
taille++;
}while(/*fin de saisie*/);
Y a t'il une autre solution?
A voir également:
- Réallocation dynamique qui ne marche pas?
- Tableau croisé dynamique - Guide
- Exemple tableau croisé dynamique télécharger - Télécharger - Tableur
- Liste déroulante dynamique excel - Guide
- Sommaire dynamique word - Guide
- Liste déroulante dynamique en cascade excel - Guide
4 réponses
Tu peux par exemple construire un premier tableau de taille 101.
Si tu as remplis tes 100 cases, tu mets dans la 101è case un pointeur vers un nouveau tableau qui sera par de taille 1001, et dont la 1001è case pourra encore être un tableau...
Si tu cherches la valeur 995, tu vas regarder la case 101 pour te déplacer sur le tableau et ensuite aller à la case 895.
C'est une façon parmi d'autres ;-)
Si tu as remplis tes 100 cases, tu mets dans la 101è case un pointeur vers un nouveau tableau qui sera par de taille 1001, et dont la 1001è case pourra encore être un tableau...
Si tu cherches la valeur 995, tu vas regarder la case 101 pour te déplacer sur le tableau et ensuite aller à la case 895.
C'est une façon parmi d'autres ;-)
http://www.linux-kheops.com/doc/man/manfr/man-ascii-0.9/man3/realloc.3.txt.html
il est préciser que le pointeur est conservé si realloc échoue.
Donc :
int* tmp;
...
tmp=realloc(tableau,sizeof(int)*taille);
if(tmp!=0) tableau=tmp;
ainsi tu conserve tes données en cas d'échec, mais attention à la taille. Tu peux aussi regarder la valeur de errno en cas d'échec pour voir ce qui cloche.
La solution de KX me parait assez compliqué à réaliser. Mais à la rigueur, je la conserverait mais lui donnerai une forme de liste chainée:
il est préciser que le pointeur est conservé si realloc échoue.
Donc :
int* tmp;
...
tmp=realloc(tableau,sizeof(int)*taille);
if(tmp!=0) tableau=tmp;
ainsi tu conserve tes données en cas d'échec, mais attention à la taille. Tu peux aussi regarder la valeur de errno en cas d'échec pour voir ce qui cloche.
La solution de KX me parait assez compliqué à réaliser. Mais à la rigueur, je la conserverait mais lui donnerai une forme de liste chainée:
struct liste
{
int taille;// taille réelle occupée
struct liste* suivant;
int tableau[100];
}Ensuite, tu fais des fonctions pour remplir cette liste et accéder à un élément.
Salut ...
C'est plus pratique d'utiliser les listes chaînés ... en gros, tu utilisera juste l'espace dont t'aura besoin, et non pas créer des tableaux au hasard et de tailles maximum, et que probablement l'utilisateur n'utiliserait même pas ...
a+
Mettez en résolu quand c'est résolu -.- ...
C'est plus pratique d'utiliser les listes chaînés ... en gros, tu utilisera juste l'espace dont t'aura besoin, et non pas créer des tableaux au hasard et de tailles maximum, et que probablement l'utilisateur n'utiliserait même pas ...
a+
Mettez en résolu quand c'est résolu -.- ...
Si tu mets 1000 valeurs, avec des listes tu auras 2000 éléments (1000 valeurs et 1000 pointeurs de liste), avec le code de CharSniper tu en auras 1020 (1000 valeurs et 20 pointeurs de liste)
C'est d'ailleurs une méthode assez utilisé par exemple dans les string en C++ où il y a une différence entre la taille et la capacité de la chaîne de caractères (c'est à dire l'espace utilisable sans avoir à réallouer une nouvelle liste)
C'est d'ailleurs une méthode assez utilisé par exemple dans les string en C++ où il y a une différence entre la taille et la capacité de la chaîne de caractères (c'est à dire l'espace utilisable sans avoir à réallouer une nouvelle liste)
Si tu sais que tu va utiliser 1000 cases, et seulement 1000 cases d'un tableau, alors la, c'ets juste, mieux vaut utiliser les tableaux que les listes ...
Disons que je déclare mon tableau de 1000 lignes, et que je n'utilise que 100 cases de ce dernier, alors 900 cases ont été crée pour rien, alors qu'avec les listes, si j'ai besoin de 100 cases, seulement 200(100*2) éléments seront crée ...
D'ailleurs dans le chapitre "Listes chaînées" des cours, lors de l'introduction a ce dernier, on nous pose la question "Si vous ne connaissez pas la taille maximum de votre tableau ?", et la réponse est "...On utilise les liste chaînées" ...
Appart ça, c'est pas la mémoire qui manque de nos jours. :)
Disons que je déclare mon tableau de 1000 lignes, et que je n'utilise que 100 cases de ce dernier, alors 900 cases ont été crée pour rien, alors qu'avec les listes, si j'ai besoin de 100 cases, seulement 200(100*2) éléments seront crée ...
D'ailleurs dans le chapitre "Listes chaînées" des cours, lors de l'introduction a ce dernier, on nous pose la question "Si vous ne connaissez pas la taille maximum de votre tableau ?", et la réponse est "...On utilise les liste chaînées" ...
Appart ça, c'est pas la mémoire qui manque de nos jours. :)
Sauf que si tu n'utilises que 100 cases, avec le code de CharSniper, ça te fera toujours que 102 éléments, pas 200... Dans le pire cas, on prend 101 cases, qui nécessite 204 éléments contre 202 avec une liste chainée, mais c'est vraiment le seul cas car pour 201, on aurait 306 contre 402 et on y gagnerai encore !
Il ne faut pas perdre de vue non plus la complexité des méthodes. Si tu veux accéder à la 995è cases, il faudra parcourir 995 éléments de ta liste chaînée contre 9 pour celle de CharSniper (le temps d'accéder au 9è tableau, l'élément 95 s'obtient alors directement)
Donc utiliser des listes chaînées avec une seule case par cellule c'est lourd en mémoire, et en temps. Alors qu'utiliser des tableaux dans les cellules permet de mieux contrôler ces deux contraintes.
Certes aujourd'hui on a de plus en plus de mémoire, et des processeurs de plus en plus rapides, mais si on gaspille ces ressources où est l'intérêt ?
Il ne faut pas perdre de vue non plus la complexité des méthodes. Si tu veux accéder à la 995è cases, il faudra parcourir 995 éléments de ta liste chaînée contre 9 pour celle de CharSniper (le temps d'accéder au 9è tableau, l'élément 95 s'obtient alors directement)
Donc utiliser des listes chaînées avec une seule case par cellule c'est lourd en mémoire, et en temps. Alors qu'utiliser des tableaux dans les cellules permet de mieux contrôler ces deux contraintes.
Certes aujourd'hui on a de plus en plus de mémoire, et des processeurs de plus en plus rapides, mais si on gaspille ces ressources où est l'intérêt ?