Je ne sais pas trop quoi penser de l'article, je suis d'accord avec tous les exemples, mais il me titille quand même.
Déjà pour l'histoire des macros, évidemment, ce sont de très mauvaises macro à éviter absolument, mais ça n'a rien à voir avec le sujet de free, mais dans d'autres contextes (et l'exemple de la macro max le montre bien), ce genre de macro est à proscrire.
Ensuite le tests avant le free, perso je me suis reconnu dans le cas "débutant", je me souviens encore dans mes jeunes années de dev quand j'ai appris que free (pour rêtre honnete, dans mon cas c'était delete du c++) vérifiait si le pointeur n'était pas null et j'ai arreté de faire la vériication à chaque fois.
Mais dans la pratique, il arrive souvent que dans les phases de nettoyage on ne fasse pas qu'un free, exemple :
if ( ptr != NULL ) {
do_something(ptr);
free(ptr);
}
Alors oui, le free peut-être sorti du bloc if, mais en terme de lisibilité, je trouve ça vraiment mieux de l'y laisser.
Et pour ce que tu appelles la programmation défensive (bizarre comme terme, ça existe la programmation offensive où on cherchce volontairement à se mettre dans des situations compliquées ???) c'est pareil : dans la pratique, mettre le pointeur à NULL c'est un flag qui permet de connaitre un état local pour le gérer correctement quand je ré-entre dans ce code, je le fait très régulièrement et je trouve que c'est une pratique très saine, simple d'utilisation et très utile.
Pour en revenir à l'article, j'ai l'impression que l'auteur prend des cas d'utilisation pourris pour appuyer ses arguments. Je peux faire à peu près pareil avec beaucoup de pratiques de code, de fonctions ou d'objet des librairies standard. Oui, quand on s'en sert mal, ç'est pas bien. (variante du : "c'est pas gentil d'être méchant")
Des questions intéressantes, pour toute critique sur des pratiques de code, seraient plutôt :
- est ce qu'il est trop facile de mal s'en servir même pour quelqu'un de pas complètement débutant ?
- quels sont les cas utiles, intéressants, et est-ce qu'il sont assez importants pour accepter qu'il y ait des limitations, revers à l'utilisation.
- est ce qu'il n'est pas plus intéressant de comprendre dans quel contexte cela est utile, pour savoir dans lesquels on peut s'en passer ? (typiquement l'idée du livre sur "design patterns" pour des cas un peu plus complexes et précis)
# Cas plus concrets
Posté par moi1392 . En réponse au journal Traduction | Doit-on vérifier le pointeur pour NULL avant d'appeler la fonction free ?. Évalué à 4. Dernière modification le 24 avril 2024 à 22:17.
Je ne sais pas trop quoi penser de l'article, je suis d'accord avec tous les exemples, mais il me titille quand même.
Déjà pour l'histoire des macros, évidemment, ce sont de très mauvaises macro à éviter absolument, mais ça n'a rien à voir avec le sujet de free, mais dans d'autres contextes (et l'exemple de la macro max le montre bien), ce genre de macro est à proscrire.
Ensuite le tests avant le free, perso je me suis reconnu dans le cas "débutant", je me souviens encore dans mes jeunes années de dev quand j'ai appris que free (pour rêtre honnete, dans mon cas c'était delete du c++) vérifiait si le pointeur n'était pas null et j'ai arreté de faire la vériication à chaque fois.
Mais dans la pratique, il arrive souvent que dans les phases de nettoyage on ne fasse pas qu'un free, exemple :
Alors oui, le free peut-être sorti du bloc if, mais en terme de lisibilité, je trouve ça vraiment mieux de l'y laisser.
Et pour ce que tu appelles la programmation défensive (bizarre comme terme, ça existe la programmation offensive où on cherchce volontairement à se mettre dans des situations compliquées ???) c'est pareil : dans la pratique, mettre le pointeur à NULL c'est un flag qui permet de connaitre un état local pour le gérer correctement quand je ré-entre dans ce code, je le fait très régulièrement et je trouve que c'est une pratique très saine, simple d'utilisation et très utile.
Pour en revenir à l'article, j'ai l'impression que l'auteur prend des cas d'utilisation pourris pour appuyer ses arguments. Je peux faire à peu près pareil avec beaucoup de pratiques de code, de fonctions ou d'objet des librairies standard. Oui, quand on s'en sert mal, ç'est pas bien. (variante du : "c'est pas gentil d'être méchant")
Des questions intéressantes, pour toute critique sur des pratiques de code, seraient plutôt :
- est ce qu'il est trop facile de mal s'en servir même pour quelqu'un de pas complètement débutant ?
- quels sont les cas utiles, intéressants, et est-ce qu'il sont assez importants pour accepter qu'il y ait des limitations, revers à l'utilisation.
- est ce qu'il n'est pas plus intéressant de comprendre dans quel contexte cela est utile, pour savoir dans lesquels on peut s'en passer ? (typiquement l'idée du livre sur "design patterns" pour des cas un peu plus complexes et précis)