Discussion :

[Captain_JS]

Bonjour à tous,

Dans mon code, j'ai une classe filleAgent qui dérive de la classe Agent.
Cette filleAgent charge des dlls et me permet de récupérer des fonctions avec des pointeurs de fonction (voilà l'histoire histoire de faire un peu de contenu ).
Le truc maintenant c'est que mes classes Agent se chargent en appelant la classe filleAgent (singleton) afin de récupérer des pointeurs de fonction à partir de dll.

Jusque là pas de problème, sauf quand je mets ma classe filleAgent dans un autre projet : j'ai une référence circulaire ... le projet contenant "Agent" a besoin du projet contenant "filleAgent" qui a besoin du 1er projet ...

Y'a-t-il un moyen de faire compiler sans mettre les 2 classes dans le même projet (histoire d'être propre et lisible) ?

Merci

[Médinoc]

J'ai du mal à voir comment le projet contenant Agent a besoin de filleAgent...

[Captain_JS]

En fait il en a besoin parce qu'au chargement des classes "Agent", chaque classe va appeller "filleAgent" pour récupérer des méthodes dans des dlls

[nicroman]

Je comprends pas bien ton problême....
Ca sent l'erreur de conception à plein nez, mais je ne saurai l'affirmer... Tu peux nous montrer un exemple de code ?

Agent, filleAgent, c'est défini ou, ca fait quoi, c'est appelé comment...

[Captain_JS]

Bon ok, alors j'ai ma classe "Agent" :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
class IMPEXP cAgent {
public:
	cAgent (std::string Nom);
	~cAgent ();
 
	// Chargement / déchargement
	virtual cObjet* Load (std::string fileName);
	virtual cObjet* Save (std::string fileName);
 
	// Interventions extérieures
	virtual cObjet* Ask (std::string methodeName, cObjet *Argument);
 
protected:
	cListObjets *_Methodes;
};

Dans sa méthode "Load", chaque agent va lire un fichier XML et récupérer des noms de méthode.
A chaque nom correspond une fonction dans une Dll (développée à part pour plus de modularité).

Pour faire le lien entre les noms de fonction et les pointeurs sur fonction, j'ai la classe :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
class IMPEXP cFunctionPicker : public cAgent {
public:
	static cFunctionPicker* getInstance ();
	static void deleteInstance ();
 
	// Méthodes de connection avec les dlls
	cObjet* bindDll (std::string dllName);
	cObjet* releaseDll (std::string dllName);
 
	// Méthodes de récupération des fonctions
	Methode getMethode (std::string funcName, std::string dllName = "");
 
private:
	cFunctionPicker ();
	~cFunctionPicker ();
 
	static cFunctionPicker *_Instance;
};

Cette classe permet grâce à sa méthode "getMethode" de récupérer un pointeur sur fonction à partir d'une nom de fonction et d'un nom de Dll.
A la base cette classe ne dérivait pas de la classe "Agent", mais à terme je souhaiterais la faire dériver pour pouvoir exploiter divers processus non encore développés (notamment l'IA ...).

Si ces 2 classes étaient dans le même projet je n'aurais pas de problème, mais là j'ai une référence circulaire ...
Y'a-t-il un moyen de s'en sortir ?

[nicroman]

Je suis désolé... ca doit être moi... mais c'est vraiment pas clair...

qui instancie quoi ?

Si j'ai bien compris tu veux faire un système de plugins...
Mais je vois pas trop pourquoi tu te compliques autant la vie... Tu ne veux pas utiliser le mécanisme des DLLs, mais en fait si...

Une référence circulaire c'est à 99% de chance un problême de conception

[Captain_JS]

Si mettre 2 fichiers dans un projet (une Dll ici) au lieu d'un autre projet c'est un problème de conception alors oui s'en est un ...
Sur 6 posts y'en a 3 de moi, et 3 qui me disent que j'ai un problème de conception ... sans vraiment comprendre quel est mon problème ...
En plus j'ai du mal à comprendre comment je peux avoir une erreur de conception liée à l'éditeur que j'utilise ... donc en fait potentiellement je bascule sous Code::blocks et mon erreur de conception disparait.

Donc en fait je bascule mes 2 headers et mes 2 cpp dans un mêm projet et je regroupe les 2 projets qui m'ennuient en un seul et je tague en résolu ce post.

Merci beaucoup de votre aide et désolé d'être un peu agressif.

[Matthieu Brucher]

En plus j'ai du mal à comprendre comment je peux avoir une erreur de conception liée à l'éditeur que j'utilise ... donc en fait potentiellement je bascule sous Code::blocks et mon erreur de conception disparait.

?? Qui te parle d'éditeur ?? Cette erreur se produira aussi avec Code::Blocks, avec make, Scons, ... Sauf que pour CB, tu auras l'impression que ça marche, mais en fait pas du tout une fois que tu crées ton projet depuis rien du tout.

Si tu as une telle dépendance circulaire, c'est que tu as un problème de conception. Clair, net et précis. Remets les choses à plat. Regarde comment ton projet peut se passer de cette dépendance et refactore ton code.

[nicroman]

Le pire c'est que j'aimerai vraiment t'aider !

Mais d'une part les références circulaires indiquent que deux objets sont suffisemment liés pour qu'ils soient dans le même projet (si tu modifies l'un tu dois modifier l'autre)...
D'autre part, j'arrive pas à comprendre ce que tu veux faire...

Un plug-in ? => interfaces... pas de dépendance (sauf vers un header bien sur).
Sinon rien n'empêche une DLL de charger manuellement une autre DLL qui pointe sur elle (par exemple un moteur de jeu A.dll va charger un plugin B.dll qui utilise A.dll... mais ce n'est pas une référence circulaire ça... B pointe sur A, et pas A sur B), mais je ne crois pas que ce soit possible entre un .exe et une dll....

Mais comme je suis dans l'impossibilité de comprendre ce que tu veux vraiment faire (qui charge quoi, comment, avec un exemple)... difficile de répondre efficacement sauf que... si il y a référence circulaire... il y a problême de conception