J'ai essayé de développer une petite application mettant en oeuvre le
Design Pattern Etat (à titre d'exercice), mais je rencontre qques
difficultés (note : je travaille avec Visual C++ 6.0) :
Mon but est de modéliser le fonctionnement d'un feu rouge. J'ai donc
créé une classe MonFeuRouge, une classe Etat et trois classes
EtatRouge, EtatOrange et EtatVert.
Dans le fichier Stdafx.h (ou je place d'habitude les #include
nécessaire à tout le projet) j'ai placé :
b) Si je comprend bien le DP Etat, la classe MonFeuRouge doit avoir un
pointeur sur un objet Etat, et les trois Etats doivent avoir un
pointeur vers MonFeuRouge.
Dans ces conditions, dans quel ordre faut-il effectuer les #include
dans le fichier stdafx.h, puisque chaque classe doit connaitre l'autre
?
Merci de vos conseils ! :-)
--
L'IMAGINATION RENOUVELLE LES PROCESSUS STRATEGIQUES DES STRUCTURES
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Aurélien Barbier-Accary
Bonjour,
J'ai essayé de développer une petite application mettant en oeuvre le Design Pattern Etat (à titre d'exercice), mais je rencontre qques difficultés (note : je travaille avec Visual C++ 6.0) :
Mon but est de modéliser le fonctionnement d'un feu rouge. J'ai donc créé une classe MonFeuRouge, une classe Etat et trois classes EtatRouge, EtatOrange et EtatVert. Dans le fichier Stdafx.h (ou je place d'habitude les #include nécessaire à tout le projet) j'ai placé :
b) Si je comprend bien le DP Etat, la classe MonFeuRouge doit avoir un pointeur sur un objet Etat, et les trois Etats doivent avoir un pointeur vers MonFeuRouge.
Dans ces conditions, dans quel ordre faut-il effectuer les #include dans le fichier stdafx.h, puisque chaque classe doit connaitre l'autre ?
Merci de vos conseils ! :-)
Je n'ai pas tout bien compris mais si tu as 3 classes qui ressemble à ça :
alors dans ton fichier EtatRouge .cpp tu dois implémenter
void EtatRouge::ChangeEtat() et pas void ChangeEtat() // ^^^^^^^^^^^ // ^^^ { { //... ... } }
et faire de même dans tes fichiers EtatOrange.cpp et EtatVert.cpp puisque tu dois implémenter la méthode ChangeEtat *de la classe EtatRouge* (respectivement EtatOrange et EtatVert).
Pour la partie b) j'avoue que je ne comprends pas bien ta question mais j'espère que ceci te permettra déjà d'avancer.
Aurélien.
Bonjour,
J'ai essayé de développer une petite application mettant en oeuvre le
Design Pattern Etat (à titre d'exercice), mais je rencontre qques
difficultés (note : je travaille avec Visual C++ 6.0) :
Mon but est de modéliser le fonctionnement d'un feu rouge. J'ai donc
créé une classe MonFeuRouge, une classe Etat et trois classes EtatRouge,
EtatOrange et EtatVert.
Dans le fichier Stdafx.h (ou je place d'habitude les #include nécessaire
à tout le projet) j'ai placé :
b) Si je comprend bien le DP Etat, la classe MonFeuRouge doit avoir un
pointeur sur un objet Etat, et les trois Etats doivent avoir un pointeur
vers MonFeuRouge.
Dans ces conditions, dans quel ordre faut-il effectuer les #include dans
le fichier stdafx.h, puisque chaque classe doit connaitre l'autre ?
Merci de vos conseils ! :-)
Je n'ai pas tout bien compris mais si tu as 3 classes qui ressemble à ça :
alors dans ton fichier EtatRouge .cpp tu dois implémenter
void EtatRouge::ChangeEtat() et pas void ChangeEtat()
// ^^^^^^^^^^^ // ^^^
{ {
//... ...
} }
et faire de même dans tes fichiers EtatOrange.cpp et EtatVert.cpp puisque tu
dois implémenter la méthode ChangeEtat *de la classe EtatRouge* (respectivement
EtatOrange et EtatVert).
Pour la partie b) j'avoue que je ne comprends pas bien ta question mais j'espère
que ceci te permettra déjà d'avancer.
J'ai essayé de développer une petite application mettant en oeuvre le Design Pattern Etat (à titre d'exercice), mais je rencontre qques difficultés (note : je travaille avec Visual C++ 6.0) :
Mon but est de modéliser le fonctionnement d'un feu rouge. J'ai donc créé une classe MonFeuRouge, une classe Etat et trois classes EtatRouge, EtatOrange et EtatVert. Dans le fichier Stdafx.h (ou je place d'habitude les #include nécessaire à tout le projet) j'ai placé :
b) Si je comprend bien le DP Etat, la classe MonFeuRouge doit avoir un pointeur sur un objet Etat, et les trois Etats doivent avoir un pointeur vers MonFeuRouge.
Dans ces conditions, dans quel ordre faut-il effectuer les #include dans le fichier stdafx.h, puisque chaque classe doit connaitre l'autre ?
Merci de vos conseils ! :-)
Je n'ai pas tout bien compris mais si tu as 3 classes qui ressemble à ça :
alors dans ton fichier EtatRouge .cpp tu dois implémenter
void EtatRouge::ChangeEtat() et pas void ChangeEtat() // ^^^^^^^^^^^ // ^^^ { { //... ... } }
et faire de même dans tes fichiers EtatOrange.cpp et EtatVert.cpp puisque tu dois implémenter la méthode ChangeEtat *de la classe EtatRouge* (respectivement EtatOrange et EtatVert).
Pour la partie b) j'avoue que je ne comprends pas bien ta question mais j'espère que ceci te permettra déjà d'avancer.
Aurélien.
Aurélien Barbier-Accary
Dans ces conditions, dans quel ordre faut-il effectuer les #include dans le fichier stdafx.h, puisque chaque classe doit connaitre l'autre ?
Comme je l'ai dit précédemment je ne suis pas sûr de comprendre ta question mais peut-être que l'exemple simple ci-dessous pourra t'aider :
class cA { cB unB; //... };
class cB { cA unA; //... };
Quel que soit l'ordre de déclaration des classes, ça bloque. Pour résoudre ça on déclare juste le prototype de la classe C cB avant de définir cA comme suit :
class cB;
class cA { cB unB; //... };
class cB { cA unA; //... };
Le fait de définir les différentes classes dans différents fichiers .h ne change rien au problème ni à la solution. I faut juste bien penser (comme toujours) à mettre *tout le code* des .h entre des commandes :
J'espère ne pas être trop à côté de la plaque de tes interrogations. Si c'est le cas, désolé :-) Aurélien.
Dans ces conditions, dans quel ordre faut-il effectuer les #include
dans le fichier stdafx.h, puisque chaque classe doit connaitre l'autre ?
Comme je l'ai dit précédemment je ne suis pas sûr de comprendre ta question mais
peut-être que l'exemple simple ci-dessous pourra t'aider :
class cA
{
cB unB;
//...
};
class cB
{
cA unA;
//...
};
Quel que soit l'ordre de déclaration des classes, ça bloque.
Pour résoudre ça on déclare juste le prototype de la classe C
cB avant de définir cA comme suit :
class cB;
class cA
{
cB unB;
//...
};
class cB
{
cA unA;
//...
};
Le fait de définir les différentes classes dans différents fichiers .h ne change
rien au problème ni à la solution. I faut juste bien penser (comme toujours) à
mettre *tout le code* des .h entre des commandes :
Dans ces conditions, dans quel ordre faut-il effectuer les #include dans le fichier stdafx.h, puisque chaque classe doit connaitre l'autre ?
Comme je l'ai dit précédemment je ne suis pas sûr de comprendre ta question mais peut-être que l'exemple simple ci-dessous pourra t'aider :
class cA { cB unB; //... };
class cB { cA unA; //... };
Quel que soit l'ordre de déclaration des classes, ça bloque. Pour résoudre ça on déclare juste le prototype de la classe C cB avant de définir cA comme suit :
class cB;
class cA { cB unB; //... };
class cB { cA unA; //... };
Le fait de définir les différentes classes dans différents fichiers .h ne change rien au problème ni à la solution. I faut juste bien penser (comme toujours) à mettre *tout le code* des .h entre des commandes :
alors dans ton fichier EtatRouge .cpp tu dois implémenter
void EtatRouge::ChangeEtat() et pas void ChangeEtat() // ^^^^^^^^^^^ // ^^^ { { //... ... } }
et faire de même dans tes fichiers EtatOrange.cpp et EtatVert.cpp puisque tu dois implémenter la méthode ChangeEtat *de la classe EtatRouge* (respectivement EtatOrange et EtatVert).
Pour la partie b) j'avoue que je ne comprends pas bien ta question mais j'espère que ceci te permettra déjà d'avancer.
Aurélien.
OK, c'était bien le problème, merci.
-- Le comble de la prudence : Marcher sur les mains, de peur de recevoir une tuile sur la tête. [Alphonse Allais]
Si Aurélien Barbier-Accary ne nous l'avait pas dit, on n'aurait jamais
cru que
Je n'ai pas tout bien compris mais si tu as 3 classes qui ressemble à ça :
alors dans ton fichier EtatRouge .cpp tu dois implémenter
void EtatRouge::ChangeEtat() et pas void ChangeEtat()
// ^^^^^^^^^^^ // ^^^
{ {
//... ...
} }
et faire de même dans tes fichiers EtatOrange.cpp et EtatVert.cpp puisque tu
dois implémenter la méthode ChangeEtat *de la classe EtatRouge*
(respectivement EtatOrange et EtatVert).
Pour la partie b) j'avoue que je ne comprends pas bien ta question mais
j'espère que ceci te permettra déjà d'avancer.
Aurélien.
OK, c'était bien le problème, merci.
--
Le comble de la prudence :
Marcher sur les mains, de peur de recevoir une tuile sur la tête.
[Alphonse Allais]
alors dans ton fichier EtatRouge .cpp tu dois implémenter
void EtatRouge::ChangeEtat() et pas void ChangeEtat() // ^^^^^^^^^^^ // ^^^ { { //... ... } }
et faire de même dans tes fichiers EtatOrange.cpp et EtatVert.cpp puisque tu dois implémenter la méthode ChangeEtat *de la classe EtatRouge* (respectivement EtatOrange et EtatVert).
Pour la partie b) j'avoue que je ne comprends pas bien ta question mais j'espère que ceci te permettra déjà d'avancer.
Aurélien.
OK, c'était bien le problème, merci.
-- Le comble de la prudence : Marcher sur les mains, de peur de recevoir une tuile sur la tête. [Alphonse Allais]
ByB
Mieux que du Shakespeare, c'est le message de Aurélien Barbier-Accary qui affirme :
Dans ces conditions, dans quel ordre faut-il effectuer les #include dans le fichier stdafx.h, puisque chaque classe doit connaitre l'autre ?
Comme je l'ai dit précédemment je ne suis pas sûr de comprendre ta question mais peut-être que l'exemple simple ci-dessous pourra t'aider :
class cA { cB unB; //... };
class cB { cA unA; //... };
Quel que soit l'ordre de déclaration des classes, ça bloque. Pour résoudre ça on déclare juste le prototype de la classe C cB avant de définir cA comme suit :
class cB;
class cA { cB unB; //... };
class cB { cA unA; //... };
Le fait de définir les différentes classes dans différents fichiers .h ne change rien au problème ni à la solution. I faut juste bien penser (comme toujours) à mettre *tout le code* des .h entre des commandes :
J'espère ne pas être trop à côté de la plaque de tes interrogations. Si c'est le cas, désolé :-) Aurélien.
C'était bien cela également, merci ! :-)
-- Championnat du millimètre à vélocipède : record mondial actuellement détenu par le Captain Cap en 1/17.000ème de seconde (Alphonse Allais)
Mieux que du Shakespeare, c'est le message de Aurélien Barbier-Accary
qui affirme :
Dans ces conditions, dans quel ordre faut-il effectuer les #include dans
le fichier stdafx.h, puisque chaque classe doit connaitre l'autre ?
Comme je l'ai dit précédemment je ne suis pas sûr de comprendre ta question
mais peut-être que l'exemple simple ci-dessous pourra t'aider :
class cA
{
cB unB;
//...
};
class cB
{
cA unA;
//...
};
Quel que soit l'ordre de déclaration des classes, ça bloque.
Pour résoudre ça on déclare juste le prototype de la classe C
cB avant de définir cA comme suit :
class cB;
class cA
{
cB unB;
//...
};
class cB
{
cA unA;
//...
};
Le fait de définir les différentes classes dans différents fichiers .h ne
change rien au problème ni à la solution. I faut juste bien penser (comme
toujours) à mettre *tout le code* des .h entre des commandes :
Mieux que du Shakespeare, c'est le message de Aurélien Barbier-Accary qui affirme :
Dans ces conditions, dans quel ordre faut-il effectuer les #include dans le fichier stdafx.h, puisque chaque classe doit connaitre l'autre ?
Comme je l'ai dit précédemment je ne suis pas sûr de comprendre ta question mais peut-être que l'exemple simple ci-dessous pourra t'aider :
class cA { cB unB; //... };
class cB { cA unA; //... };
Quel que soit l'ordre de déclaration des classes, ça bloque. Pour résoudre ça on déclare juste le prototype de la classe C cB avant de définir cA comme suit :
class cB;
class cA { cB unB; //... };
class cB { cA unA; //... };
Le fait de définir les différentes classes dans différents fichiers .h ne change rien au problème ni à la solution. I faut juste bien penser (comme toujours) à mettre *tout le code* des .h entre des commandes :
