Pour le coup, la lisibilité de visitBinaryExpression est la même, il n'y qu'une seule méthode supplémentaire a créer.
Note que je suis pas sûr de la bonne équivalence du code, vu que ton getResult() ne semble lié à aucun objet. J'ai donc supposé un prototype genre "Type* TypeDerive::getResult(void)" mais ça reste une supposition.
Si c'est lié à autre chose, le même principe peut se faire aussi de toute façon.
Je pense aussi que tu vas lever l'argument de la méthode virtuelle pure qui empêche d'utiliser accept() sur Type, mais ce n'est pas parce qu'une méthode est virtuelle pure qu'il est interdit de l'implémenter. C'est juste les filles ont l'obligation de le faire (j'ai appris ça il y a quelques mois, j'ai testé vite fait et effectivement… mais je n'ai pas trop joué avec, pas eu l'utilité encore).
PS: j'ai l'impression d'avoir merdé quelque part… alors je m'excuse par avance -.-'
[^] # Re: Avantage pas compris
Posté par freem . En réponse au journal Visiteurs en C++. Évalué à 0.
Tu codes tassé toi dis donc, ça coûte si cher que ça les lignes vides? :D
Sinon, autre version, avec une méthode supplémentaire à implémenter:
Pour le coup, la lisibilité de visitBinaryExpression est la même, il n'y qu'une seule méthode supplémentaire a créer.
Note que je suis pas sûr de la bonne équivalence du code, vu que ton getResult() ne semble lié à aucun objet. J'ai donc supposé un prototype genre "Type* TypeDerive::getResult(void)" mais ça reste une supposition.
Si c'est lié à autre chose, le même principe peut se faire aussi de toute façon.
Je pense aussi que tu vas lever l'argument de la méthode virtuelle pure qui empêche d'utiliser accept() sur Type, mais ce n'est pas parce qu'une méthode est virtuelle pure qu'il est interdit de l'implémenter. C'est juste les filles ont l'obligation de le faire (j'ai appris ça il y a quelques mois, j'ai testé vite fait et effectivement… mais je n'ai pas trop joué avec, pas eu l'utilité encore).
PS: j'ai l'impression d'avoir merdé quelque part… alors je m'excuse par avance -.-'