malloc et piles - C - Programmation
Marsh Posté le 08-10-2004 à 21:49:07
En fait, quand y'a plus assez de place dans la pile, je ralloue un
tableau plus grand dans ma pile. je copie l'ancien avec memcopy,
et la certains des chiffres deviennent fous !
Sinon tous les reste marche. compren pa...
Marsh Posté le 08-10-2004 à 21:51:25
p.v = (Nat*) malloc (n * sizeof(Nat));
pas besoin de cast
du reste tout ça c'est bien mais c'est quoi n ?
memcpy(nouveauTableau, p.v, p.h);
-> memcpy(dest, source, quantité)
quantité est exprimé en 'char'
donc ce n'est pas 'p.h', mais 'p.h * sizeof(Nat)'
voir 'p.h * sizeof *p.v' si tu veux faire propre
Marsh Posté le 08-10-2004 à 21:51:56
oula ca fuis tout ca,
et utilise realloc qui gere ca a ta place
ne cast pas inutiliment memcpy et malloc et ca sort d'ou n dans pilenouv ?
Marsh Posté le 08-10-2004 à 21:54:26
ta pas trouvé mieux (et surtout plus unique) comme nom pour ta macros ?
Marsh Posté le 08-10-2004 à 21:54:54
Taz a écrit : |
merci d'avoir répondu si vite, et qui plus est,
correctement !
ca marche nickel.
Merci
Marsh Posté le 08-10-2004 à 21:56:18
cris56 a écrit : ta pas trouvé mieux (et surtout plus unique) comme nom pour ta macros ? |
bah c le prof qui veut ses trucs a lui.
Je sais, c débile, genre vo mieux un truc du genre TAILLE_BUFFER
ou je ne sais quoi.
Je suis les ordres, c'est tout
Marsh Posté le 08-10-2004 à 21:58:05
oui, mais surtout ça sert à rien, sauf à rendre illisible une opération de routine comme un malloc ou un memcpy
Marsh Posté le 08-10-2004 à 22:04:27
il manque toujours un free dans empiler
memcpy(nouveauTableau , ... );
free( p.v );
p.v = nouveauTableau ;
Marsh Posté le 08-10-2004 à 23:27:59
cris56 a écrit : il manque toujours un free dans empiler |
Je pensais que si rien ne pointait sur une zone,
yavait comme un garbage collector quil le libere tout seul.
Pas en C alors ?
edit: taz > c'est clair, realloc, c'est bien plus beau.
Marsh Posté le 08-10-2004 à 23:29:01
je crois que tu ferais bien te renseigner sur l'histoire du C et sur pourquoi le C a été conçu.
Marsh Posté le 08-10-2004 à 23:29:22
ReplyMarsh Posté le 08-10-2004 à 23:36:16
j'ai un peu de mal a comprendre: pourquoi tu n'alloues pas dynamiquement un espace mémoire à chaque empilage? (et désalloue au dépilage)
en fait c'est pas une pile que tu fais là, c'est juste un tableau
Marsh Posté le 08-10-2004 à 23:37:35
Taz a écrit : pour justement ne pas avoir à le faire à chaque fois. |
Oui mais c'est pas une pile
-> meumeul
tu peux aussi remplacer
p.v[p.h]= x;
p.h++;
par p.v[p.h++] = x;
Ah oui et comment il détermine que la pile est pleine après le 1er resize?
Marsh Posté le 08-10-2004 à 23:39:54
Masklinn a écrit : |
aucun intérêt sauf dégrader la lisibilité, déjà mauvaise avec des membres '.v' et '.h'
Marsh Posté le 08-10-2004 à 23:43:43
Taz a écrit : aucun intérêt sauf dégrader la lisibilité, déjà mauvaise avec des membres '.v' et '.h' |
pas faux
mauvais point donc
mais il me reste le (gros) problème de déterminer si la pile est pleine (vu qu'il ne conserve pas la taille allouée de la pile )
et le fait que ca soit pas géré comme une pile FILO (je présumme que c'est ce à quoi il veut arriver, parce qu'une FIFO avec son implémentation actuelle )
Marsh Posté le 08-10-2004 à 23:50:51
ben non, h est le curseur
c'est une pile, et fifo tu peux appeler ca file
Marsh Posté le 08-10-2004 à 23:59:27
cris56 a écrit : ben non, h est le curseur |
mouais
Citation : c'est une pile, et fifo tu peux appeler ca file |
Marsh Posté le 09-10-2004 à 00:16:19
Citation : stack et queue |
stack = FILO
queue = FIFO
non?
Marsh Posté le 09-10-2004 à 00:19:21
bon, donc autant utiliser les termes consacrés pour une pile, qui sont fifo et filo, non?
Marsh Posté le 09-10-2004 à 00:23:44
en français, c'est Pile et File et tout le monde le comprends
Marsh Posté le 09-10-2004 à 00:24:51
c'est ce que j'avais dit au debut, ca semblais pas etre compris ??
Marsh Posté le 09-10-2004 à 00:31:03
Taz a écrit : en français, c'est Pile et File et tout le monde le comprends |
mais ca veut rien dire
ca découle de comparaisons avec des éléments de vie, alors que les termes originaux sont les acronymes décrivant le comportement de la pile
enfin bon laissez tomber je viens de me rendre compte que je fais des mélanges francais anglais sans même le réaliser
j'vais me tirer une balle, redémarrer mon PC, réinstaller mon imprimante et je reviens
Marsh Posté le 09-10-2004 à 00:35:12
ca veut tout dire au contraire, tu vois tout de suite quel genre de probleme tu va pouvoir modeliser
Marsh Posté le 09-10-2004 à 01:04:11
cris56 a écrit : ca veut tout dire au contraire, tu vois tout de suite quel genre de probleme tu va pouvoir modeliser |
pour moi, pas plus qu'en utilisant les termes fifo/lifo
Marsh Posté le 09-10-2004 à 09:50:41
meumeul a écrit :
|
Hum... est-ce bien judicieux de faire "return" d'une structure ? Si tous les octets de la structure sont renvoyés par copie cela risque d'être bien long.
Marsh Posté le 09-10-2004 à 09:59:47
Sve@r a écrit : Hum... est-ce bien judicieux de faire "return" d'une structure ? Si tous les octets de la structure sont renvoyés par copie cela risque d'être bien long. |
Nan, c'est bon. Sa structure ne contient qu'un pointeur et un entier, c'est pas très gourmand...
Marsh Posté le 09-10-2004 à 10:12:46
je sais que c pas une "vraie" pile, c juste l'implentation
que le prof veut. Je la trouve bien pourri, mais bon
Apres on doit faire une pile chainée, ca sera biiien mieux.
Mais pas le choix, je devais faire comme ca.
Marsh Posté le 08-10-2004 à 21:47:19
alors que toues les chiffres que j'ai empilé sont en dessous de 10.
Je suppose que c mes mallocs qui font nimporte quoi,
mais je comprend pas pkoi.
une idée ?