Bug incompréhensible dans un programme C compilé en .EXE

→ **MyCalcs** profile · de **rentech7289** » 16 Aoû 2021, 19:40

Bonjour
Exact: en C, malloc sert à allouer de la mémoire, free à libérer cette même mémoire; en C++: new et delete. Quand on utilise malloc pour une variable, on utilise free sur cette même variable dès qu'elle est inutile. La raison est que les langages C, à la différence de python ou Java, ne gèrent pas la mémoire. Ce qui fait que tant que le programme n'est pas terminé elle est perdue. D'autre part, un plantage du programme peut ne pas récupérer cette mémoire, il faut alors redémarrer la machine; C'est la fameuse 'fuite de ressources mémoire' qui peut interrompre un programme par manque de mémoire...
D'autre part, il faut ajouter qu'une compilation vers un fichier executable donne des résultats différents en fonction de la machine. Exemple: avec un même OS et les même programmes, deux ordinateurs identiques exécuteront différemment un programme de jeux qui fait appel à la carte graphique si elles ont un logiciel différent. La raison est la suivante: les exécutables C sont en langage machine, pas en bytecode comme python ou Java qui sont restent interprétables si l"interpréteur/machine virtuelle est compatible. En un mot, un même fichier exécutable peut tourner sur deux machines qui utilisent le mêmes langage machine pour ce même fichier.

→ **MyCalcs** profile · de **Bobb** » 20 Aoû 2021, 10:20

Oui, les machines sur lesquelles le programme fonctionne ne doivent pas avoir la même gestion de mémoire que sur Windows, et le programme ne bug pas.

→ **MyCalcs** profile · de **rentech7289** » 01 Sep 2021, 04:12

Ce n'est pas une question liée typiquement à Windows ou à un OS particulier. Deux machines matériellement identiques, avec les mêmes programmes, mais avec des mises à jour différentes peuvent fournir un résultat different pour le même exécutable. Ce qui joue ici c'est toute la partie logicielle de la machine et non tel ou tel programme. De plus, il suffit parfois de compiler un code source avec un autre compilateur pour obtenir ce type de résultat...

→ **MyCalcs** profile · de **Bobb** » 29 Jan 2022, 14:15

Merci pour tous ces conseils, de toute façon, je vais réécrire mon programme entièrement et le faire fonctionner autrement. Tous vos conseils vont m'être utiles maintenant, pour ne pas refaire les mêmes erreurs.

Par contre je me posais encore une question.
Dès fois, j'utilise des tableaux de char à double niveau de pointeur : des char** quand que veux stocker différentes chaînes de caractères à la suite. En gros c'est pour faire comme en python : ['salut', 'comment', 'ca', 'va'].

Sauf que si je fais juste un free(), ça va vider le premier tableau, mais pas les chaînes en elle-même. Ca va vider juste l'endroit où sont stockés les adresses des char* mais pas les char* en eux mêmes.

Dans ce cas, je fais quoi pour tout vider ? Une boucle de free ?

→ **MyCalcs** profile · de **Adriweb** » 29 Jan 2022, 14:16

Une boucle, oui, pour free chacun des strings d'abord, puis l'array a la fin.

→ **MyCalcs** profile · de **Bobb** » 25 Mar 2022, 22:04

Maintenant que j’ai ,,abandonné’’ ce programme ou en tous cas que je l’ai entièrement reprogrammé d’une autre manière bien plus efficace (voir : https://tiplanet.org/forum/viewtopic.php?f=12&t=25550) , et que j’ai progressé en C, je pense pouvoir donner la raison finale du but que j’avais.

En fait quand je tapais un calcul, au lieu de m’afficher le bon résultat, le programme affichait une ribambelle de caractères abracadabrants. A mon avis, c’est dû au fait que quand j’allouais de la memoire pour stocker mes chaînes de caractères, je n’initialisais pas la valeur de chaque élément du tableau de char à 0. Du coup la chaine de carcateres contenait encore les octets de sa précédente allocation. Du coup il faut appeler la fonction memset après l’allocation.
Ça peut peut être aider des gens qui se retrouveraient dans le même cas que je l’ai été.