Non: lorsque le langage supporte l'overloading, tu dois non seulement savoir le nom et le type de la fonction que tu veux appeler, mais aussi être sûr qu'il n'y a aucune autre fonction avec le même nom et une signature compatible. Parce que dans le cas contraire, une petite erreur de type peut passer à la compilation, ce qui remet en question un des principes fondamentaux du typage statique.
Dans un projet un peu large, demander au programmeur de garder à l'esprit l'ensemble de toutes les fonctions existantes est irréaliste.
Et savoir que les conversions implicites sont dangereuses n'est pas le problème. Le problème est que, le duo overloading + conversion implicite fait que le compilateur va chercher silencieusement à "réparer" une erreur de type, comme par exemple un int à la place d'un float (voire pire, un float à la place d'un double). Et lorsqu'on a besoin de ces différents types dans un même projet, ces erreurs arrivent fatalement, même au meilleur programmeur.
Je trouve ça étrange que tu compares avec le polymorphisme
(Note: le polymorphisme peut être tout aussi bien statique que dynamique). J'ai pris l'exemple du polymorphisme par c'est un mécanisme similaire (permet d'utiliser le même nom de fonction pour des objets différents), mais avec une sémantique claire (un nom dans une classe = une fonctionnalité, éventuellement avec plusieurs implémentations).
Il en va de même avec la surcharge des opérateurs en C: la sémantique est claire, tout le monde connaît les règles mathématiques. Ton exemple avec les matrices tombe aussi dans cette catégorie.
Naturellement, on peut donner des milliers d'exemples de mauvaise utilisation de l'overloading. Mais de la mauvaise programmation peut être faite dans n'importe quel paradigme.
Je suis entièrement d'accord, et j'ai horreur qu'on justifie la suppression d'une fonctionnalité sous prétexte qu'elle peut-être mal utilisée.
Mais le cas de l'overloading est différent: il induit invariablement des erreurs, même lorsque l'on ne l'utilise pas. Et, encore une fois, je n'ai jamais vu de situation où il n'y avait pas une solution plus élégante.
S'il fallait absolument introduire quelque chose de ce genre en C, l'approche prise par le langage Go (les interfaces) me parait nettement plus saine.
[^] # Re: _Generic et surcharge de fonction
Posté par drakmaniso . En réponse à la dépêche C11 n'est pas encore mort. Évalué à 1.
Non: lorsque le langage supporte l'overloading, tu dois non seulement savoir le nom et le type de la fonction que tu veux appeler, mais aussi être sûr qu'il n'y a aucune autre fonction avec le même nom et une signature compatible. Parce que dans le cas contraire, une petite erreur de type peut passer à la compilation, ce qui remet en question un des principes fondamentaux du typage statique.
Dans un projet un peu large, demander au programmeur de garder à l'esprit l'ensemble de toutes les fonctions existantes est irréaliste.
Et savoir que les conversions implicites sont dangereuses n'est pas le problème. Le problème est que, le duo overloading + conversion implicite fait que le compilateur va chercher silencieusement à "réparer" une erreur de type, comme par exemple un int à la place d'un float (voire pire, un float à la place d'un double). Et lorsqu'on a besoin de ces différents types dans un même projet, ces erreurs arrivent fatalement, même au meilleur programmeur.
(Note: le polymorphisme peut être tout aussi bien statique que dynamique). J'ai pris l'exemple du polymorphisme par c'est un mécanisme similaire (permet d'utiliser le même nom de fonction pour des objets différents), mais avec une sémantique claire (un nom dans une classe = une fonctionnalité, éventuellement avec plusieurs implémentations).
Il en va de même avec la surcharge des opérateurs en C: la sémantique est claire, tout le monde connaît les règles mathématiques. Ton exemple avec les matrices tombe aussi dans cette catégorie.
Je suis entièrement d'accord, et j'ai horreur qu'on justifie la suppression d'une fonctionnalité sous prétexte qu'elle peut-être mal utilisée.
Mais le cas de l'overloading est différent: il induit invariablement des erreurs, même lorsque l'on ne l'utilise pas. Et, encore une fois, je n'ai jamais vu de situation où il n'y avait pas une solution plus élégante.
S'il fallait absolument introduire quelque chose de ce genre en C, l'approche prise par le langage Go (les interfaces) me parait nettement plus saine.