Voila le topic : j'ai deux classes (Cube et Groupe). La première me permet de créer des petits cubes que je peux réunir dans un groupe avec la deuxième.
#ifndef CUBE_H_INCLUDED
#define CUBE_H_INCLUDED
#include "Vecteur.h"
#include "constantes.h"
class Cube
{
public:
Cube(Vecteur const& pPosition, Vecteur const& pVitesse, bool pPhys = true);
Cube(Cube const& a = Cube(Vecteur(0, 0, 0), Vecteur(0, 0, 0)));
virtual ~Cube(); // S
Vecteur getPosition() const;
Vecteur getVitesse() const;
double getMasse() const;
bool isPhysEnabled() const;
void afficheAtt() const;
void calcGravite();
void changePosition(Vecteur pPosition);
void changePosition(double pX, double pY, double pZ);
bool estEgal(Cube const& a) const; // Ne renvoie true que si c'est la même instance
protected:
Vecteur m_position;
Vecteur m_vitesse;
double m_masse;
Groupe *m_groupe;
bool m_physEnable;
void enablePhys(bool enable);
};
bool operator==(Cube const& a, Cube const& b);
bool operator!=(Cube const& a, Cube const& b);
#endif // CUBE_H_INCLUDED
Le problème vient du fait qu'il faut que chaque cube sache à quel groupe il appartient, pour ça il faut que je #include la classe Groupe dans Cube.h, mais quand je fais ça le code ne compile pas, le compilateur me dit que la classe Cube n'existe pas dans Groupe.h.
Donc voila mon problème, je suis toute ouïe à vos suggestions
P.S : Groupe est abstraite car je n'utiliserais pas cette classe directement pour faire mes groupes, et Cube sera abstraite plus tard aussi pour l'hériter dans différents matériaux
Le problème vient du fait qu'il faut que chaque cube sache à quel groupe il appartient,
Pourquoi? N'aurais tu pas plus facile de te dire que chaque groupe s'occupe de manipuler l'ensemble des cubes qu'il contient, ainsi que des interactions entre les différent cubes que le groupe contient et basta ?
A pire, si des interactions entre les groupes sont possibles, ne pourrais tu pas permettre à deux groupes d'avoir accès aux données qui composent les cube de "l'autre groupe" afin de traiter ces interactions ?
Comprenons nous bien : il se peut que tu aies vraiment besoin que chaque cube puisse savoir à quel groupe il appartient, vu je ne sais absolument rien de ton projet. Mais je tenais à te faire prendre conscience que ce n'est pas forcément obligatoire, et qu'il y a peut-être une solution "plus simple" à mettre en oeuvre, car les dépendances cycliques (quand le type A qui a besoin de connaitre le type B pour fonctionner, alors que le type B doit connaitre le type A pour fonctionner), sont très souvent sources de bien des problèmes.
Ceci étant dit, s'il n'y a vraiment pas d'autre solution, il est tout à fait possible d'y arriver en ayant recours à ce que l'on appelle la déclaration anticiptée: ==>un peu de lecture<==. Mais cette solution devrait n'être envisagée que quand on n'a pas d'autre choix
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
Pourquoi? N'aurais tu pas plus facile de te dire que chaque groupe s'occupe de manipuler l'ensemble des cubes qu'il contient, ainsi que des interactions entre les différent cubes que le groupe contient et basta ?
Je ne peux pas, parce que quand je vais hériter Cube, c'est pour avoir des comportements physiques différents. Ce serait trop compliqué de les mettre tous dans une seul classe. Voici comment va a peu près fonctionner Cube :
koala01 a écrit:
Ceci étant dit, s'il n'y a vraiment pas d'autre solution, il est tout à fait possible d'y arriver en ayant recours à ce que l'on appelle la déclaration anticiptée: ==>un peu de lecture<==. Mais cette solution devrait n'être envisagée que quand on n'a pas d'autre choix
Merci pour cette solution, ça fonctionne parfaitement. Merci aussi à Fvirtman qui m'a donné la même solution.
Primo, tu ne peux pas faire hériter liquide de cube, ni même de volume, parce qu'un liquide n'est ni un cube, ni un volume. Et il en va de même pour la notion de solide et de gaz.
D'après les instances que tu prévois de créer j'aurais tendance à dire ce que ce que tu veux conceptualiser, c'est la notion d'élément, qui dispose -- entre autre -- de la notion d'état, mais qu'il n'y a absolument aucune raisons de partir sur une hiérarchie de classes, vu que les notions eau, acide, lave, glace et tout le reste ne sont que ... des éléments
Et encore, cette analyse est fragmentaire, vu que cela impliquerait que tu dispose exactement des mêmes propriétés, quel que soit l'élément envisagé
Secundo, ces éléments n'ont pas à s'inquiéter des autres éléments lorsqu'ils "vivent leur vie": l'eau ne doit savoir comment réagir qu'avec l'eau. Idem pour les autres éléments.
Si tu veux créer des "communautés d'éléments" (déjà, pourquoi voudrais tu en créer plusieurs ???) et que les interactions entre les éléments d'une même société (voire, pourquoi pas, entre les éléments de différentes sociétés) sont soumises à des règles, c'est la société qui doit veiller à respecter les règles qu'elle impose lorsqu'elle transmet ses ordres aux éléments dont elle a la charge.
Et encore, tu risque d'avoir de sérieux problème pour définir clairement ces interactions, vu que, de manière générale, tu risques de te retrouver face à une situation dans laquelle le nombre de combinaisons est quasi illimité; la réaction de l'eau avec l'acide étant différente de celle de l'eau avec la lave ou avec l'huile, par exemple.
Enfin, n'oublie pas que l'état des différents éléments dépend de la pression qu'ils subissent et de leur température:
l'élément H2O, soumise à une pression de 1013 mbr (la pression atmosphérique moyenne sur terre) est solide (glace) si sa température est inférieure à 0° C, liquide (eau) si sa température est comprise entre 0 et 100° C, et gazeux (vapeur) si sa températeur est égale ou supérieure à 100° C.
De la même manière, l'élément N (azote), soumis à la même pression, est solide si sa température est inférieure à -210° C, liquide si sa température est comprise entre -210 et -195.9°C et gazeux si sa température est supérieure à -195.9°C
Enfin, la lave, soumise à la même pression, ne sera liquide que tant que sa température sera supérieure à un certain seuil pouvant varier entre 700 et 1200 °C, mais redeviendra solide (pierre; obsidienne???) en dessous de ce seuil.
Et ces températures varieront en fonction de la pression exercée (savais tu, par exemple, que l'eau bout à des températures beaucoup plus faibles à haute altitude, par exemple, au sommet des hautes montagnes, à cause d'une pression atmosphérique plus faible? )
Enfin, pour les éléments que l'on retrouve "facilement" dans le différents états (H2O, par exemple), il ne faut pas oublier que de grands écarts très brusques de température (si la glace est mise en contact avec de la lave, par exemple) sont tout à fait capable de faire passer l'élément de son état solide à son état gazeux (et inversement), sans passage intermédiaire par l'état liquide.
Tout cela pour essayer de bien te faire comprendre que chaque élément dispose d'un état "ponctuel", dans le sens où il dépend des circonstances et des situations auxquels il est soumis "à l'instant même"; qui est donc susceptible de changer "n'importe quand". Ce simple fait plaide contre l'utilisation de l'héritage pour représenter la notion d'état de l'élément
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
while (true) { be happy }
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html
while (true) { be happy }