Référeces croisées : pb d'oeuf et de poule

Bonjour, dans quelle direction chercher pour :
creer 2 classe A et B, ecrites dans 2 fichiers differents, avec des includes sachant que A a besoin de connaitre B et B a besoin de connaitre A.

monA est initialement crée avec des int, char... (clasique)
#include "A.h"
A monA(1,2,3);

monB à partir de l'adresse de monA
#include "B.h"
B monB(& monA);

monAbis à partir de l'adresse de monB
A monAbis(& monB); -> là est le probleme puisque il faudrait que "B.h" soit deja inclu
c'est l'histoire de l'oeuf et de la poule

je me rapelle vagement qu'en cours on avait le droit de faire
void * monA;
je fais fausse route ?

:faq:

je susi pas un expert mais il me semble que tu peux predeclarer l'existence d'une classe tierce dans le fichier .h de ta classe courante. Tu n'as pas besoin de faire le #include. tu le feras dans le cpp.

Exemple :

Code:

---

1 2 3 4 5 6 7

class A;   class B{ ... void ma fonction(A &monA) };

---

qqchose comme ça...:roll:

Merci titoo ! C'est tout à fait ça !

http://cpp.developpez.com/faq/cpp/?p...erence_croisee

Salut,

Il y a deux problèmes dans ce que tu pose comme question...

Le premier a trait à la dépendance croisée (a qui a besoin de b qui a lui meme besoin de a), et, pour cela, la FAQ répond correctement ;)

Le deuxième est qu'il me semble surprenant qu'un A, qui doit être construit avec trois entier doive, aussi/à la place contenir un pointeur sur B et qu'un B doive, lui, contenir un pointeur sur A...

Tout cela me ferait penser au pattern composite (désolé, le lien est en anglais :aie:) bien qu'il y ait quelques incohérences dans tes explication...

Qu'est ce qui te choque ? Il n'y a, à priori, aucun rapport entre le type des données dont a besoin le constructeur d'un objet et ce qu'il est supposé faire ensuite.

Ce qui me choque le plus, en dehors de toute famille, c'est de vouloir mettre un B qui contient un A dans... un A...

Si tu entre dans le patern composite (entre autre), cela n'a rien de trop choquant (quoi que...), mais tu pars sur deux classes qui ont la meme origine, or aucune mention d'une origine commune n'est faite dans les explications...

J'ai peut-être mal lu ton post :

Citation:

---

Le deuxième est qu'il me semble surprenant qu'un A, qui doit être construit avec trois entier doive, aussi/à la place contenir un pointeur sur B et qu'un B doive, lui, contenir un pointeur sur A...

---

Je ne vois nul part où l'auteur du message d'origine parle de pointeur membre.
Lorsqu'il parlait de void* cela devait être comme argument du constructeur, non ?

Ben, quand tu vois les déclarations qu'il donne...

• A monA(1,2,3);
• B monB(&monA);
• A monAbis(&monB);

tu te rend compte qu'il crée deux A (monA et monABis), l'un avec un constructeur prenant trois entier et l'autre avec un constructeur prenant un pointeur sur B...

Dés lors, et sans autre explications de sa part, je part du princique qu'il respecte le principe du RAII et que les classes prennent à peut de chose près la forme de

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

class A { /*...*/ int a; int b; int c; B* ptrb; }; class B { /*...*/ A* ptra; }

---

parce qu'il pourrait tout aussi bien passer le A en référence si le seul but était de récupérer les informations contenue dans le A (et qu'il n'aurait qu'à passer A en référence ou trois entiers s'il s'était agit d'un héritage)...

Mais, cela signifie, toujours en respectant le RAII, que l'auteur a deux constructeurs pour son A, qui sont sans doute implémentés sous la forme de

Code:

---

1 2 3 4

A::A(int a, int b, int c):a(a),b(b),c(c),ptrb(NULL) {   }

---

et de

Code:

---

1 2 3 4

A::A(B* ptrb):a(0),b(0),c(0),ptrb(ptrb) {   }

---

et un constructeur pour B dont l'implémentation prend la forme de

Code:

---

1 2 3 4

B::B(A* ptra):ptra(ptra) {   }

---

et je dois avouer que ca me chiffone au plus haut point, parce que je ne vois que très mal le genre de logique que l'on peut vouloir implémenter sous cette forme...

Tout cela me fait penser au fait qu'il voudrait que A et B alternent dans une liste d'éléments, et que ce soit d'office un A qui termine la liste...

Je n'ai rien contre à priori, mais j'ai la furieuse impression qu'il manque quelque chose dans l'histoire ;)

Et ce qui m'inquiète également, c'est le fait qu'il ne fasse rien sous la forme d'allocation dynamique :P

Et pourquoi pas simplement plutôt quelque chose comme :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

A::A(int a, int b, int c):a(a),b(b),c(c) {   }   A::A(B& ptrb) : a( ptrb.calculea() ), b( ptrb.calculeb() ), c( ptrb.calculec() ) {   }

---

et pareil dans l'autre sens

Sauf que là, il passe un pointeur... donc, a priori, c'est qu'il veut une référence forte entre A et B :P

C'est pour cela que je ne comprend pas du tout la logique sous-jacente ;)

S'il s'agissait d'une référence, on pourrait penser qu'il y a "simplement" des calculs effectués, voire une question d'héritage dans l'histoire, et je ne serais pas *trop* inquiet (bien que cela reste assez limite de vouloir calculer un A à partir d'un B qui a été calculé lui-même à partir d'un A (qui lui-même a été... :question:)...), mais, ici, encore une fois, le PO parle bel et bien de pointeurs ;)