Thepro (./1533) :
Pour la première partie, tu pourrais ne pas imbriquer tous les tests :
Je sais pas pourquoi je suis parti sur cette idée. Je vais réécrire tout ce fichier. D'ailleurs, c'est pour ça que je termine jamais un programme, je recommence tout quand ça va pas.
Thepro (./1533) :
Ensuite, tu essayes peut-être de faire trop de choses dans une seule fonction. Tu ne pourrais pas séparer la lecture du fichier et la création du MODULE_DATA ?
Pourquoi pas, mais ça serait purement "artificiel". Je construit ici un module (la page des highscores) qui a bien besoin de lire ce fichier-là pour se construire. Mais si ça fait plus propre, pourquoi pas appeler une fonction inline.
PpHd (./1534) :
Linux autorise à allouer plus de mémoires virtuelles qu'il ne peut en allouer physiquement), tu peux avoir un pointeur valide, mais dès que tu essayes d'y écrire, boum
J'ai vu ça dans les doc de malloc cette semain, j'ai halluciné
Mais j'ai encore plus halluciné quand Kevin m'a dit que les programmes ne vérifiaient pas, la majorité du temps, leurs malloc, que std::bad_alloc n'était jamais intercepté etc... Dans tout mon programme, je termine proprement en cas d'erreur. Bonne habitude prise sur TI.Toi tu me conseilles de faire un abort si j'ai quelque chose qui échoue ? C'est-à-dire je ne libère rien, je laisse tout en plan et je me casse ?
Je trouve ça super crade
ps -> ah oué, tu me conseilles de définir une fonction void* my_alloc(size) qui fait abort si elle a foiré
PpHd (./1534) :
Terminaison (pas forcément du tien d'ailleurs).
OOM Killer. Je trouve ça bizare ce truc, dans quel état le système se retrouve après ça ^^ Mais c'est sûr que c'est mieux qu'un système sans mémoire.
(J'ai vu ça dans la doc aussi, sisi Bob
)PpHd (./1534) :
Un autre raison pour est que si ton programme n'arrive pas à allouer les 44 octets nécessaires à tes structures, il ne pourra rien faire du tout de toute facon.
Oui bien sûr, le système est évidemment dans un état critique. Ya peut-être autre chose à faire que de nettoyer tout proprement. Je sais pas quelles sont les bonnes stratégies sur PC. Sur TI en tout cas, j'ai toujours fait proprement (même si PreOS aurait pu tout faire pour moi
).Thepro (./1535) :
Tiens, il manque des tests pour savoir si les fread ont réussi
Oui, rajoutés depuis, bien vu t'as l'oeil
(feof et ferror)Zerosquare (./1536) :
Pour les erreurs fatales (qui font que tu vas terminer ton programme), atexit() est une solution assez élégante.
Effectivement, j'ai enregisté deux fonctions au début de mon programme : une qui ferme la STL, une autre qui détruit les modules chargés en appelant leur destructeurs (qui eux-même appellent ceux des objets qui les composent, c'est bien foutu je suis content de mon système
).Mais je crois qu'un appel à abort zappe les atexit()
