Posté par ahuillet .
En réponse au journal realloc.
Évalué à 5.
Perso, le mec qui me fait du code "super secure" pour un prototype par exemple "parce qu'il faut toujours bien coder", je le paye moitié moins car 50% du temps est pour son plaisir
Ce genre de "robustesse" a effectivement un coût, ce que pas mal de commentateurs semblent ignorer. Pour un prototype c'est carrément contre-productif de faire des vérifications de ce genre, mais c'est parfois également vrai sur des logiciels de production. Ceux qui ont développé par exemple dans Catia en savent quelque chose : vérifier si le pointeur est NULL avant chaque utilisation, ça a un coût en temps de développeur. (Cela a également un coût en temps d'exécution, qui n'est pas négligeable en C++ car on n'a pas de JIT pour éliminer ces NULL-checks.)
La question qui se pose c'est "est-ce que l'amélioration vaut le temps qu'elle coûte" (comme toujours en ingénierie logicielle), et pour des programmes non critiques la réponse est non sans hésiter. Lorsqu'un développeur passe son temps à écrire de la gestion d'erreur-qui-n'arrivera-pas, il ne fait pas autre chose de plus productif.
Concernant ce journal on est tout simplement dans le ridicule. Si realloc() returne NULL, ce qui n'arrive essentiellement jamais sous Linux, le programme va crasher (ce que Conky fait assez souvent par ailleurs). C'est un comportement tout à fait correct.
[^] # Re: Chaque amélioration compte
Posté par ahuillet . En réponse au journal realloc. Évalué à 5.
Ce genre de "robustesse" a effectivement un coût, ce que pas mal de commentateurs semblent ignorer. Pour un prototype c'est carrément contre-productif de faire des vérifications de ce genre, mais c'est parfois également vrai sur des logiciels de production. Ceux qui ont développé par exemple dans Catia en savent quelque chose : vérifier si le pointeur est NULL avant chaque utilisation, ça a un coût en temps de développeur. (Cela a également un coût en temps d'exécution, qui n'est pas négligeable en C++ car on n'a pas de JIT pour éliminer ces NULL-checks.)
La question qui se pose c'est "est-ce que l'amélioration vaut le temps qu'elle coûte" (comme toujours en ingénierie logicielle), et pour des programmes non critiques la réponse est non sans hésiter. Lorsqu'un développeur passe son temps à écrire de la gestion d'erreur-qui-n'arrivera-pas, il ne fait pas autre chose de plus productif.
Concernant ce journal on est tout simplement dans le ridicule. Si realloc() returne NULL, ce qui n'arrive essentiellement jamais sous Linux, le programme va crasher (ce que Conky fait assez souvent par ailleurs). C'est un comportement tout à fait correct.