Bonjour,
Quel est l'avantage de typeid( Object ) face à une fonction
Objet::type() retournant un entier par fixe pour chaque type d'Objet à
leur construction ?
Est ce que ca n'engendre pas trop de calculs ?
Est ce que les RTTI sont bien supportés par gcc 3.2.x ?
--------------------------------------------
Benoît Rousseau : roussebe at spray dot se
Jouez en programmant : http://realtimebattle.sourceforge.net/
2) on augmente le risque d'erreur à l'exécution, surtout si en maintenant le code on change la hiérarchie des classes : on est alors obligé de se "souvenir" que les portions du code qui utilisent RTTI dépendent de cette hiérarchie
Ça dépend comment on l'utilise. C'est sûr que du code genre : if ( typeid( *p ) == typeid( ClasseA ) ) { } else if ( typeid( *p ) == typeid( ClasseB ) { ... est à éviter.
Pourquoi est ce à éviter ? J'ai une classe Observer que l'on appelle par la fonction notify(Event*) Il faut que je fasse ce genre de test pour déterminer ce que je vais faire de mon Event*. Sinon, il faudrait que je spécialise chacun des événements pour chacun des Observers (une Factory pour chaque Observer ?) et ce serait beaucoup de travail en plus...
La methode classique est celle du DP Visiteur, en attendant qu'on ait du dispatch multiple. Il y a un certain nombre de variantes qui supposent generalement qu'une des hierarchies est fermees (celles des Event vraissemblablement dans ton cas).
A+
Les Events sont envoyés pour signaler à la GUI qu'il y a eu une modification sur l'un des objets qu'elle doit dessiner (un mur n'a besoin d'être visité qu'une seule fois pendant toute la simulation ; par contre un robot doit être redessiné toutes les n ms). Le Visiteur ne conviendrait pas à ce genre de situation puisqu'il visiterait toutes les objets (à moins qu'il n'y ait une variante que je ne connaisse pas).
Où trouver un bon cours de DP appliqués au C++ ?
-------------------------------------------- Benoît Rousseau : roussebe at spray dot se Jouez en programmant : http://realtimebattle.sourceforge.net/
Jean-Marc Bourguet wrote:
Benoit Rousseau <not.provided@no.spam> writes:
kanze@gabi-soft.fr wrote:
2) on augmente le risque d'erreur à l'exécution, surtout si en
maintenant le code on change la hiérarchie des classes : on est alors
obligé de se "souvenir" que les portions du code qui utilisent RTTI
dépendent de cette hiérarchie
Ça dépend comment on l'utilise. C'est sûr que du code genre :
if ( typeid( *p ) == typeid( ClasseA ) ) {
} else if ( typeid( *p ) == typeid( ClasseB ) {
...
est à éviter.
Pourquoi est ce à éviter ?
J'ai une classe Observer que l'on appelle par la fonction notify(Event*)
Il faut que je fasse ce genre de test pour déterminer ce que je vais faire
de mon Event*.
Sinon, il faudrait que je spécialise chacun des événements pour chacun des
Observers (une Factory pour chaque Observer ?) et ce serait beaucoup de
travail en plus...
La methode classique est celle du DP Visiteur, en attendant qu'on ait
du dispatch multiple. Il y a un certain nombre de variantes qui
supposent generalement qu'une des hierarchies est fermees (celles des
Event vraissemblablement dans ton cas).
A+
Les Events sont envoyés pour signaler à la GUI qu'il y a eu une
modification sur l'un des objets qu'elle doit dessiner (un mur n'a
besoin d'être visité qu'une seule fois pendant toute la simulation ; par
contre un robot doit être redessiné toutes les n ms). Le Visiteur ne
conviendrait pas à ce genre de situation puisqu'il visiterait toutes les
objets (à moins qu'il n'y ait une variante que je ne connaisse pas).
Où trouver un bon cours de DP appliqués au C++ ?
--------------------------------------------
Benoît Rousseau : roussebe at spray dot se
Jouez en programmant : http://realtimebattle.sourceforge.net/
2) on augmente le risque d'erreur à l'exécution, surtout si en maintenant le code on change la hiérarchie des classes : on est alors obligé de se "souvenir" que les portions du code qui utilisent RTTI dépendent de cette hiérarchie
Ça dépend comment on l'utilise. C'est sûr que du code genre : if ( typeid( *p ) == typeid( ClasseA ) ) { } else if ( typeid( *p ) == typeid( ClasseB ) { ... est à éviter.
Pourquoi est ce à éviter ? J'ai une classe Observer que l'on appelle par la fonction notify(Event*) Il faut que je fasse ce genre de test pour déterminer ce que je vais faire de mon Event*. Sinon, il faudrait que je spécialise chacun des événements pour chacun des Observers (une Factory pour chaque Observer ?) et ce serait beaucoup de travail en plus...
La methode classique est celle du DP Visiteur, en attendant qu'on ait du dispatch multiple. Il y a un certain nombre de variantes qui supposent generalement qu'une des hierarchies est fermees (celles des Event vraissemblablement dans ton cas).
A+
Les Events sont envoyés pour signaler à la GUI qu'il y a eu une modification sur l'un des objets qu'elle doit dessiner (un mur n'a besoin d'être visité qu'une seule fois pendant toute la simulation ; par contre un robot doit être redessiné toutes les n ms). Le Visiteur ne conviendrait pas à ce genre de situation puisqu'il visiterait toutes les objets (à moins qu'il n'y ait une variante que je ne connaisse pas).
Où trouver un bon cours de DP appliqués au C++ ?
-------------------------------------------- Benoît Rousseau : roussebe at spray dot se Jouez en programmant : http://realtimebattle.sourceforge.net/
Jean-Marc Bourguet
Benoit Rousseau writes:
Jean-Marc Bourguet wrote:
Benoit Rousseau writes:
J'ai une classe Observer que l'on appelle par la fonction notify(Event*) Il faut que je fasse ce genre de test pour déterminer ce que je vais faire de mon Event*. Sinon, il faudrait que je spécialise chacun des événements pour chacun des Observers (une Factory pour chaque Observer ?) et ce serait beaucoup de travail en plus...
La methode classique est celle du DP Visiteur, en attendant qu'on ait du dispatch multiple. Il y a un certain nombre de variantes qui supposent generalement qu'une des hierarchies est fermees (celles des Event vraissemblablement dans ton cas).
Les Events sont envoyés pour signaler à la GUI qu'il y a eu une modification sur l'un des objets qu'elle doit dessiner (un mur n'a besoin d'être visité qu'une seule fois pendant toute la simulation ; par contre un robot doit être redessiné toutes les n ms). Le Visiteur ne conviendrait pas à ce genre de situation puisqu'il visiterait toutes les objets (à moins qu'il n'y ait une variante que je ne connaisse pas).
L'astuce est que ce que tu visites c'est les evenements, pas la structure de ton GUI, tu ne visites meme qu'un seul element et le DP se reduit a une implementation du double dispatch dans un langage qui ne supporte que le simple. Tu peux avoir un cas simple ou le EventHandler (le visiteur) est capable de traiter tous les types d'evenements, ou un cas plus complexe ou tu as toute une hierarchie d'EventHandler suivant les types d'evenements qui sont traites.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Benoit Rousseau <not.provided@no.spam> writes:
Jean-Marc Bourguet wrote:
Benoit Rousseau <not.provided@no.spam> writes:
J'ai une classe Observer que l'on appelle par la fonction
notify(Event*) Il faut que je fasse ce genre de test pour
déterminer ce que je vais faire de mon Event*. Sinon, il faudrait
que je spécialise chacun des événements pour chacun des Observers
(une Factory pour chaque Observer ?) et ce serait beaucoup de
travail en plus...
La methode classique est celle du DP Visiteur, en attendant qu'on
ait du dispatch multiple. Il y a un certain nombre de variantes
qui supposent generalement qu'une des hierarchies est fermees
(celles des Event vraissemblablement dans ton cas).
Les Events sont envoyés pour signaler à la GUI qu'il y a eu une
modification sur l'un des objets qu'elle doit dessiner (un mur n'a
besoin d'être visité qu'une seule fois pendant toute la simulation ;
par contre un robot doit être redessiné toutes les n ms). Le
Visiteur ne conviendrait pas à ce genre de situation puisqu'il
visiterait toutes les objets (à moins qu'il n'y ait une variante que
je ne connaisse pas).
L'astuce est que ce que tu visites c'est les evenements, pas la
structure de ton GUI, tu ne visites meme qu'un seul element et le DP
se reduit a une implementation du double dispatch dans un langage qui
ne supporte que le simple. Tu peux avoir un cas simple ou le
EventHandler (le visiteur) est capable de traiter tous les types
d'evenements, ou un cas plus complexe ou tu as toute une hierarchie
d'EventHandler suivant les types d'evenements qui sont traites.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
J'ai une classe Observer que l'on appelle par la fonction notify(Event*) Il faut que je fasse ce genre de test pour déterminer ce que je vais faire de mon Event*. Sinon, il faudrait que je spécialise chacun des événements pour chacun des Observers (une Factory pour chaque Observer ?) et ce serait beaucoup de travail en plus...
La methode classique est celle du DP Visiteur, en attendant qu'on ait du dispatch multiple. Il y a un certain nombre de variantes qui supposent generalement qu'une des hierarchies est fermees (celles des Event vraissemblablement dans ton cas).
Les Events sont envoyés pour signaler à la GUI qu'il y a eu une modification sur l'un des objets qu'elle doit dessiner (un mur n'a besoin d'être visité qu'une seule fois pendant toute la simulation ; par contre un robot doit être redessiné toutes les n ms). Le Visiteur ne conviendrait pas à ce genre de situation puisqu'il visiterait toutes les objets (à moins qu'il n'y ait une variante que je ne connaisse pas).
L'astuce est que ce que tu visites c'est les evenements, pas la structure de ton GUI, tu ne visites meme qu'un seul element et le DP se reduit a une implementation du double dispatch dans un langage qui ne supporte que le simple. Tu peux avoir un cas simple ou le EventHandler (le visiteur) est capable de traiter tous les types d'evenements, ou un cas plus complexe ou tu as toute une hierarchie d'EventHandler suivant les types d'evenements qui sont traites.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
kanze
Benoit Rousseau wrote in message news:<3f8abd3e$0$28696$...
Jean-Marc Bourguet wrote:
Benoit Rousseau writes:
wrote:
2) on augmente le risque d'erreur à l'exécution, surtout si en maintenant le code on change la hiérarchie des classes : on est alors obligé de se "souvenir" que les portions du code qui utilisent RTTI dépendent de cette hiérarchie
Ça dépend comment on l'utilise. C'est sûr que du code genre : if ( typeid( *p ) == typeid( ClasseA ) ) { } else if ( typeid( *p ) == typeid( ClasseB ) { ... est à éviter.
Pourquoi est ce à éviter ? J'ai une classe Observer que l'on appelle par la fonction notify(Event*) Il faut que je fasse ce genre de test pour déterminer ce que je vais faire de mon Event*. Sinon, il faudrait que je spécialise chacun des événements pour chacun des Observers (une Factory pour chaque Observer ?) et ce serait beaucoup de travail en plus...
La methode classique est celle du DP Visiteur, en attendant qu'on ait du dispatch multiple. Il y a un certain nombre de variantes qui supposent generalement qu'une des hierarchies est fermees (celles des Event vraissemblablement dans ton cas).
Les Events sont envoyés pour signaler à la GUI qu'il y a eu une modification sur l'un des objets qu'elle doit dessiner (un mur n'a besoin d'être visité qu'une seule fois pendant toute la simulation ; par contre un robot doit être redessiné toutes les n ms). Le Visiteur ne conviendrait pas à ce genre de situation puisqu'il visiterait toutes les objets (à moins qu'il n'y ait une variante que je ne connaisse pas).
Comment est-ce que tu fais la liaison entre les listener et le générateur des évenemments ? Dans ce cas-ci, d'après le peu que tu as présenté, je vois deux solutions :
- Il y a des types d'évenemments différents (création initiale, mise à jour ou déplacement périodique). Et mur et robot s'inscrivent pour l'évenement « création » (ou affichage initial, ou ... ) ; seulement le robot s'inscrit pour mise à jour ou « déplacement périodique ». Je verais donc dans le générateur d'évenemments un éspèce de map : std::map< type_info const*, std::vector< Listener * >, ... > Le générateur (ou le dispatcheur) ne visite que les objets dans la liste correspondante.
- Il y a un évenemment périodique (dison « mise à jour ») ; les objets s'inscrivent selon la période qui leur intéresse : n ms pour les robots, infini pour les murs. Encore une fois, on ne visite que les objets intéressés.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Benoit Rousseau <not.provided@no.spam> wrote in message
news:<3f8abd3e$0$28696$ba620e4c@reader2.news.skynet.be>...
Jean-Marc Bourguet wrote:
Benoit Rousseau <not.provided@no.spam> writes:
kanze@gabi-soft.fr wrote:
2) on augmente le risque d'erreur à l'exécution, surtout si en
maintenant le code on change la hiérarchie des classes : on est
alors obligé de se "souvenir" que les portions du code qui
utilisent RTTI dépendent de cette hiérarchie
Ça dépend comment on l'utilise. C'est sûr que du code genre :
if ( typeid( *p ) == typeid( ClasseA ) ) {
} else if ( typeid( *p ) == typeid( ClasseB ) {
...
est à éviter.
Pourquoi est ce à éviter ?
J'ai une classe Observer que l'on appelle par la fonction
notify(Event*) Il faut que je fasse ce genre de test pour déterminer
ce que je vais faire de mon Event*. Sinon, il faudrait que je
spécialise chacun des événements pour chacun des Observers (une
Factory pour chaque Observer ?) et ce serait beaucoup de travail en
plus...
La methode classique est celle du DP Visiteur, en attendant qu'on
ait du dispatch multiple. Il y a un certain nombre de variantes qui
supposent generalement qu'une des hierarchies est fermees (celles
des Event vraissemblablement dans ton cas).
Les Events sont envoyés pour signaler à la GUI qu'il y a eu une
modification sur l'un des objets qu'elle doit dessiner (un mur n'a
besoin d'être visité qu'une seule fois pendant toute la simulation ;
par contre un robot doit être redessiné toutes les n ms). Le Visiteur
ne conviendrait pas à ce genre de situation puisqu'il visiterait
toutes les objets (à moins qu'il n'y ait une variante que je ne
connaisse pas).
Comment est-ce que tu fais la liaison entre les listener et le
générateur des évenemments ? Dans ce cas-ci, d'après le peu que tu as
présenté, je vois deux solutions :
- Il y a des types d'évenemments différents (création initiale, mise à
jour ou déplacement périodique). Et mur et robot s'inscrivent pour
l'évenement « création » (ou affichage initial, ou ... ) ; seulement
le robot s'inscrit pour mise à jour ou « déplacement périodique ».
Je verais donc dans le générateur d'évenemments un éspèce de map :
std::map< type_info const*, std::vector< Listener * >, ... >
Le générateur (ou le dispatcheur) ne visite que les objets dans la
liste correspondante.
- Il y a un évenemment périodique (dison « mise à jour ») ; les objets
s'inscrivent selon la période qui leur intéresse : n ms pour les
robots, infini pour les murs. Encore une fois, on ne visite que les
objets intéressés.
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Benoit Rousseau wrote in message news:<3f8abd3e$0$28696$...
Jean-Marc Bourguet wrote:
Benoit Rousseau writes:
wrote:
2) on augmente le risque d'erreur à l'exécution, surtout si en maintenant le code on change la hiérarchie des classes : on est alors obligé de se "souvenir" que les portions du code qui utilisent RTTI dépendent de cette hiérarchie
Ça dépend comment on l'utilise. C'est sûr que du code genre : if ( typeid( *p ) == typeid( ClasseA ) ) { } else if ( typeid( *p ) == typeid( ClasseB ) { ... est à éviter.
Pourquoi est ce à éviter ? J'ai une classe Observer que l'on appelle par la fonction notify(Event*) Il faut que je fasse ce genre de test pour déterminer ce que je vais faire de mon Event*. Sinon, il faudrait que je spécialise chacun des événements pour chacun des Observers (une Factory pour chaque Observer ?) et ce serait beaucoup de travail en plus...
La methode classique est celle du DP Visiteur, en attendant qu'on ait du dispatch multiple. Il y a un certain nombre de variantes qui supposent generalement qu'une des hierarchies est fermees (celles des Event vraissemblablement dans ton cas).
Les Events sont envoyés pour signaler à la GUI qu'il y a eu une modification sur l'un des objets qu'elle doit dessiner (un mur n'a besoin d'être visité qu'une seule fois pendant toute la simulation ; par contre un robot doit être redessiné toutes les n ms). Le Visiteur ne conviendrait pas à ce genre de situation puisqu'il visiterait toutes les objets (à moins qu'il n'y ait une variante que je ne connaisse pas).
Comment est-ce que tu fais la liaison entre les listener et le générateur des évenemments ? Dans ce cas-ci, d'après le peu que tu as présenté, je vois deux solutions :
- Il y a des types d'évenemments différents (création initiale, mise à jour ou déplacement périodique). Et mur et robot s'inscrivent pour l'évenement « création » (ou affichage initial, ou ... ) ; seulement le robot s'inscrit pour mise à jour ou « déplacement périodique ». Je verais donc dans le générateur d'évenemments un éspèce de map : std::map< type_info const*, std::vector< Listener * >, ... > Le générateur (ou le dispatcheur) ne visite que les objets dans la liste correspondante.
- Il y a un évenemment périodique (dison « mise à jour ») ; les objets s'inscrivent selon la période qui leur intéresse : n ms pour les robots, infini pour les murs. Encore une fois, on ne visite que les objets intéressés.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
