Bonjour à tous.
Je n'aime pas les ramasse-miettes ! Ils sont peut être utiles pour les programmeurs peu structurés qui oublient de mettre un free() pour chaque [m|re|c]alloc(), mais ils sont une plaie pour débugguer.
Car un bon exemple illustre très bien mon problème : voici comment j'ai perdu deux heures de développement à cause du Gc Ocaml.
J'avais écris une petite bibliothèque statique en C pour Ocaml (parce que caml pour faire de la prog bas niveau bonjour !), bibliothèque exportant une fonction retournant un tuple (un struct dont les attributs ne sont pas nommés). J'ai quelques semaines plus tard décidé d'ajouter un champ à mon tuple, mais sans toucher à la taille demandée à la fonction d'allocation (erreur de débutant). Il s'en suit bien évidement un SIGSEGV.
Sauf que, grace à la gestion "intelligente" de la mémoire par le Gc, ce n'est que lorsque je demande un gros segment que j'obtiens l'erreur faisant planter l'application purement et simplement. Finalement, c'est sur une fonction de la bibliothèque GTK de chargement de fichier image que mon code crashait. Il m'a fallu plus de deux heures pour comprendre que le réel problème ne venait pas de là.
Les Garbage Collectors peuvent être une bonne chose, notamment pour les applications graphiques, mais ils devrait pouvoir être désactivés lors du déboggage, au diable les memory leaks lors des phases de tests (ne visant pas à vérifier qu'il n'y a pas de fuites). Mais je maintiens mon idée première : un code structuré n'a pas de fuite !






Répondre avec citation










Partager