Probleme de redefinition de type

Salut tout le monde !!

J'ai un petit probleme je veux choisir un de deux fichiers headers à inclure lors de l'execution parce que si je les inclus en meme temps j'aurais une erreur lors la compilation de redefinition de variable.

En fait le probleme se pose de cette facon: J'ai 2 classes AffichageConsole et AffichageGraphique. Au debut l'utilisateur choisit le type d'affichage et selon son choix j'inclut le header approprié .

La solution se trouve dans les macros c'est bien ca ??

hein?? Mais à l'execution tu n'a plus de fichier header ou cpp tu n'a plus que le exe. Tu veux dire à la compilation? Dans ce cas tu peux utiliser les macros dans le code effectivement.

Code:

---

1 2 3 4 5 6 7 8 9 10

// #define GUI // Enlever les comments pour affiche l'interface graphique   #ifdef GUI #include "AffichageGraphique.h"   #else #include "AffichageConsole.h"   #endif

---

Sinon il faut implémenter ça si tu veux que l'utilisateur choisisse à l'exécution.

oui je sais ce n'est pas logique ce que je dis mais c'est comme ca mais et je crois qu'il n'y a pas de solution .

La solution telle que tu l'a ecrite ne permet pas de choisir le mode graphique à l'execution !!

En fait je crois qu'il faut que refait la conception de mes classes d'affichages pour que je puisse les inclure en meme temps !!!

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

enum etatAffichage { caseFerme, caseInterrogation, caseIlYaBombe, caseBlanc   };   class AffichageGraphique { public: //methodes private: //mon etat   };

---

le enum est aussi declaré dans la classe AffichageConsole, si je les inclu toutes les 2 j'aurais une erreur de compilation de redefinition du type enum

Que faire !!!

Si tu pense que c'est faisable, c'est que tu n'a vraiment pas compris le principe de la compilation. Mais heureusement, ce n'est pas une maladie grave, on en guéri très bien : http://www.developpez.com/c/megacours/x2392.html (par exemple).

Non !! J'ai pas dis que c'est faisable au contraire c'est pour ca que j'ai dit qu'il faut revoir la conception de mes classes
Merci comme meme pour le lien !!!

dans le sens de revoir la conception de tes classes tu peux faire une classe mère (abstraite?) de laquelle va hériterer tes classes console et graphiques et gérer le choix soit par argument de la ligne de commande soit par une boite de dialogue qui demande le mode (graphiquie/console) en fonction du choix tu crée l'objet

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

class Affichage { public: //methode et proprieté de l'interface virtual Methode1() = 0; }   class AffichageGraphique : public Affichage { public: virtual Methode1() { // ....... } }   class AffichageConsole : public Affichage { public: virtual Methode1() { // ....... } }   Affichage* pAffichage;   int main(int argc, char *argv[]) { if((*argc[0])=='g') pAffichage = new AffichageGraphique(); else pAffichage = new AffichageConsole(); . . . }

---

Citation:

---

Envoyé par mehdi_tn

Code:

---

1 2 3 4 5 6 7 8 9

enum etatAffichage { caseFerme, caseInterrogation, caseIlYaBombe, caseBlanc   };

---

le enum est aussi declaré dans la classe AffichageConsole, si je les inclu toutes les 2 j'aurais une erreur de compilation de redefinition du type enum

---

Qu'est-ce qui t'empêche de définier cette enum dans un .h unique qui sera inclus dans tes deux .h. Les include guards de ce .h unique empêcherons l'inclusion multiple.

Et hop je change le topic

merci deja d'avoir repondu !!!

Je pense que le projet est mal concu à la base. Parce que si un jour je veux ajouter un autre mode d'affichage je dois ajouter une autre instance de la nouvelle classe qui supporte le nouveau mode d'affichage, ce qui n'est pas bien du tout. L'idee de Rely n'est pas mal et elle ressemble au design pattern "Abstract Factory" je vais converger vers cette solution et commencer à re-structurer les classes

Je vous mes au courant si cette solution fonctionne bien dans ce cas ou non !!!

En fait ca n'a rien à voir avec le design pattern que j'ai signalé, mais plutot utiliser des classes abstraites et instancier selon le mode comme l'a dit Rely. Un probleme banal de conception :oops:

Ca marche 8)