plantage a la liberation de la memoire [C] - C - Programmation
Marsh Posté le 10-08-2004 à 21:47:29
bon, que je m'explique alors vu que on dirait que quelqu'un ici aime a ce que l'on soit precis...
Oui j'ai fais une classe C++, et oui j'utilise les fonctions C malloc, printf... et autres et non je ne veux pas changer pour iostream.h et new, delete a la place de malloc free...
Et bon, que je sache, ca m'etonnerait que les problemes viennent de l'utilisation de malloc a la place de new vu que dans mon cas, j'ai vérifié et je n'ai pas de problemes lors des allocations...
Marsh Posté le 10-08-2004 à 21:56:19
ton problème c'est que tu fais du très mauvais C avec des classes C++ : à mélanger les genre, tu n'as que les inconvénients des 2 langages
edit : y a pas a dire, je ne garderais pas une seule ligne, ton C est vraiment mauvais et dangereux. revois tes bases sur les FILE* (feof en particulier), (f)scanf, découvre fgets, les enums, les déclarations imbriquées, le mot clef const, vire tes cast inutiles. tes allocations sont bugguées et défaillantes, tu passes ton temps à corrompre ta mémoire. y a pas un seul malloc correct
quant au C++, n'en parlons pas
Marsh Posté le 10-08-2004 à 22:08:56
GuiYom_00 a écrit : Oui j'ai fais une classe C++, et oui j'utilise les fonctions C malloc, printf... et autres |
ouais enfin a la base tu choisis entre C et C++ et tu t'y tiens, à part quand t'as pas le choix tu code pas dans un truc hybride avec des bouts de C et des bouts de C++...
Citation : et non je ne veux pas changer pour iostream.h |
et <iostream>?
Après pour la technique 'pure' je ne vais sûrement pas prétendre être du niveau du grincheux croulant ( ) donc je vais te laisser voir ce qu'il dit
Marsh Posté le 10-08-2004 à 22:23:55
en fait ce qui se passe c que j'ai un code fait a 95% en C et pour me faciliter la vie, j'aurais juste besoin de la classe C++ que j'ai copié au dessus...
donc voila pourquoi je veux pas tout reprendre maintenant que j'en suis a un peu plus de 5000 ligne de code quand meme...
Marsh Posté le 10-08-2004 à 22:41:52
ben quand t'es pas capable de faire un malloc correct mais que tu te permets de critiquer new, j'ai peur ...
Marsh Posté le 10-08-2004 à 22:51:16
alors dans ce cas dis moi ou mon malloc est pas correct...
si c'est a cause des typecast, c juste pour que VS gueule pas...
Marsh Posté le 10-08-2004 à 23:01:38
sle.pvVal=(void *)malloc(sizeof(int *)); dans readFile par exemple
Marsh Posté le 10-08-2004 à 23:05:15
tu preferes que je mettes sle.pvVal=(void *)malloc(sizeof(void *));
mais bon ca ne changes quand meme rien...
Marsh Posté le 10-08-2004 à 23:10:38
GuiYom_00 a écrit : tu preferes que je mettes sle.pvVal=(void *)malloc(sizeof(void *)); |
c'est un pointeur sur quel type sle.pvVal ?
Marsh Posté le 10-08-2004 à 23:16:12
justement, ca depends... ca peut etre float, int, double...
donc par defaut je mets un void et apres je fais un cast quand je veux lui donner une valeur particuliere... mais bon, vu que tout les pointeurs ont la meme taille, c'est vrai que c'est pas la dessus que j'ai porté toute mon attention...
Edit : c'est vrai que une fois que je serais sur que les fontions marchent, je m'occuperai de rendre la classe canonique...
Marsh Posté le 10-08-2004 à 23:19:48
si tu veux allouer pour un double
sle.pvVal=malloc(sizeof(double));
...
le cast du malloc est inutile
Marsh Posté le 10-08-2004 à 23:23:13
*(double *)pSLnew->pvVal = *(double *)SLe->pvVal
et après ça y va ....
Marsh Posté le 10-08-2004 à 23:26:09
et je parle pas du cast de lvalue qui est rigoureusement interdit
Marsh Posté le 10-08-2004 à 23:31:22
sprintf((char *)pSLnew->pvVal,"%s",(char *)SLe->pvVal);
et ça c'est pas beau ?
Marsh Posté le 10-08-2004 à 23:31:40
ok si je veux allouer pour un double je fais sle.pvVal=malloc(sizeof(double));
mais le truc c'est que je ne sais pas a l'avance quel est le type des variables or dans ma declaration il faut quand meme que je dise que j'ai besoin d'un pointeur...
Peut etre que si j'explique un peu plus dans quel but je fais cette classe, cela rendra les choses plus claires...
Un programme a besoin de X parametres , par exemple un temps (double), une position (aussi double), le nom d'un fichier (char *)...et il faut qu'il stocke ces parametres dans un fichier a qu'il puisse les relire a chaque execution...
Dans ce cas, je me sers de cette classe pour creer le fichier avec les valeurs dedans, et aussi pour le lire...
Donc vu que mes variables peuvent etre de differents type, je ne vois pas comment faire autrement que par des void * et des cast...
Marsh Posté le 10-08-2004 à 23:33:21
« il faut quand meme que je dise que j'ai besoin d'un pointeur... » le fait est que tu n'as pas besoin d'un pointeur
la solution classique C, c'est union + enum, comme j'ai déjà maintes fois donné l'exemple
Marsh Posté le 10-08-2004 à 23:50:33
Oui c'est vrai que j'avais pas pensé au systeme enum+union...
mais ca n'empeche que j'aimerais savoir pourquoi j'ai les free qui plantent de temps en temps alors que, meme si l'utilisation des void * n'est peut etre pas la plus "jolie", a aucun moment dans les test que j'ai fais je n'ai eu de problemes pour lire mes valeurs, les ecrire, les afficher ou quoi que ce sois d'autres...
Marsh Posté le 10-08-2004 à 23:51:31
qu'est-ce que tu veux que tes free comprennent si tu cases tes données n'importe ou ? le problème c'est pas les free bordel
Marsh Posté le 10-08-2004 à 23:56:31
mes mes données sont bien casées dans mes pointeurs void pourtant... donc je vois pas en quoi les free sont génés...
Edit et pour en revenir aux expressions du type : *(int *)sle.pvVal = *(int *)pvValue
Si j'ai fais ca, c'est que je ne veux pas que au moment ou je libere la memoire allouée a sle.pvVal, ca joue sur la zone memoire de pvValue...
Or si j'avais fais sle.pvVal=pvValue
et qu'ensuite je fais un free(sle.pvVal) alors que va-t-il advenir de la valeur de pvValue??
Marsh Posté le 11-08-2004 à 00:01:09
la ou elle devrait pas être, ça corrompt tout et n'importe quoi
Marsh Posté le 11-08-2004 à 00:09:15
ok donc dans ce cas je vais voir ce que me donne un petit debug en suivant bien tout du debut a la fin concernant la memoire pour savoir ou c que ca commence a partir en live...
Marsh Posté le 11-08-2004 à 00:10:31
des que tu touches à un pointeur
tu gagnerais du temps à passer au modèle enum+union, plus d'allocation dynamique si ce n'est pour ta structure de données.
ou alors tu fais ça en 2 lignes de C++ avec std::list, mais c'est toi qui voit
Marsh Posté le 11-08-2004 à 00:15:42
C'est sur que la liste chainée, je vois pas trop comment je pourrais faire autrement...
et bon, le modele enum+union est assez rapide a mettre en place, mais vu que je suis quand meme un peutetu, je vais essayer de voir plus en detail les raisons des plantages...car les pointeurs, je fais gaffe justement a essayer de pas trop les "deplacer" mais juste a modifier leurs valeurs...
Marsh Posté le 10-08-2004 à 20:16:26
Bonjour, ou plutot bonsoir,
Voila je bosse sur cette liste chainée depuis ce matin, tout marche bien sauf la fonction SLfree qui a une tendance a planter... Donc si quelqu'un voit pourquoi...
Je pense que ca peut etre quelque chose que j'ai pas fais de maniere assez "propre" mais je vois pas pourquoi les plantages sont pas tout le temps au meme endroit dans la fonction.
Donc bon je pourrais ne pas liberer la memoire en fin de programme mais c'est loin d'etre une maniere elegante de faire je trouves...
Message édité par GuiYom_00 le 10-08-2004 à 20:29:33