Discussion :

[Davidbrcz]

Salut à tous.
Je suis en train de lire le livre Conception et programmation orientées objet par Bertrand Meyer.

1er salve de critiques:
Dans le chapitre 14 qui est consacré à l'héritage, il analyse les choix fait par le comité du C++ en ce qui concerne les techniques de liaisons.

Il relève les points suivants:
C1: rendre le programmeur responsable du choix de la liaison (statique ou dynamique)
C2: utiliser la liaison statique par défaut.

Il relève C1 car selon lui, ce genre de choix tient des compilateurs et non des programmeur, qui devrait se concentrer sur autre chose.
Il en tire aussi la conséquence que C1 viole le principe ouvert-fermé, car choisir si la fonction doit être virtuelle ou non force revient à deviner ce que les classes héritières vont pouvoir redéfinir, et bloque ainsi toute évolution (Pour note, dans le langage étudié, toute liaison est dynamique par défaut, c'est le compilateur qui décide s'il peut la rendre statique).

En ce qui concerne C2,je dois d'abord planter le contexte. Selon lui la liaison statique est une optimisation.En effet, certain appels de fonction ne nécessite pas de liaison dynamique, mais comme dans le langage étudié toute liaison est dynamique, la remplacer par une liaison statique quand c'est possible enlève le sur-coût lié à l'appel dynamique, et c'est donc une optimisation: CQFD.

Après, selon lui :

Une liaison statique est sémantiquement incorrecte sauf si son effet est identique à celui de la liaison dynamique

ce qui semble logique car dans un contexte polymorphique, un appel à une fonction redéfinie dans une classe B via un pointeur de type A (A parent de B) doit appeler la version redéfinie. Et enfin plus loin il résume sa vision à :

La liaison statique est soit une optimisation soit un bogue.

On en arrive donc au cœur du problème, le C++ force à écrire quelque chose de spécial pour arriver à une sémantique correcte.

Pour résoudre C1 et C2 en même temps, il propose de rendre tout appel de fonction virtuel par défaut et ajouter un mot clé pour utiliser la liaison statique.

Dans l'état actuel des choses pour solutionner le problème, il propose de mettre toutes les fonctions membres virtuelles pour contrer C1 et C2, ce qui est paradoxal car cela augmente les temps d'exécution alors que justement C1 et C2 sont présentes pour les diminuer.

Enfin après, il cite un livre de Walter Bright datant de 1995 qui recommande de limiter les technologies Objets (polymorphisme, héritage multiple) à cause des question de coût temporel. je pense que ca a été vrai par le passé mais que ça ne l'est plus.

2eme salve:
Elle concerne le mélange surcharge de fonction ad hoc (via signature) couplé au polymorphisme. Pour résumer, il pense que ca met un bordel par possible dans le choix de la fonction à appeler tout en n'apportant rien au langage. Il conseille donc de bannir cette forme de surcharge.

Que pensez vous de ces critiques ?
Pour ma part, je pense que les critiques liées à C1 et C2 sont globalement justes, même si on peut résoudre le problème avec l'utilisation du pattern template method (en gros, chaque fonction foo d'une ABC fait appel à une fonction virtuelle do_foo qui réalise vraiment foo).

Par contre pour la 2eme salve, je suis plutôt choqué. Bien que les rêgles de surcharge soit assez ésotériques, la surcharge ad hoc permet des chose très puissantes comme par exemple l'uniformité des interfaces (surcharge de operator<< qui permet d l'utiliser quelque soit le type de l'objet) alors que dans son langage, on dispose de fonction tel put_ligne, ....

Merci.

EDIT: La discussion ayant été supprimé à cause du rollback, ci joins l'ensemble des messages de la première discussion, si un admin pouvait les restaurer, merci.