Si tu codes en objet c'est normal, effectivement la construction des objets et l'archi globale des applications fait que tu es beaucoup plus carré de ce coté la.
Si tu regardes du cote du C (puisque c'est principalement lui qui pose problème) j'ai jamais vu un devel ecrire "propre". Si tu fais un valgrind sur les applis tu verras qu'il n'y a pas de leaks simplement des warnings "Memoire encore referencee mais non liberee" par ce que ca valait pas le coup de saloper le soft de code inutile. La ou c'est propre dans des destructeurs et se fait en 80 caracteres en P0O; en C tu auras souvent un pavé de 50 lignes pour reussir a terminer proprement, donc on ne fait que ce qui est necessaire et en utilisant atexit() par exemple.
Genre tu ecris un filtre qui construit un arbre a partir de stdin et qui en fait XXX sur stdout. 99% des devels ne vont pas libérer la mémoire, il leur suffirait de faire un parcours recursif s'il y avait besoin mais tant que le cas special ne se presente pas.... Si le même devel est en train d'écrire une lib qui s'interface sur graphviz il fera une fonction pour libérer sa structure.
[^] # Re: OS
Posté par ckyl . En réponse au journal La mémoire ? On s'en fout !. Évalué à 2.
Si tu codes en objet c'est normal, effectivement la construction des objets et l'archi globale des applications fait que tu es beaucoup plus carré de ce coté la.
Si tu regardes du cote du C (puisque c'est principalement lui qui pose problème) j'ai jamais vu un devel ecrire "propre". Si tu fais un valgrind sur les applis tu verras qu'il n'y a pas de leaks simplement des warnings "Memoire encore referencee mais non liberee" par ce que ca valait pas le coup de saloper le soft de code inutile. La ou c'est propre dans des destructeurs et se fait en 80 caracteres en P0O; en C tu auras souvent un pavé de 50 lignes pour reussir a terminer proprement, donc on ne fait que ce qui est necessaire et en utilisant atexit() par exemple.
Genre tu ecris un filtre qui construit un arbre a partir de stdin et qui en fait XXX sur stdout. 99% des devels ne vont pas libérer la mémoire, il leur suffirait de faire un parcours recursif s'il y avait besoin mais tant que le cas special ne se presente pas.... Si le même devel est en train d'écrire une lib qui s'interface sur graphviz il fera une fonction pour libérer sa structure.