En C++ il y a deux mécanismes de polymorphisme: les méthodes virtuelles où la résolution se passe à l'éxécution du programme, et les templates, où la résolution se passe à la compilation.
Du coup quand on lit un truc du style «Le Visiteur template à base de RTTI» qui annonce mélanger du polymorphisme à l'éxécution et du polymorphisme à la compilation, on se dit à quoi bon?
on peut passer par un membre mais c'est moins joli.
Si tu ne veux pas montrer ton membre dans l'espace public, il suffit d'encapsuler l'appel à Visitor::visit dans une fonction qui renvoie la valeur du membre. Au passage, cela permet de donner un vrai nom à la fonction au lieu de visit.
L'implémentation classique du modèle n'est d'ailleurs pas ce que tu donnes: dans Base la méthode accept est virtuelle et abstraite et implémentée dans les classes concrètes Derived1, Derived2. Dans ce cas Visitor::visit(Base& b) est b.accept(*this).
# Polymorphisme
Posté par Michaël (site web personnel) . En réponse au journal Visiteurs en C++. Évalué à 5. Dernière modification le 25 avril 2013 à 01:12.
En C++ il y a deux mécanismes de polymorphisme: les méthodes virtuelles où la résolution se passe à l'éxécution du programme, et les templates, où la résolution se passe à la compilation.
Du coup quand on lit un truc du style «Le Visiteur template à base de RTTI» qui annonce mélanger du polymorphisme à l'éxécution et du polymorphisme à la compilation, on se dit à quoi bon?
Si tu ne veux pas montrer ton membre dans l'espace public, il suffit d'encapsuler l'appel à Visitor::visit dans une fonction qui renvoie la valeur du membre. Au passage, cela permet de donner un vrai nom à la fonction au lieu de visit.
L'implémentation classique du modèle n'est d'ailleurs pas ce que tu donnes: dans Base la méthode accept est virtuelle et abstraite et implémentée dans les classes concrètes Derived1, Derived2. Dans ce cas Visitor::visit(Base& b) est b.accept(*this).