Discussion :

[kennylafougere]

Bonjour,

Voila je ne suis pas tout a fait débutant (enfin pas loin quand même) mais ça fait des années que je n'ai pas codé et je bute sur des notions de base de la poo.

Donc pour résumer mon problème, après mettre remis au C sur un petit projet de wake on lan je continue sur la lancée en faisant une interface graphique avec qt. Au niveau de la structure de mon code pour l'instant j'ai le main, une classe gui et une classe parc (qui gère une liste statique du par info). j'instancie tout dans le main et la classe gui a besoin de connaitre l'instance de parc et inversement. J'ai donc créé dans chaque classes une méthode publique qui récupère un pointeur de l'instance de l'autre classe (chacune appelée dans le main après la création des objets). et là le compilo commence a péter un plomb quand je déclare le pointeurs sur la gui.

Déjà je voudrais savoir si je m'y prend correctement dans la façon de faire.
Je suppose que le problème des classes qui doivent mutuellement connaitre les instances d'autres classes doit être courant et donc les solutions connues.
De plus quel est le problème avec la création d'un pointeur de type gui? (spécificité de Qt ?)

sinon je donne quand même un résumé du code en sachant qu'il y a sans doute d'autres erreurs de base dedans :

main

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
#include <QApplication>
#include "gui.h"
#include "parc.h"
 
int main(int argc, char *argv[])
{
    QApplication app(argc, argv);
 
    Gui interface;
    Parc mParc;
    interface.recupPtrParc(&mParc);
    mParc.recupPtrGui(&interface);
    interface.show();
 
    return app.exec();
}

gui.h

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
#include "parc.h"
 
class Gui : public QWidget 
{
    Q_OBJECT
 
    public:
        Gui();
        void recupPtrParc(Parc::Parc *monParc);
 
    private:
        Parc::Parc *PtrParc;
};

gui.cpp

Code :

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

1
2
3
4
5
6
7
8
9
10
11
#include "gui.h"
 
Gui::Gui() : QWidget()
{
    PtrParc = new Parc();
}
 
void recupPtrParc(Parc *monParc)
{
    *PtrParc = *monParc;
}

parc.h

Code :

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

1
2
3
4
5
6
7
8
9
10
11
#include "gui.h"
 
class Parc
{
    public :
        Parc();
        void recupPtrGui(Gui::Gui *maGui);
 
    private :
        Gui::Gui *PtrGui;
};

parc.cpp

Code :

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

1
2
3
4
5
6
7
8
9
10
11
#include "parc.h"
 
Parc::Parc()
{
    PtrGui = new Gui();
}
 
void recupPtrGui(Gui *maGui)
{
    *PtrGui = *maGui;
}

[3DArchi]

Salut,
F.A.Q. : Comment créer 2 classes qui font référence l'une à l'autre ?
Ahhhh, l'habitude du C ! En C++, utilises une référence dès que tu le peux et un pointeur quand tu le dois :

Code :

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

1
2
3
4
void recupPtrGui(Gui &maGui)
{
    PtrGui = *maGui;
}

Ensuite, tu as un (petit ) problème : parc crée un gui dans son constructeur qui crée un parc dans son constructeur qui crée un gui dans son constructeur qui crée un parc dans son constructeur qui crée un gui dans son constructeur qui crée un parc dans son constructeur qui crée un gui dans son constructeur qui crée un parc dans son constructeur qui crée un gui dans son constructeur qui crée un parc dans son constructeur qui crée un gui dans son constructeur qui crée un parc dans son constructeur qui crée un gui dans son constructeur qui crée un parc dans son constructeur qui ... Error Exception non gérée : 0xC00000FD: Stack overflow.

C'est donc que tu as probablement un petit soucis de design : si les deux classes sont liées, elles ne sont en revanche probablement pas responsable de la durée de vie l'une de l'autre. Peut être est-ce plus pertinent de l'avoir dans le main :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
int main(int argc, char *argv[])
{
    QApplication app(argc, argv);
 
    Gui interface;
    Parc mParc;
    interface.setParc(mParc);
    mParc.setInterface(interface);
    interface.show();
 
    return app.exec();
}

et :

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 Gui : public QWidget 
{
    Q_OBJECT
 
    public:
        Gui();
        void setParc(Parc::Parc &monParc);
    private:
        Parc::Parc *PtrParc;
};
// .cpp 
void Gui::setParc(Parc::Parc &monParc)
{
   PtrParc = &monParc;
}

Idem bien sur côté interface.

Enfin, cela me fait penser à un début d'architecture MVC (M=Parc, V = Gui...).

[kennylafougere]

Merci pour la réponse rapide et bien vu pour les inclusion croisées ça à effectivement résolu la majeur partie de mes problèmes .

Pour ce qui est des références j'y avais aussi pensé mais pour tout dire je m'étais heuté au fait qu'il faut les initialiser a la déclaration d'autant plus qu'avec ta solution j'utiliserais quand même un pointeur au final.

Sinon pour le model MVC je connaissais pas mais en y regardant sa tombe pile dedans puisqu'il me manquait encore une classe pour la partie communication réseau que j'ai laissé de coté jusque là car je ne savais pas trop comment la définir et qu'elle découlerait de ce que j'ai déjà fait en C.

Par contre il reste encore une erreur de compil que je ne comprend pas par rapport a mon pointeur PtrParc dans la méthode setParc dans le gui.cpp :

'PtrParc' was not declared in this scope

Sachant qu'il ne dit rien pour le pointeur PtrGui alors que le code est le même dans la classe Parc (j'ai enlevé les new dans les 2 constructeurs sa n'as pas l'air de poser problème)

edit : je suis en train de voir le tuto du sdz sur le pseudo mvc de qt je me demande si sa vaut le coup de reprendre mon code pour l'exploiter sachant qu'a la base je compait utiliser un std::map pour le parc (nom netbios / mac addr)?

[koala01]

Par contre il reste encore une erreur de compil que je ne comprend pas par rapport a mon pointeur PtrParc dans la méthode setParc dans le gui.cpp :

'PtrParc' was not declared in this scope

Sachant qu'il ne dit rien pour le pointeur PtrGui alors que le code est le même dans la classe Parc (j'ai enlevé les new dans les 2 constructeurs sa n'as pas l'air de poser problème)

Typiquement, quand tu obtiens une erreur du type "Quelquechose" was not declared in this scope, c'est que tu t'es "simplement" trompé d'identifiant pour une variable, ou pour un argument.

Cela peut tout à fait être "simplemnt" du à une erreur de casse (== différence entre les majuscules et les minuscules) parce que tu aurais nommé ton pointeur sur parc ptrParc, par exemple, ou, tout aussi bêtement, parce que tu aurais nommé ton pointeur non pas PtrParc, mais... m_parc ou quoi que ce soit d'autre.

Cela arrive régulièrement lorsque l'on décide de modifier le nom de la variable ou de l'argument, mais que l'on ne répercute pas la modification partout où l'on tente d'y accéder

edit : je suis en train de voir le tuto du sdz sur le pseudo mvc de qt je me demande si sa vaut le coup de reprendre mon code pour l'exploiter sachant qu'a la base je compait utiliser un std::map pour le parc (nom netbios / mac addr)?

Le fait est que le MVC est une approche qui présente pas mal d'intérêt...

D'abord parce qu'elle te permet de distinguer clairement les données de la manière dont elle sont représentées et de la manière dont elles sont utilisées (on parle souvent de la distinction entre la partie purement applicative (dont l'IHM) et de la partie purement métier ).

Cela parait tout bête comme cela, mais tu semble parti pour créer au final une architecture de type "client / serveur".

Les données que tu manipulera alors seront intrinsèquement les même tant du coté "client" que du coté "serveur", mais la manière dont tu pourra les utiliser sera sans doute fondamentalement différente, dans le sens où le client n'aura pas forcément accès à l'ensemble des informations et où le serveur fera sans doute un maximum de vérifications avant d'accepter une requête de la part du client.

La distinction que le Model View Controller permet entre la partie purement applicative et la partie réellement métier permet donc d'augmenter globalement la sécurité de ton système

De plus, cela permet de s'affranchir, pour une partie du problème en tout cas, de la dépendance envers un framework particulier.

Tu peux, en effet (et c'est d'ailleurs conseillé :p) décider de baser la partie purement métier sur du C++ tout à fait standard (donc en théorie portable), sans qu'elle ne dépende de Qt (vu que c'est ce que tu utilise), et de n'utiliser Qt que pour la partie purement applicative.

Et, si un jour les choses se mettent de la sorte, tu pourras sans aucun problème décider de créer une application tout autre, basée sur la partie métier qui ne nécessitera aucune modification, mais dont la partie applicative serait mise en oeuvre en utilisant le framework .Net ou WxWidget, par exemple

Enfin, cela facilitera énormément l'évolution de ton projet, car tu n'es surement pas sans savoir que les besoins évoluent sans arrêt.

Si tu es trop dépendant de ton IHM pour ce qui concerne la partie métier, tu te sentira rapidement "étriqué" dans les possibilités de faire "facilement" évoluer ton projet.

Il m'est, pour te donner un simple exemple, arrivé de devoir virer un total de près de 30.000 lignes de code parce que je ne pouvais plus faire évoluer un projet comme je l'entendais, "simplement" parce que j'avais commis la bêtise de ne pas séparer la partie métier de la partie applicative.

Je peux t'assurer que, bien que cela me soit arrivé il y a des années, j'ai encore un gout amère qui me revient par le seul fait d'y penser

Maintenant, nous sommes bien d'accord sur le fait que tu reste seul maitre de ton projet, mais j'espère que ces quelques lignes te permettront de prendre la décision la plus sage

[gbdivers]

Bonjour kennylafougere

En complément, Qt offre le système des signaux/slots, qui permettent d'éviter ce type de problème (2 classes qui doivent connaître la structure l'une de l'autre). Pour lier une couche métier et une couche IHM, ça simplifie le code et son évolution.

[kennylafougere]

Pour mon problème de compil je suis absolument certain de l'orthographe puisque j'ai fait un copier/coller de la déclaration.

Code :

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

1
2
3
4
5
6
7
8
9
//gui.h
 private:
        Parc *PtrParc;
 
//gui.cpp
void setParc(Parc &monParc)
{
    PtrParc = &monParc;
}

Sinon pour le mvc je vais tester avec un QStandardItemModel et QListView.
Je pourrais lier la vue au modèle dans le main et effectivement régler de façon définitive ce problème de pointeur grâce au système de signaux/slot (n'empêche sa m'énerve quand même de pas savoir pourquoi).

[3DArchi]

Pour mon problème de compil je suis absolument certain de l'orthographe puisque j'ai fait un copier/coller de la déclaration.

void Gui::setParc(Parc &monParc)

[kennylafougere]

Effectivement merci 3DArchi ce sont toujours les erreurs les plus bêtes qui donnent le plus de fil a retordre.
Du coup je vais peut-être relativiser sur le système de signaux/slots qui me pause aussi problème quand le signal est émis par un autre objet que celui qui contient le slot (le connect est dans le main mais ne fait rien a priori).