Discussion :

[julieng31]

Bonjour,

une petite question en C++ pour laquelle je ne trouve pas de réponse sur Internet, pourriez-vous m'aider ?

1. J'ai un main dans lequel j'alloue plusieurs mémoires qui seront partagées par tout mon programme (ici un exemple avec listLoc).

Code :

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

1
2
3
4
5
6
7
8
9
 
MainWindow::MainWindow(QWidget *parent) : QMainWindow(parent) {
 
    // Create memory
    listLocalization * listLoc = new listLocalization();
 
    // Build central widget
    MainWindow::buildCentralWidget(listLoc);
}

2. J'ai une fonction qui crée des onglets (Qt). Ces onglets sont des classes et auront besoin d'accéder à listLoc (un exemple ici).

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
 
void MainWindow::buildCentralWidget(listLocalization * listLoc) {
 
    // Add central widget
    mainWidget = new QTabWidget();
 
    // Create first tab
    tab1 = new tabLocalization(mainWidget);
 
    // Add tabs
    mainWidget->addTab(tab1, tr("&Localization (database)"));
 
    // Define central layout
    setCentralWidget(mainWidget);
}

Comment est-ce que je peux donner accès à ma mémoire listLoc à la classe tabLocalization ?


Une solution à laquelle je pense serait de rajouter un pointer dans la classe tabLocalization:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
class tabLocalization : public QWidget {
    Q_OBJECT
 
public:
    explicit tabLocalization(QWidget *parent = 0, listLocalization * listLoc);
    ~tabLocalization();
 
private:
    listLocalization * listPtr;
}

Et de faire pointer listPtr vers listLoc dans le constructeur.

Est-ce qu'il existe une façon plus simple ou propre de faire ce que je souhaite ?

Merci pour votre réponse !

[Astraya]

Bonjour,

L'utilisation d'un pointeur est une bonne idée, cependant, tu dois faire attention au pointeur. Je te conseil d'utiliser std::shared_ptr. C'est un wrapper pour ton pointeur qui vas s'assurer que tu ne le delete pas dans une classe alors qu'une autre l'utilise par exemple.

[julieng31]

Merci pour ta réponse et ok pour le shared_ptr.

Pour ma compréhension uniquement, chaque classe aurait son pointeur "local" donc comment une classe pourrait supprimer le pointeur pour une autre classe ?

[white_tentacle]

Le problème n’est pas de supprimer le pointeur, mais de désallouer la zone mémoire pointée.

Si tu l’alloues avant, et que tu t’assures de la désallouer une fois que tous les onglets sont fermés, pas de soucis. Si toutefois tu l’alloues au premier onglet ouvert, et que tu veux t’assurer qu’elle soit désallouée quand le dernier onglet est fermé, on est dans le cas d’une propriété partagée, et donc un shared_ptr est approprié.

Attention aussi : si tu es en multithread, il est probable qu’il te faille un mutex pour protéger les accès à la mémoire (si tous les accès sont faits dans le même thread, pas besoin).

[julieng31]

Merci pour vos réponses très claires, j'ai compris !

Résolu.

[koala01]

Salut,

Hummm... J'ai l'impression que tu es bien mal parti, là...

tu travailles sur une interface graphique ici et tu dois donc adapter ton "système de pensée" à cette circonstance particulière.

Le "système de pensée" auquel toute la partie dédiée à l'IHM de Qt tend à te faire adhérer est basé sur le principe du MVC (Modèle View Controler, même si certains esprits chagrins me rétorqueront peut etre que l'on est plus orienté vers un aspect proche du Model View Delegate ).

C'est, très clairement, celui auquel tu devrais adhérer le plus vite possible.

En effet, quel que soit le contenu réel de ta classe tabLocalization, c'est, d'abord et avant tout, un widget, c'est à dire un élément visuel.

Autrement dit, c'est un élément qui intervient dans le domaine de la vue que l'utilisateur a des différentes données.

Il ne va pas manipuler directement les données métier, non, non, non : il va les manipuler au travers d'un modèle! (typiquement, une classe dérivée de QAbstractModel )... Ou, du moins, il devrait le faire de la sorte

Ton rôle consiste donc:

1. A créer un modèle qui explique à la vue les différentes parties de tes donnée métier qui l'intéresse
2. A remplir ce modèle avec des données pertinentes
3. Si la vue doit permettre la modification des données qu'elle affiche, à créer un controleur qui s'assurera que les modifications sont sensées (on ne sait jamais, si c'est un singe qui est devant le clavier ) avant de modifier effectivement les données.

En travaillant de la sorte:

1. Le modèle peut parfaitement resservir pour une autre vue si besoin
2. Le contrôleur peut parfaitement resservir dans des circonstances similaires
3. Tu gardes tes données métier "bien au chaud" dans leur coin, et tu n'a pas à t'inquiéter de leur dispertion
4. Le jour où tu décides de changer de bibliothèque d'IHM (les gens ont de ces lubies quand meme ), ta "base métier" reste réutilisable (à moins bien sur qu'elle ne fasse déjà une utilisation massive de possibilités propres à Qt )

[julieng31]

Pour être sûr de comprendre, je te propose ma vision initiale puis la même modifiée avec ce que j'ai compris :

1. Approche initiale
* listLocalization = "mémoire centrale" qui est en fait un vector d'objets Localization
* dans l'onglet tabLocalization, l'utilisateur a 2 vues (j'ai un switch qui n'en fait apparaître qu'une à la fois) :
- une vue détaillée (élément Localization par élément). Je modifie donc directement listLocalization en fonction des opérations de l'utilisateur
- une vue en liste (voir tous les éléments). Je remplis un modèle (QStandardItemModel) avec listLocalization et quand je le souhaite, après modification par l'utilisateur, je modifie listLocalization avec le contenu du modèle
=> avec cette approche, il faut qu'à chaque fois que je change de vue, je rafraichisse la "mèmoire centrale" et ré-initialise le modèle
* une fois que ceci est fait (en réalité sur plusieurs "mémoires centrales" indépendantes), je lance un calcul qui prend comme entrée les objets lus dans les "mémoires centrales", un à un, pour faire un calcul. J'essaye d'avoir les objets les plus légers possibles car c'est un calcul intensif (plusieurs heures à plusieurs dizaines d'heures)
* J'ai des onglets de résultat. Je crée un modèle qui est rempli par le résultat du calcul précédent

2. Ce que tu me conseilles serait :
* créer un modèle de type QAbstractModel qui contient toutes mes données
* dans l'onglet tabLocalization, générer 2 vues différentes depuis/vers ce même modèle
* lancer le calcul sur ces modèles
* afficher les résultats comme précédemment

Est-ce que j'ai bien compris ?

Est-ce que le fait de faire des calculs intensifs sur des modèles QT ne va pas être plus long que de le faire avec des vectors d'objets C++ ?

[white_tentacle]

Personnellement, j’utilise toujours QAbstractModel (du moins, son implémentation) comme glue entre mon modèle réel (pouvant être totalement indépendant de qt) et la vue, qui elle est fortement dépendante du toolkit qt.

Travailler directement avec une classe QAbstractModel est de mon point de vue une très mauvaise idée. Cette classe est beaucoup trop liée à la notion d’interface graphique et d’affichage / édition des données.

[Iradrille]

Le jour où tu décides de changer de bibliothèque d'IHM (les gens ont de ces lubies quand meme ), ta "base métier" reste réutilisable (à moins bien sur qu'elle ne fasse déjà une utilisation massive de possibilités propres à Qt )

C'est là un gros problème de Qt, on à souvent des QVector, QString etc.. qui se retrouvent un peu partout pour ne pas avoir à faire de conversion à chaque fois. Les méthodes ont en plus des noms souvent légèrement différent de celles des conteneurs de la STL (pas pratique pour les templates).
Changer de lib de GUI implique souvent de gros changements :/

Qu'est ce que j'aimerai que Qt abandonne sa "QTL" pour utiliser la STL (ou propose un moyen d'utiliser la STL, pour ne pas avoir de problèmes de rétrocompatibilité).

[koala01]

Pour être sûr de comprendre, je te propose ma vision initiale puis la même modifiée avec ce que j'ai compris :

2. Ce que tu me conseilles serait :
* créer un modèle de type QAbstractModel qui contient toutes mes données
* dans l'onglet tabLocalization, générer 2 vues différentes depuis/vers ce même modèle
* lancer le calcul sur ces modèles
* afficher les résultats comme précédemment

Est-ce que j'ai bien compris ?

Presque, mais pas tout à fait.

D'abord, tu remarqueras que j'ai parlé de classe dérivée de QAbstractModel.

Il existe déjà quelques classes dérivées de QAbstractModel dans Qt qui sont adaptée à certains besoins spécifiques.

Tu trouveras peut être celle qui t'intéresses parmi elles

Ensuite, L'idée est que cette classe est "simplement là" pour répondre aux différentes questions que ta vue peut éventuellement se poser.

Le modèle ne sert pas à "générer" la vue. Il ne sert "qu'à fournir les informations qui rempliront la vue".

A charge pour la vue d'aller "piocher" les informations dont elle a besoin dans le modèle

Si deux vues différentes peuvent utiliser le même modèle, tant mieux: le modèle peut être partagé entre deux vues (ou plus).

Par contre, rien ne t'empêche d'avoir un modèle par vue parce que les données affichées par l'une n'ont strictement rien à voir avec les données affichées par l'autre.

Il t'appartient donc de déterminer quelles données seront accessibles depuis quel modèle et sera utilisé par quelle(s) vue(s) pour afficher les informations

Est-ce que le fait de faire des calculs intensifs sur des modèles QT ne va pas être plus long que de le faire avec des vectors d'objets C++ ?

Crois moi, si problème il y a, ce ne sera pas à cause des modèles en eux même, mais bien à cause des manipulations que tu dois faire sur tes données métier pour arriver à les remplir

Personnellement, j’utilise toujours QAbstractModel (du moins, son implémentation) comme glue entre mon modèle réel (pouvant être totalement indépendant de qt) et la vue, qui elle est fortement dépendante du toolkit qt.

C'est exactement ce que je propose

[koala01]

C'est là un gros problème de Qt, on à souvent des QVector, QString etc.. qui se retrouvent un peu partout pour ne pas avoir à faire de conversion à chaque fois. Les méthodes ont en plus des noms souvent légèrement différent de celles des conteneurs de la STL (pas pratique pour les templates).
Changer de lib de GUI implique souvent de gros changements :/

Qu'est ce que j'aimerai que Qt abandonne sa "QTL" pour utiliser la STL (ou propose un moyen d'utiliser la STL, pour ne pas avoir de problèmes de rétrocompatibilité).

C'est un problème récurrent à tout framework un tantinet correct, surtout s'il permet de faire de l'IHM.

Les raisons sont souvent historiques, mais actuellement, je crois que c'est surtout au développeur de faire la distinction claire entre ses données métier (qui devraient être indépendantes du framework en question) et la manière dont elles sont utilisées.

Cela demande très certainement énormément de concentration et, surtout, cela implique d'être d'accord pour se "compliquer un peu la vie" par moment

... Chose que très peu de dev sont d'accord de faire

[julieng31]

Et ben, j'ai bien fait de créer ce post

Merci pour vos réponses, j'ai repris l'architecture pour me rapprocher de vos conseils !!

[koala01]

La plus idiote des questions est celle que l'on n'aura pas (osé) poser