Namespace, PO et Visual C++

Namespace, PO et Visual C++ - C++ - Programmation

Marsh Posté le 01-10-2008 à 19:35:25    

Bonjour,
 
Le sujet peut parraitre tres confus, c est parce que la question ou les questions touchent differents problemes.
 
Contexte: Je suis en train de creer un jeu video, composé de 2 composants le jeu en lui meme (framework de jeu) et  l affichage. Je peux choisir soit un affichage avec openGl soit avec DirectX. L affichage doit implementer une interface pour se brancher avec le jeu. Afin de choisir quel affichage j utilise son namespace correspondant.
Concretement il y a le namespace DX et GL qui definnissent les meme objets qui sont : Object3D, Object2D, Font, View et Controler. Dans un fichier config.h j utililise

Code :
  1. using namespace DX;

ou

Code :
  1. using namespace GL;

 pour avoir l affichage avec openGl ou DirectX.
 
Probleme 1: Je travaille avec VisualC++ lorsqu il me genere Object3D.obj de DirectX il ne cherchera plus a me generer Object3D.obj de OpenGL pour simple raison qu il ne peut pas creer de fichier identique dans Debug. Ils ont le meme nom car  MonObject3DAMoi derrive de Object3D. Il y a t il un moyen de generer les fichier obj dans une sous arborescence de Debug?
 
Probleme 2: Ma solution ne me convient entierement car quand je developpe je n ai pas envie que MonObject3DAMoi connaisse DirectX et OpenGL hors dans le fichier MonObject3DAMoi.h il y a un

Code :
  1. #include "GL/Object3D.h"

et de

Code :
  1. #include "DX/Object3D.h"

.
La solution qui consiste a placer des macro partout dans le code du genre

Code :
  1. #ifndef GL

est trop ancestral et ne me convient pas non plus.  
Amateur de programation objet un solution serait apprecie pour ce probleme.
 
Je vous remercie,
 
 
Vincent

Reply

Marsh Posté le 01-10-2008 à 19:35:25   

Reply

Marsh Posté le 01-10-2008 à 20:05:19    

passe plutot par des lib dynamique qui sont chargés au runtime.

Message cité 1 fois
Reply

Marsh Posté le 02-10-2008 à 18:40:09    

Joel F a écrit :

passe plutot par des lib dynamique qui sont chargés au runtime.


 
J'y avais pensé également, mais je ne sais pas si cette solution me convient réellement. J'attendais plutot une réponse qui parle d'interface. En fait elle pourrais me convenir si:
 
Je définis une interface InterfaceAffichage::Object3D qui implémente DX::Object3D et GL::Object3D
 
Interface:

Code :
  1. class Object3D {
  2. void dessine() = 0;
  3. float* getVertex()=0;
  4. };


 
 
Dans le jeu:

Code :
  1. #include "InterfaceAffichage/Object3D.h"
  3. class MonObjet3DAMoi : public Object3D{
  5. float* getVertex();
  7. };


 
Dans DX::Object3D:

Code :
  1. #include "InterfaceAffichage/Object3D.h"
  3. namespace DX {
  4. class Object3D: public Object3D {
  6. void dessine();
  7. float* getVertex()=0;
  9. };
  10. }


 
Dans GL::Object3D:

Code :
  1. #include "InterfaceAffichage/Object3D.h"
  3. namespace GL {
  4. class Object3D: public Object3D {
  6. void dessine();
  7. float* getVertex()=0;
  9. };
  10. }


 
Avec un tel principe il faudrait qu'à la compilation il utilise InterfaceAffichage/Object3D.h puis ensuite lors de l'exécution qu'il utilise le Object3D de DX si c'est cette DLL qui est utilisé.
 
 
NB 1: Les Dlls DX et GL contiennent des classes abstraitent est ce un probleme?
NB 2: Si je fais comme ca la compilation échouera certainement avec un message du style:  MonObjet3DAMoi ne peut être instancié car il contient une méthode abstraite "dessine()";  
 
 
Est ce qu une telle solution semble possible? comment résoudre les éventuels problèmes? Une autre solution, laquelle?
 
Merci,
 
Vincent
 

Reply

Marsh Posté le 02-10-2008 à 19:21:52    

C'est la bonne solution :o


---------------
Python Python Python
Reply

Marsh Posté le 02-10-2008 à 20:46:23    

exactement ce que je disais plus haut :o

Reply

Marsh Posté le 04-10-2008 à 00:54:02    

Vous etes serieux???!!!!
 
Vous ne faite aucun commentaire!! Je vais essayer mais je n y crois pas, ca ne compilera meme pas cf NB2.
 
En tout cas j aime bcp mon idee meme si je n y crois pas...

Reply

Marsh Posté le 04-10-2008 à 11:13:38    

Euh je vois pas ou est ton problem.
Tu compile sun DLL GL et un DLL D3D qui exporte les mêmes interfaces et tu charge celui qui faut dynamiquement. Y a des millions de soft qui fonctionnent comme ça.

Reply

Marsh Posté le 04-10-2008 à 18:39:07    

En fait ce qui me posait probleme (cf NB2), c'est de pouvoir compiler avec des instance de classe abstraites, ce qui n'est pas possible, j'ai cru comprendre hier soir que lorsque on développe en utilisant une dll on fait référence à la dll pour le compilateur ce qui implique que le compilateur saura que les méthodes de mon interface sont implémentés dans la dll...
 
Ceci dit, a mon avis il est strictement impossibe de compiler ca:
 
   

Code :
  1. 1. class Object3D {
  2.    2. void dessine() = 0;
  3.    3. float* getVertex()=0;
  4.    4. };


 
 

Code :
  1. 1. #include "InterfaceAffichage/Object3D.h"
  2.    2.
  3.    3. class MonObjet3DAMoi : public Object3D{
  4.    4.
  5.    5. float* getVertex();
  6.    6.
  7.    7. };


 

Code :
  1. MonObjet3DAMoi monObjet3DAMoi;


 
 
Bon, pour le moment je ne suis pas foutu d'utiliser une Dll, je te donnerais des nouvelles plus tard...
 
Dans tous les cas merci,


Message édité par smallGame le 04-10-2008 à 19:46:52
Reply

Marsh Posté le 05-10-2008 à 02:28:20    

Si tu as besoin de déclarer ton objet MonObject3DAMoi sans avoir implémenté la méthode dessine(); ça veut dire que ta conception est incorrecte.

Reply

Marsh Posté le 05-10-2008 à 09:55:29    

en effet je pense que t'as pas compris la notion de classe abstraite ni celle de dll ...

Reply

Marsh Posté le 05-10-2008 à 09:55:29   

Reply

Marsh Posté le 06-10-2008 à 21:59:37    

Je ne suis pas d accord je pense que j ai bien integre la notion de classe abstraite, celui de Dll j´avoue que je ne suis pas familiarise du tout avec.
 
Mais bon comme les reponse sont courtes et pas claire j essaie des interprete du mieux que je peux...  
 
Je vais vous dire en quoi j en suis reduit maintenant parce que je n arrive pas a resoudre ce probleme et que je ne veux pas y perdre trop de temps....
 
J ai un repertoire openGL un repertoire DirectX et un repertoire diplayer, le projet utilise le repertoire displayer.  
 
Lorsque je souhaite compiler avec DirectX je copy colle les fichier DirectX dans Displayer et reciproquement pour openGl...
 
Cést moche, je sais si j arrivais a creer mes .obj dans des repertoires en fonction des namespace je n aurais plus de pb.
 
 
Vincent

Reply

Marsh Posté le 07-10-2008 à 08:32:15    

Je n'ai pas lu :o Mais je pense que ça répond parfaitement à ton problème :
 
http://www.nuclex.org/articles/bui [...] chitecture
 
C'est comme ça et pas autrement. nah :o


---------------
Python Python Python
Reply

Marsh Posté le 07-10-2008 à 08:44:47    

C'est *exactement* la page que je cherchais pour la montrer à smallGame !
Merci BenO

Reply

Marsh Posté le 11-10-2008 à 17:39:29    

Bonjour à tous,
 
Apres ma deuxième réponse à ce post, je ne savais pas trop comment marché les dll, une réponse du style, oui c est ca mais il faut rajouter pour DX et GL

Code :
  1. class __declspec(dllexport) Object3D

et pour Mon pseudo interface

Code :
  1. class __declspec(dllimport) Object3D

m'aurais directement éclaircis.
 
Merci à Joel et à BenO pour votre aide et l'apport des dlls dans mon projet, je n'ai pas eu de mal à les integrer la conception de mon projet étant un jolie MVC. Ceci dit peut etre pas si jolie que ca:
 
J'ai toujours eu l'habitude et je n'ai jamais entendu dire que c'était mal que le M connaisse le V et le C et réciproquement V et C connaissent M. Cependant avec les dll je crois avoir compris que C et V étant la dll ne devaient pas connaitre M et ne devait pas faire de référence à M:
 
Par exemple j'ai fait:
 

Code :
  1. void View::display(Game* game){
  3. this->clearScreenColor(game->getColorToClear());
  5. ....
  7. }


 
Apparemment ca ne fonctionne pas car View et dans  V (dll) et Game et dans M (exe)
 
Je suppose donc qu il faut remplacer le code ci dessus par :
 

Code :
  1. void Game::display(View* view){
  3. view->clearScreen(this->getColorToClear());
  5. ....
  7. }


 
Me trompe-je?
 
Voila sinon j'ai eu un peu de mal à compiler à cause de

Code :
  1. MonConstructeur(void)

n'était pas reconnu il préférait

Code :
  1. MonConstructeur()


mais pourquoi pas une  
C'est fou quand même que je ne connaissais pas les dll, c'est vraiment pratique, j'ai envie de diviser tout monde avec des dll :), notement une pour la partie reseau si je fait un client 2D...
Et sous Linux c'est pareil??  
 
Merci encore...
 
 
 
 
 

Reply

Marsh Posté le 11-10-2008 à 18:36:40    

Sous linux, c'ets presque pareil. Mates du coté des .so ;) Y a qqs facilités vis à vis de WIn32.
 
Par contre je suis pas fan d'exporter des classes. Je prefere exporter des fonctions qui générent des instances de mes classes. Aprés c'ets chacun son truc ;)

Message cité 1 fois
Reply

Marsh Posté le 12-10-2008 à 18:33:47    

Juste par curiosité pourquoi ?
Quelle est pour toi la différence de passer par une fonction plutôt que d'accéder à la classe directement ?

Reply

Marsh Posté le 12-10-2008 à 19:04:43    

Exporter une fonction qui renvoit un pointeur vers une classe avec une interface correcte permets de rendre les appels indépendants de la dite classe. Ca permet aussi de rentrer propremeent dans un Design Pattern de type factory voire abstarctFactory.

Reply

Marsh Posté le 12-10-2008 à 23:21:34    

Oui mais tu es dépendant des appels de tes fonctions donc c'est pareil.
 
Et je ne vois pas non plus l'avantage pour le factory. T'aurais pas un exemple ?
 
Enfin bon, c'est du pinaillage sans grand intérêt ça ne vaut peut être pas le coup de poursuivre  :o

Reply

Marsh Posté le 13-10-2008 à 08:37:27    

J'ai pas d'exemple sous la main. Mais bon, c'est un reste de mes habitudes à l'époque ou VC6 se chiait dessus à l'export de classe. Si aujourd'hui ça passe mieux, go ;)

Message cité 1 fois
Reply

Marsh Posté le 13-10-2008 à 23:38:37    

Joel F a écrit :

c'est un reste de mes habitudes à l'époque ou VC6 se chiait dessus à l'export de classe. Si aujourd'hui ça passe mieux, go ;)


 
La justement, pour moi ca chie bien comme il faut, je vais essayé de faire un exemple simplifier, pour vous le montrer, mais en gros j ai ma classe Object3D avec deux methodes abstraite differentes signature, en mode debug j ai observe que le progamme rentré dans la mauvaise, c est a ne rien y comprendre
 

Code :
  1. class Object3D {
  3. protected:
  4. void createVertex(Vertex* vertex) = 0;
  5. bool useTransparancy() = 0;
  7. }
  9. void Object3D::initialize() {
  11. createVertex(vertex); // !!!!!!! a ce moment la je rentre dans la methode useTransparency de sa mère !!!!!
  12. }


 
 
C'est à rien y comprendre je deviens fou, je n'arriverrai donc jamais à faire une Dll !!! (crie de désespoir!!)

Reply

Marsh Posté le 14-10-2008 à 00:28:43    

Heu, c'est moi ou ta classe dérive de rien ?
Sinon, en admettant que c'est une erreur de copier/coller, tu peux nous donner la définition de la classe mère ?
Et depuis où appelles tu ta méthode initialize ?

Message cité 1 fois
Message édité par SquiZZ le 14-10-2008 à 00:29:47
Reply

Marsh Posté le 14-10-2008 à 00:48:07    


 
Voici le message que j ai lors de l execution:
 

Citation :

Run-Time Check Failure #0 - The value of ESP was not properly saved across a function call.  This is usually a result of calling a function declared with one calling convention with a function pointer declared with a different calling convention.


 
 
J'ai réalisé un petit exemple et il est rentré dans la bonne méthode... Bon je crois qu avec Visual C++ 2008 ca chie aussi...
 
 

Reply

Marsh Posté le 14-10-2008 à 00:50:57    

SquiZZ a écrit :

Heu, c'est moi ou ta classe dérive de rien ?
Sinon, en admettant que c'est une erreur de copier/coller, tu peux nous donner la définition de la classe mère ?
Et depuis où appelles tu ta méthode initialize ?


 
 
Non en fait je n ai rien copier-coller j ai juste ecrit du pseudo code pour expliquer ce qui plante et pourquoi....
 
Je pensais que c etait claire, je n ai aucun probleme d'heritage classe ou methode abstraite, interface etc.... C est juste un probleme de DLL.

Reply

Marsh Posté le 14-10-2008 à 01:01:30    

Bon si tu veux je te donne le petit exemple que j ai codé pour clarifier:
 
 
Dans la DLL: Fichier Object3D.h
 

Code :
  1. #include <string>
  3. using namespace std;
  5. class __declspec(dllexport)Object3D {
  7. private:
  8. int x,y, radius;
  10. public:
  11.  Object3D();
  12. virtual ~Object3D();
  14. virtual void getPerimeter();
  15. virtual void calculateJustForDX();
  16. virtual void initialize();
  18. protected:
  20. virtual string getTextureFile() = 0;
  21. virtual bool needToCalculateNormal() = 0;
  25. };


 
Fichier Object3D.cpp:
 

Code :
  1. #include <iostream>
  3. using namespace std;
  6. #include "Object3D.h"
  8. Object3D::Object3D(): x(5), y(5), radius(5) {
  10. }
  12. Object3D::~Object3D() {
  14. }
  16. void Object3D::getPerimeter() {
  18. float p = 2 * 3.14f * radius;
  19. calculateJustForDX();
  20. cout<<p<<endl;
  22. }
  24. void Object3D::calculateJustForDX() {
  26. }
  28. void Object3D::initialize() {
  30. string fileToLoad = getTextureFile();
  32. }


 
Dans le projet principale: Fichier Object3D.h
 
 

Code :
  1. #include <string>
  3. using namespace std;
  5. class __declspec(dllimport)Object3D {
  7. public:
  8.  Object3D();
  9. virtual ~Object3D();
  11. virtual void getPerimeter();
  12. virtual void calculateJustForDX();
  13. virtual void initialize();
  15. protected:
  17. virtual string getTextureFile() = 0;
  18. virtual bool needToCalculateNormal() = 0;
  22. };


 
Fichier Terrain.h
 
 

Code :
  1. #pragma comment (lib, "MaDll.lib" )
  2. #include "Object3D.h"
  4. class Terrain : public Object3D {
  5. public:
  6. Terrain();
  7. ~Terrain();
  8. void getPerimeter();
  10. protected:
  12. virtual string getTextureFile();
  13. virtual bool needToCalculateNormal();
  15. };


 
 
Dans Terrain.cpp
 

Code :
  1. #include "Terrain.h"
  2. #include <iostream>
  5. using namespace std;
  7. Terrain::Terrain():Object3D()
  8. {
  9. }
  11. Terrain::~Terrain()
  12. {
  13. }
  15. void Terrain::getPerimeter() {
  17. cout<<"Terrain::"<<endl;
  18. Object3D::getPerimeter();
  19. }
  22. string Terrain::getTextureFile(){
  23. return "terrain.bmp";
  24. }
  25. bool Terrain::needToCalculateNormal() {
  26.  return true;
  27. }


 
 
Dans main.cpp:
 
 

Code :
  1. #pragma comment (lib, "MaDll.lib" )
  3. #include "Terrain.h"
  5. #include <iostream>
  7. using namespace std;
  9. int main() {
  11.  Terrain* terrain = new Terrain();;
  13. terrain->initialize(); // La ne se situe pas de PB, mais dans mon vrai projet OUI
  15. terrain->getPerimeter();
  17. char c;
  18. cin>>c;
  20. return 0;
  21. }


 
 
 
 
Bon c est vraiment le bordel ce code,  c est pour ca que je ne voulais pas le mettre en il y a un message d erreur lorsque son execution se termine.
 
Voila tu l as mon code.
 
 
 

Message cité 1 fois
Reply

Marsh Posté le 14-10-2008 à 01:08:08    

smallGame a écrit :


Voila tu l as mon code.


Si tu veux tu peux te le garder ton code.
Sinon, pour essayer de faire avancer le problème quand même, et même si je ne pratique pas l'export de classes pour des motifs personnels, new s'utilise comme  ça quand il  n'y a pas de paramètres :

Code :
  1. Terrain* terrain = new Terrain;


Message édité par SquiZZ le 14-10-2008 à 01:09:44
Reply

Marsh Posté le 14-10-2008 à 01:19:55    

Attend pourquoi tu me réponds comme ca??? c 'était pas méchant le "Voila tu l as mon code", c est juste que c est du code de test un peu merdique.... c est tout...

Reply

Marsh Posté le 14-10-2008 à 02:09:10    

Joel F a écrit :


Par contre je suis pas fan d'exporter des classes. Je prefere exporter des fonctions qui générent des instances de mes classes. Aprés c'ets chacun son truc ;)


 
 
Dans mon cas ca ne peut pas marcher car j'ai besoin des classes, non d'une instance car j'ai un héritage...
 
MonGameObject du jeu hérite de Object3D de la dll....

Message cité 1 fois
Reply

Marsh Posté le 14-10-2008 à 08:44:57    

smallGame a écrit :


Dans mon cas ca ne peut pas marcher car j'ai besoin des classes, non d'une instance car j'ai un héritage...


 
[:prozac]
Revois tes bases du langage stp :D

Reply

Marsh Posté le 14-10-2008 à 16:35:25    

Je crois que tu n'as pas compris ce que j'ai dit, où a quoi je fais allusion...
 
Le factory est un design pattern qui te renvoie une instance de classe en fonction des paramètres que tu lui donnes... Le type statique de la classe qui te renvoie serra toujours le meme et le type dynamique dépendra des paramètres... C'est pas ca pour toi??? Je ne vois pas ce qui te fait rire....

Reply

Marsh Posté le 14-10-2008 à 17:30:03    

Mates AbstractFactory ;)

Reply

Marsh Posté le 14-10-2008 à 17:44:08    

Non, mais là je crois que tu n'as pas compris ce que je voulais dire, l'abstract factory c'est le même probleme moi...
 
J'ai rien contre et j'aime bien les deisgn pattern, mais dans ma conception actuelle je ne peux rien faire de tout ca car Object3D qi est une classe de la DLL est hérité par Terrain qui est dans l'application, donc Factory ou AbstractFactory ne peuvent pas s'appliquer dans mon cas...
 
Mais là je pense que de toute facon je vais faire un refactoring, revoir la conception de mon projet pour intégrer les DLL à la AbstractFactory facon.
 
Je pense que comme tu le disais les importDll de classe merde, surtout quand elles ont des méthodes abstraites, ca ne doit pas être au point, je ne vois aucune auter explication.

Reply

Marsh Posté le 14-10-2008 à 17:47:04    

Petite question pour hellbilly:
 
Tu as l'air de connaitre es import dll de classe:
- Tu as déjà importer une classe qui as des méthodes abstraites? tu n'as eu aucun problème?

Message cité 1 fois
Reply

Marsh Posté le 14-10-2008 à 19:59:00    

Tu ne devrais aps herité d'une classe dans la DLL.
Ta dll devrais te fournir tes classes Terrains etc...
 
C'ets comme ça que c'est sensé marcher

Reply

Marsh Posté le 14-10-2008 à 22:10:00    

smallGame a écrit :

Petite question pour hellbilly:
 
Tu as l'air de connaitre es import dll de classe:
- Tu as déjà importer une classe qui as des méthodes abstraites? tu n'as eu aucun problème?


oui et j'ai pas de soucis.
 
J'ai pas trop le temps de voir ton problème mais juste quelques remarques en balayant ton code:
- vire les using namespace dans tes headers
- pourquoi tu as deux headers différents pour la même classe ?
Fais plutôt ça :

Code :
  1. #if defined(MYPROJECT_EXPORTS)
  2. #   define MYPROJECT_API __declspec(dllexport)
  3. #else
  4. #   define MYPROJECT_API __declspec(dllimport)
  5. #endif
  7. class MYPROJECT_API Object3D { ... };


 
 
Et comme l'a dit Joel F, c'est à ta lib de te fournir les bons objets dont ton application a besoin.
 
EDIT: en fait non j'importe pas de classe avec des méthodes abstraites


Message édité par hellbilly le 14-10-2008 à 22:11:21
Reply

Marsh Posté le 15-10-2008 à 19:03:25    

Mes header sont différents car il y a des membres et méthodes utilisé par par la dll en interne, que l'application ne doit pas connaitre, exemple:
 
Object3D de DX connait D3Device que Object3D de l'appli ne doit pas connaitre.
 
Ma lib me fournit les bonnes "classes" dont mon application a besoin... Pas de soucis la dessus.
 Je dit classe et non objet car ObjetDeMonApplication hérite de Object3D de la dll.
 
Merci quand meme.

Reply

Marsh Posté le 15-10-2008 à 19:06:06    

c'est justement ca qui est incorrect v_v

Reply

Marsh Posté le 15-10-2008 à 21:42:01    

Bonjour le mal de crane avec tes headers.
 
Je comprends pas pourquoi ta dll ne retourne pas un objet indépendant de l'api graphique.
 
Dans ta dll, tu implémentes ta classe Object3D et les classes DXObject3D et GLObject3D qui héritent de Object3D. Ta dll retourne à ton appli un objet Object3D via un factory par ex et c'est tout.

Reply

Marsh Posté le 15-10-2008 à 22:36:59    

Oui je sais bien et je comprend bien que ça résoudrait sûrement tous mes problèmes Abstract Factory ou Factory, mais voilà ca me demande un gros refactoring...
 
C'est claire que ce que tu dis me semble  très bien, juste j'aurais voulu  savoir pourquoi ca ne marche pas avec des méthodes abstraite dans la dll...
 
De toute facon je vais le faire l'abstract factory ca me semble mieux...
 
Merci,

Reply

Marsh Posté le 16-10-2008 à 10:18:13    

ca n'a PAS DE SENS d'avoir des méthodes abstraites dans une DLL. Une méthode abstraite par définition n'a pas de corps ...

Reply

Marsh Posté le 16-10-2008 à 16:29:28    

Je sais bien qu'une méthode abstraite par définition n'a pas de corps;
 
Et je t'assure que j'ai trouvé un sens à mettre une méthode abstraite dans une DLL, peut etre parce que ma conception était faite avant d'introduire les DLL dans mon projet.

Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed