malloc et piles

malloc et piles - C - Programmation

Marsh Posté le 08-10-2004 à 21:47:19    

Code :
  1. typedef unsigned int Nat;
  2. typedef struct pile {
  3. Nat* v;
  4. Nat h;
  5. } Pile;
  6. Pile pilenouv() {
  7. Pile p;
  8. p.v = (Nat*) malloc (n * sizeof(Nat)); // MALLOCN(n,Nat);
  9. p.h = 0;
  10. return p;
  11. }
  12. Pile empiler(Pile p, Nat x) {
  13. if (pleine(p)) {
  14.  Nat* nouveauTableau = (Nat*) malloc(((p.h)+n)*sizeof(Nat));
  15.  p.v = (Nat*) memcpy(nouveauTableau, p.v, p.h);
  16. }
  17. p.v[p.h]= x;
  18. p.h++;
  19. return p;
  20. }


Code :
  1. Informations sur la pile :
  2.         Hauteur : 7
  3.         Sommet  : 5
  4.         Contenu : 5 | 3998724 | 1096575332 | 1768714352 | 1769234787 | 0 | 6
  5. Fin des informations.


 
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 ?

Reply

Marsh Posté le 08-10-2004 à 21:47:19   

Reply

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...


Message édité par meumeul le 08-10-2004 à 21:49:36
Reply

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

Reply

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  ?

Reply

Marsh Posté le 08-10-2004 à 21:52:17    

"n" c'est un define qui vaut 5

Reply

Marsh Posté le 08-10-2004 à 21:54:26    

ta pas trouvé mieux (et surtout plus unique) comme nom pour ta macros ?

Reply

Marsh Posté le 08-10-2004 à 21:54:54    

Taz a écrit :


donc ce n'est pas 'p.h', mais 'p.h * sizeof(Nat)'
voir 'p.h * sizeof *p.v' si tu veux faire propre


 
merci d'avoir répondu si vite, et qui plus est,
correctement !
ca marche nickel.
Merci :)


Message édité par meumeul le 08-10-2004 à 21:55:25
Reply

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 :)

Reply

Marsh Posté le 08-10-2004 à 21:56:53    

c grave de caster inutilement ?

Reply

Marsh Posté le 08-10-2004 à 21:57:46    

oui, surtout si tu oubli les entetes necessaire

Reply

Marsh Posté le 08-10-2004 à 21:57:46   

Reply

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

Reply

Marsh Posté le 08-10-2004 à 21:58:53    

Oki ben merci à tous les deux. Je débute :)

Reply

Marsh Posté le 08-10-2004 à 22:04:27    

il manque  toujours un free dans empiler
 
memcpy(nouveauTableau , ... );
free( p.v );
p.v = nouveauTableau ;

Reply

Marsh Posté le 08-10-2004 à 22:06:41    

un petit realloc ça serait sympa

Reply

Marsh Posté le 08-10-2004 à 23:27:59    

cris56 a écrit :

il manque  toujours un free dans empiler
 
memcpy(nouveauTableau , ... );
free( p.v );
p.v = nouveauTableau ;


 
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.


Message édité par meumeul le 08-10-2004 à 23:28:56
Reply

Marsh Posté le 08-10-2004 à 23:28:37    

surtout pas en C !

Reply

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.

Reply

Marsh Posté le 08-10-2004 à 23:29:22    

Taz a écrit :

surtout pas en C !


lol autant pour moi alors.
merci

Reply

Marsh 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 :heink:


Message édité par masklinn le 08-10-2004 à 23:37:16

---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody
Reply

Marsh Posté le 08-10-2004 à 23:37:08    

pour justement ne pas avoir à le faire à chaque fois.

Reply

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 [:spamafote]
 
-> 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?


Message édité par masklinn le 08-10-2004 à 23:40:39

---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody
Reply

Marsh Posté le 08-10-2004 à 23:39:03    

je vois pas le rapport...

Reply

Marsh Posté le 08-10-2004 à 23:39:54    

Masklinn a écrit :


 
-> meumeul
tu peux aussi remplacer
 p.v[p.h]= x;
 p.h++;
 
par p.v[p.h++] = x;

aucun intérêt sauf dégrader la lisibilité, déjà mauvaise avec des membres '.v' et '.h'

Reply

Marsh Posté le 08-10-2004 à 23:42:34    

et h doit etre un size_t

Reply

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 [:figti]  
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 [:fande--] )
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 [:fande--] )


Message édité par masklinn le 08-10-2004 à 23:44:46

---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody
Reply

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

Reply

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


 :??:  


---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody
Reply

Marsh Posté le 09-10-2004 à 00:00:52    

ya stack et queue

Reply

Marsh Posté le 09-10-2004 à 00:02:54    

il manque effectivement un membre capacité

Reply

Marsh Posté le 09-10-2004 à 00:16:19    

Citation :

stack et queue


stack = FILO
queue = FIFO
 
non?


---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody
Reply

Marsh Posté le 09-10-2004 à 00:18:21    

oui

Reply

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?


---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody
Reply

Marsh Posté le 09-10-2004 à 00:23:44    

en français, c'est Pile et File et tout le monde le comprends

Reply

Marsh Posté le 09-10-2004 à 00:24:51    

c'est ce que j'avais dit au debut, ca semblais pas etre compris ??

Reply

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 [:spamafote]  
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 [:spamafote]
 
enfin bon laissez tomber je viens de me rendre compte que je fais des mélanges francais anglais sans même le réaliser :cry:  
 
j'vais me tirer une balle, redémarrer mon PC, réinstaller mon imprimante et je reviens :hello:


Message édité par masklinn le 09-10-2004 à 00:32:34

---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody
Reply

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

Reply

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 [:spamafote]


---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody
Reply

Marsh Posté le 09-10-2004 à 09:50:41    

meumeul a écrit :

Code :
  1. typedef unsigned int Nat;
  2. typedef struct pile {
  3. Nat* v;
  4. Nat h;
  5. } Pile;
  6. Pile pilenouv() {
  7. Pile p;
  8. p.v = (Nat*) malloc (n * sizeof(Nat)); // MALLOCN(n,Nat);
  9. p.h = 0;
  10. return p;
  11. }




 
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.


---------------
Vous ne pouvez pas apporter la prospérité au pauvre en la retirant au riche.
Reply

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...

Reply

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.

Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed