Discussion :

[stanfillirenfro]

Bonsoir à tous!
Je sollicite un efois de plus votre aide pour la résolution d'un probléme qui me tracasse depuis un certain temps. Je veux en effet parcourir une bibliothéque (la bibliothèque list), mais je recois une message d'erreur me disant que list n'est pas déclarée.
Je vous serai reconnaisant si vous m'aidiez à contourner cette difficulté. Pour être clair, pourquoi ce message d'erreur est affiché? Et comment y rémédier?
Merci d'avance!

Voici le code:

Fen.h

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
19
#ifndef DEF_FEN
#define DEF_FEN
 
#include <QtGui>
 
 
class Fen: public QDialog
{
    Q_OBJECT
 
public:
    Fene(QWidget *parent);
    ~Fen();
 
 
private:
 
};
#endif

Fen.cpp

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
#include "Fen.h"
 
list<QString> nom;
nom.append("Ali");
nom.append("Baba");
nom.append("Nounou");
 
list<QString>::iterator it;
 
for(it = nom.begin(); it != nom.end(); it++)
{
  out<< *it
}

main.cpp

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
#include "Fen.h"
#include <QApplication>
 
 
int main(int argc, char *argv[])
{
    QApplication app(argc, argv);
    PuriVec fen;
    fen.show();
 
    return app.exec();
}

[Kaamui]

Bonjour,

d'où vient ton type list ?

s'il s'agit du conteneur std::list il faut ajouter (là où tu en as besoin, ici fen.cpp) #include <list> et un petit using namespace std; si tu ne veux pas avoir à préciser à chaque fois dans quel scope ce type se situe.

[cob59]

Si tu utilises Qt, utilise-le jusqu'au bout : QList et QStringList. On a rarement besoin de classes de la STL (comme std::list) dans un projet Qt.

[stanfillirenfro]

Merci cob59 et Kaamui!
Vos réponses m'ont aidé.
Le problème est résolu.
Merci une fois de plus.

[JolyLoic]

Si tu utilises Qt, utilise-le jusqu'au bout : QList et QStringList. On a rarement besoin de classes de la STL (comme std::list) dans un projet Qt.

Je ne suis pas trop d'accord. Si je devais faire un projet Qt, je séparerais la partie UI de la partie moteur, et dans la partie moteur, je m'interdirais d'utiliser quoi que ce soit lié à Qt.

Et même dans la partie UI, je ne vois pas pourquoi je m'interdirais d'utiliser la bibliothèque standard (et d'ailleur plus std::vector que std::list). Disons que je n'ai rien vu dans les listes Qt qui me semble être un avantage concurrentiel sur les conteneurs utilisables partout en C++.

[cob59]

Il sera toujours plus facile d'écrire, lire, gérer et documenter un code si le nombre de ses dépendances est minimal. En plus toutes les classes issues de QtGui se basent sur les "équivalents Qt" des conteneurs de la STL, donc il va devoir faire des conversions std::container <=> QContainer à n'en plus finir.

[stanfillirenfro]

Salut cob59 et JolyLoic et merci pour vos commentaires.
Disons plutot que j'au pu trouver mon compte dans ce que cob59 a donné comme, puisque je travaille en Qt. Son explication a résolu mon prblème.
En pensant aux autres qui pouvaient etre interessés, je me dis qu'aucune idée ne devarit être rejetée du moment où elle aide. Pour ce que dis JolyLoic, j'ai encore á beaucoup travailler pour mieux cerner ses explications.
Je vous dis merci pour vos commentaires.

[Klaim]

Il sera toujours plus facile d'écrire, lire, gérer et documenter un code si le nombre de ses dépendances est minimal. En plus toutes les classes issues de QtGui se basent sur les "équivalents Qt" des conteneurs de la STL, donc il va devoir faire des conversions std::container <=> QContainer à n'en plus finir.

Dans mon code qui utilise principalement la SL et qui passe des données à Qt, les conversions sont quasi toujours implicites et marquent les frontières entre les deux parties.

C'est une bonne chose.

Aussi, si tu dois utiliser Qt, alors SL n'est pas une dépéndance de plus, c'est Qt qui l'est. Dans l'idéal, c'est les spécificités de Qt que tu dois éviter pour maintenir du code portable (plus que ce que Qt permet) et qui pourrait bien être réutilisé sans Qt.

[cob59]

Dans mon code qui utilise principalement la SL et qui passe des données à Qt, les conversions sont quasi toujours implicites et marquent les frontières entre les deux parties.

C'est un choix de conception que je respecte, quoiqu'on pourrait discuter du temps de calcul perdu dans cet interfaçage STL/Qt. Si ton programme comporte un noyau STL-only découplable du GUI et compilable-exécutable sous une plateforme non gérée par Qt (ou qui doit s'en passer pour des questions de perf/conso mémoire) alors je dis OK. Le reste du temps, une API Qt convient parfaitement.

Aussi, si tu dois utiliser Qt, alors SL n'est pas une dépéndance de plus, c'est Qt qui l'est. Dans l'idéal, c'est les spécificités de Qt que tu dois éviter pour maintenir du code portable (plus que ce que Qt permet) et qui pourrait bien être réutilisé sans Qt.

La STL est une dépendance comme une autre ; elle est standard certes, mais on a le droit de s'en abstraire et d'utiliser les types Qt qui sont tout aussi portables, fonctionnels et complets.
Et je dis ça en tant qu'utilisateur réguier et intensif de la STL

[koala01]

Salut,

C'est un choix de conception que je respecte, quoiqu'on pourrait discuter du temps de calcul perdu dans cet interfaçage STL/Qt. Si ton programme comporte un noyau STL-only découplable du GUI et compilable-exécutable sous une plateforme non gérée par Qt (ou qui doit s'en passer pour des questions de perf/conso mémoire) alors je dis OK. Le reste du temps, une API Qt convient parfaitement.


La STL est une dépendance comme une autre ; elle est standard certes, mais on a le droit de s'en abstraire et d'utiliser les types Qt qui sont tout aussi portables, fonctionnels et complets.
Et je dis ça en tant qu'utilisateur réguier et intensif de la STL

Je crois, personnellement, que tu prends le problème à l'envers...

Pour moi, le découplage du business et de l'IHM n'est simplement pas un choix, ca devrait presque etre une obligation!

En effet, le business est, même s'il évolue, ce qui va sans doute rester le plus stable, alors que la manière de l'utiliser, de l'afficher de permettre à l'utilisateur de le manipuler correspond à une vision très temporaire des problèmes que le business résout.

Il n'est pas rare que le business soit identique pour un grand nombre d'applications différentes, développées en tant que projet totalement indépendants, avec des optiques et dans des langages totalement différent.

Si tu fais dépendre ton business de bibliothèques trop spécifiques, tu vas poser des restrictions à la réutilisation de ton business telles que "d'autres projets" (dont tu n'auras peut etre jamais connaissance ni meme conscience !!! ) n'auront que deux solutions :

• Soit, ils s'adaptent et utilisent les même technologies que toi
• Soit, ils réimplémentent toute la partie business, avec tous les risques que cela comprend

De plus, Qt n'est portable que dans la mesure où les fonctionnalités qu'elle offre sont portables et dans la mesure où l'ensemble des développeurs veillent à la maintenir portable.

Mais les utilisateurs de Qt restent à la merci du moindre changement de mentalité dans le chef des dév de l'outil, de régressions dues à un manque de tests ou, simplement, d'une revue conséquente de l'ensemble.

Le fait d'utiliser la S(T)L de manière systématique pour le business te permet, au moins, d'avoir la certitude de la stabilité de ce que tu utilises car, même si tu utilises différentes implémentations, tu a la garantie qu'elles devront, pour etre "standard compliant" présenter une interface déterminée.

Sans oublier les philosophies particulières (telles que lasy initialization / lasy copy) éventuelles

Enfin, la nécessité d'éventuelles conversions (j'ai presque envie de dire "surtout les conversions explicites" ) peut présenter pas mal d'avantages, dont, par exemple, celui de t'interdire la concaténation "brutale" des données au moment de les afficher.

En effet, si tu as besoin des chaines contenues dans le business sous les noms de str1 et str2 pour générer un message Qt, tu vas, tout naturellement, utiliser la fonction arg de Qstring pour le faire!

La création de ton message ressemblera donc à quelque chose comme QString msg = QString("blabla %1 blabla %2 blabla").arg(str1/*.c_str()*/).arg(str2/*.c_str() */ ); ce qui te facilitera la traduction du message (en cas de besoin), et qui le rendra beaucoup plus générique que si tu avais envisagé une simple concaténation de QString

Dis toi bien que ce n'est pas le temps passé à convertir un std::vector<std::list>en QStringList qui va poser des problèmes de performances, mais que c'est l'ensemble des appels système propre à la création / à l'affichage / au rafraichissement des fenêtres et des limitations purement matérielles (ou de certains algo, y compris, et surtout tes algo personnels)

[cob59]

C'est en posant l'égalité Qt=IHM que tu te plantes
Le découplage données/métier/IHM est déjà prévu dans Qt, qui est beaucoup plus qu'une simple interface graphique. Chez un dev Qt responsable, la couche métier est systématiquement isolée du reste de son appli, et rien ne l'empêche de coller un wrapper Qt<->STL si le besoin s'en fait sentir.

A propos de traduction, tu sais qu'il existe QString::tr() n'est-ce pas ?

[koala01]

C'est en posant l'égalité Qt=IHM que tu te plantes
Le découplage données/métier/IHM est déjà prévu dans Qt, qui est beaucoup plus qu'une simple interface graphique. Chez un dev Qt responsable, la couche métier est systématiquement isolée du reste de son appli, et rien ne l'empêche de coller un wrapper Qt<->STL si le besoin s'en fait sentir.

Je sais pertinemment que Qt ne se limite pas à l'IHM, ne t'en fais pas

Mais, bien au delà de considérer uniquement Qt, il faut vraiment veiller à limiter les dépendances envers des "bibliothèques externes" (de manière générale ) aux parties qui ont réellement besoin de ces dépendances!

Or, tu sembles oublier que lorsque tu compile du C++, la dépendance envers la bibliothèque standard à l'édition de liens est d'office activée ( tu as d'office le flag -lstdc++)...


En basant ta partie métier sur Qt (ne serait-ce qu'avec QString), tu rajoutes bel et bien une dépendance complémentaire qui n'a pas forcément lieu d'être!

Il est donc beaucoup plus logique d'envisager de créer la partie métier en C++ "pur" ( comprend : à l'exception de toute bibliothèque externe non indispensable), quitte à faire un wrapper vers Qt pour les projets qui en auront besoin.

De cette manière, les autres projets restent tout à fait libre de choisir le "niveau de dépendance" selon leur propres conception de la chose, et de ne payer le cout de la dépendance envers Qt que si... ils ont effectivement décidé de l'utiliser

Quelque part, c'est peut etre le seul reproche que j'aurais à faire à Qt : celui d'être parti en direction d'une "boite à outils fourre tout"

Je te rassure: c'est un reproche que je peux faire vis à vis de nombreux frameworks

Mais c'est à tel point que l'utilisateur de Qt ne se rend plus forcément compte du fait qu'il rajoute systématiquement une dépendance lorsqu'il décide de lancer un projet Qt (quitte à ce que ce ne soit qu'envers QtCore ) alors qu'il aurait peut etre parfaitement pu s'en passer

A propos de traduction, tu sais qu'il existe QString::tr() n'est-ce pas ?

C'est exactement à cela que je pensais...

Et tu avoueras qu'il est beaucoup plus facile de traduire "vous ne pouvez pas utiliser %1 dans %2" que d'envisager chaque variation que ce genre de phrase peut prendre, non

Ne serait ce que parce que dans le cas que je présente, on garde le contexte général de la phrase, et que l'on ne se retrouve pas à devoir traduire trois ou quatre morceaux de phrases qui ne veulent dire quelque chose que... dans le contexte de la phrase complète