Discussion :

[spirzouf]

Bonsoir !

En parcourant la doc ou le net, je ne me souviens plus, j'étais tombé sur une classe intéressante dont je n'arrive pas à me souvenir du nom.

Cette classe fournit des objets qui sont des sortes de listes avec une variable index puis une variable stockée.

Par exemple, dans mon cas, je souhaite faire une liste indexée en fonction de la taille du fichier et donc retrouver sous le même index tous les fichiers de même taille (enregistrés sous forme de QString de chemin absolu :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
Taille en octets                   Fichier et chemin absolu
 
678                             |  ->  "/home/fichier1.blabla"
                                |  ->  "/home/fichier36.blabla"
                                |  ->  "/home/fichier12.blabla"
 
463788                             ->  "/home/fichier91.blabla"
 
4667                            |  ->  "/home/fichier71.blabla"
                                |  ->  "/home/fichier25.blabla"

l'avantage, c'est que c'était très simple à ajouter : suffisait de mettre l'index, la valeur à stocker, et hop, la classe se charge de créer l'index s'il n'existe pas encore avec la valeur associée, ou ajoute cette valeur s'il existe déjà des valeurs sous cet index.

Vous voyez de quoi je parle ???

Le premier qui trouve aura le droit à ................. toute ma gratitude
Merci d'avance !

[koala01]

Salut,

Il semblerait que tu sois à la recherche de la classe map, fournie par le standard avec le fichier d'en-tête <map> et disponible dans l'espace de noms std.

Cette classe fournit un tableau associatif clé / valeur trié sur la clé

[spirzouf]

Bonsoir,

merci pour ta réponse, elle s'approchait en effet de de que je cherchais et ça m'a permis de le retrouver : c'était QHash (qui doit être un peu équivalent à multimap pour reprendre ta solution ?).

QHash est il adapté à ma problématique ?? J'ai l'impression que oui, je vais tester...
EDIT : QMultiHash semble encore plus près de ce que je cherche

[koala01]

Il faut voir ce que tu veux effectivement...

En effet, QHash est une classe issue du framework Qt, qui est intéressant, certes, mais qui fait que l'utilisation de QHash implique une dépendance forte vis à vis de Qt.

Il serait dommage d'impliquer cette dépendance si tu ne l'utilise pas dores et déjà dans ton projet, et encore plus dommage d'apprendre le C++ en se basant dessus.

QHash n'est, en effet, pas compatible avec ce que le standard fourni, et si tu apprends le C++ sous cette forme, tu risques de t'enfermer dans un carcan dont il te sera difficile de sortir par la suite :p

Si ton but est de gérer des collections de clés / valeurs dont les clés peuvent apparaitre plusieurs fois, et que les arguments que je présente font mouche, tu devrais envisager d'utiliser unordered_map, disponible grace à l'inclusion du fichier d'en-tête <tr1/unordered_map> dans l'espace de noms std ::tr1 (pour ce qui est de la norme "actuelle", dans l'en-tete <unordered_map> et l'espace de noms std pour ce qui concerne la "nouvelle" norme )

Comprenons nous bien: il n'est pas question ici de dire du mal de Qt, car c'est un framework d'excellente qualité...

Il est juste question de t'inciter à apprendre le C++ standard avant de t'y intéresser

[Steph_ng8]

Bonsoir.

@koala01 Pour répondre à ton interrogation :

(enregistrés sous forme de QString de chemin absolu :

[koala01]

Bonsoir.

@koala01 Pour répondre à ton interrogation :

(enregistrés sous forme de QString de chemin absolu :

Là est justement bien le problème

Tout dans le vocabulaire employé par spirzouf tend à me faire penser qu'il débute à peine (ce n'est qu'une impression diffuse, et ca ne doit absolument pas être pris de manière négative, hein ) et, à partir de là, qu'il s'agisse d'utiliser QString, QHash ou QMultiHash, le problème reste le même : le standard fournit tout ce qu'il faut pour arriver à s'en sortir, et il est donc dommage d'apprendre C++ en y incluant dés le départ une dépendance envers Qt (ou avec n'importe quelle autre bibliothèque non standard d'ailleurs )

Qt supporte ce que le standard fournit, mais il est très difficile de redescendre de Qt vers le standard!

L'idéal (y compris une fois que l'on a passé le stade de "débutant" ) est donc de faire en sorte que le noyau même de l'application (la partie "business" et, pourquoi pas, la partie "controleur" ) soit exclusivement basée sur le standard, et que la dépendance envers Qt n'apparaisse qu'au niveau pour lequel Qt est prévu à la base: lorsqu'on arrive à l'IHM.

De cette manière, si, un jour, on décide de changer de bibliothèque d'IHM, il restera tout à fait possible de garder "la base" de l'application, et il n'y aura "que" l'IHM à refaire

[Steph_ng8]

Ah d'accord, je n'avais pas vu aussi loin.

Ça me fait penser, quand j'utilises Qt, je me débrouille pour utiliser au maximum le standard (ou au minimum Qt ).
Je crois même me souvenir qu'à un moment j'avais utilisé un conteneur de la STL pour stocker des objets Qt... (mais je ne ferai pas l'inverse !)

On dirait qu'inconsciemment j'avais cette vision visant à réduire au minimum les dépendances à ce qui n'est pas standard...

[spirzouf]

Bonjour à tous les 2,

Tout d'abord mes excuses : je pensais avoir posté dans le sous-forum Qt...

Je suis très sensible à vos remarques justifiées. Je suis effectivement débutant et ai fait très peu de programme console C++. Il faut dire que malheureusement, c'est assez peu stimulant par rapport à ce qui m'intéresse, à savoir l'IHM et plus tard la manipulation de données en SQL.
J'ai en fait suivi le tuto du SdZ dans l'ordre, et arrivé au moment des objets de type QAbstractItemModel, j'ai voulu tester en faisant un programme C++/Qt de recherche de doublons de fichiers.
J'imagine qu'en faisant ainsi, je risque effectivement de m'enfermer dans le framework Qt avec C++ qui ne serait qu'un simple "support" pour utiliser ce framework.
Disons qu'en tant que débutant, c'est un peu difficile de savoir où aller quand on a jamais entendu parlé des destinations, alors on va un peu au hasard dans ce que l'on connait déjà, et avec la doc de Qt, de proche en proche, je trouvais de quoi répondre à mes besoins alors que la librairie standard de C++ permet surement de faire la majorité des choses.

Si j'ai stocké les chemins absolus sous forme de QString, c'était parce que je pensais gagner de la mémoire plutôt qu'à stocker des objets QFileInfo / QFile dans un conteneur pouvant posséder plusieurs milliers d'éléments. Dans mon idée, je refabriquai ensuite des QFile à partir du chemin absolu stocké sous forme de QString. Peut-être pas un bon choix, je ne sais pas...

J'ai vu qu'un de vos membres proposait un tutorat pour construire des jeux en C++/Qt si je me souviens bien, j'avoue qu'un truc pareil m'aurait bien plu pour monter pas à pas mon programme de recherche de doublon.

Je ne suis pas étudiant en informatique (un peu avec regret d'ailleurs), j'ai déjà un boulot, des gamins, et du coup, même si j'ai encore pas mal de temps libre, ce n'est pas évident de se dire "on va tout reprendre au début tout seul, faire 10 ans de console, et un jour, je commencerai peut-être à faire ce dont j'avais envie au départ", d'où les raccourcis peut-être un peu malheureux pour se faire plaisir tout en croyant bien faire.

J'ai commencé en partant de zéro le C+++ mi-août et Qt très récemment, avec comme seuls pré-requis un peu de GW BASIC et Turbo Pascal dans l'enfance, et un bref essai de Python / TKinter l'année dernière, abandonné faute de vrai investissement.
Là, j'accroche pas mal sur le C++ que je trouve en fait plus accessible que le python qui fait plein de trucs implicites, mélange les types de variables (en faisant des "transtypages" automatiques si j'ai bien compris), du coup on ne comprend pas forcément comment ça marche, alors que le C++ est plus rigoureux (je ne sais pas si c'est vrai, mais c'est mon ressenti en tout cas). Si j'arrive à avoir de bonnes bases en C++, je pense que je me laisserai à nouveau tenter par le python, mais pour ça on verra plus tard

Donc, pour revenir à nos moutons, il faudrait que je pense davantage en C++ et restreindre au maximum le Qt à la seule partie "affichage". Mais c'est vrai qu'avec la belle doc de Qt, c'est tentant de naviguer dedans, surtout que l'anglais utilisé y est visiblement plus simple par rapport aux docs apparement très éclatées de C++ (et mon anglais pêche pas mal...). C'est marrant aussi de voir que dans le tutoriel du site "débuter en C++", on ne trouve même pas de façon évidente un lien vers une doc C++. (http://alp.developpez.com/tutoriels/debuter-cpp/).
Tout ça pour dire qu'avec Qt, on ne se sent pas perdu, on a une doc et pas mal d'outils dedans. Pour les classes de la librairie standard, c'est moins évident. Faudrait que je regarde en détail le site cplusplus.com que vous m'avez mis en exemple.

Pour conclure, merci pour vos remarques, je vais tenter de faire au mieux...

[ptyxs]

Une doc utile et claire :
http://www.cplusplus.com/reference/

[koala01]

Bonjour à tous les 2,

Tout d'abord mes excuses : je pensais avoir posté dans le sous-forum Qt...

L'erreur est humaine

Je suis très sensible à vos remarques justifiées. Je suis effectivement débutant et ai fait très peu de programme console C++. Il faut dire que malheureusement, c'est assez peu stimulant par rapport à ce qui m'intéresse, à savoir l'IHM

Je te comprends, mais je ne suis pas d'accord...

Le problème, c'est que tu envisage un programme comme un tout incluant d'office les entrées et les sorties, dont les entrées sorties utilisateur!

Je t'accorde volontiers que, vu sous cet angle, le "mode console" s'avère rapidement austère et peu stimulant à utiliser

Mais, si tu "laisse de coté" l'aspect "interactif" (avec l'utilisateur), tu te rendra compte qu'il est possible de faire énormément sans devoir recourir à la bibliothèque d'IHM!

Je n'exagère sans doute pas en te disant qu'il y a très certainement 80 à 90% de ton application qui peut parfaitement se passer de Qt !!!

Tout le noyeau, et tout le business de ton application pourraient parfaitement s'en passer!

et plus tard la manipulation de données en SQL.

C'est sans doute l'exemple idéal de ce que j'essaye d'expliquer:

Tu vas devoir gérer un certain nombre de données. Il est tout à fait possible d'y arriver en se contentant de ce que le standard fourni, qu'il s'agisse des structures qui permettent de les représenter, ou de toutes les règles qui doivent s'y appliquer en terme de lecture et d'édition.

Ensuite, il y a toute la partie qui fait appel à la connexion à la DB, qui génère les requètes et qui en traite les résultats.

Tout cela n'a aucun besoin de la bibliothèque IHM et peut aussi se contenter de ce que le standard fourni et, il faut bien l'avouer quand même, de la bibliothèque MySQ!

Il ne reste plus que la "partie interactive" de l'application qui ait besoin de l'IHM, et de "quelques pièces rajoutées" qui permettent de faire le lien entre les données et le modèle utilisé ou entre la manière dont les données sont affichées et les controleurs qui appliqueront certaines transformations.

Tu me diras sans doute que tu auras de toutes manières besoin d'interactivité pour arriver à tester le business et le "controleur"!

Hé bien non, justement... C'est là qu'interviennent... tadaaaa!!! les tests unitaires:

Tu te crées une série de scénarios reprenant les "cas simples" et les cas "susceptibles de foirer", et tu vérifie que, dans une situation donnée, tu obtienne effectivement un résultat donné.

La seule interactivité qui sera alors nécessaire, l'input étant donnée par programmation, sera... l'affichage du résultat des tests.

Et, s'il s'agit d'afficher la comparaison du résultat obtenu avec le résultat attendu, la console est amplement suffisante (et sans doute plus claire qu'un IHM équivalente)

J'ai en fait suivi le tuto du SdZ dans l'ordre, et arrivé au moment des objets de type QAbstractItemModel, j'ai voulu tester en faisant un programme C++/Qt de recherche de doublons de fichiers.

Et tu as eu bien raison!!

J'ai toujours estimé que le plus difficile était de trouver l'inspiration pour créer un "programme de test"

Mais les tutos qui parlent de Qt partent, malheureusement, trop souvent du prérequis... de connaitre C++ à la base.

Ce n'est pas un reproche, loin de là, c'est juste une constatation et c'est normal et tout à fait justifié :

Qt représente un nombre phénoménal de classe et utilise une approche particulière appelée MVC (Model View Controler) qui est, sans doute, la meilleure approche possible dans la gestion de données.

Il y a donc déjà largement assez à dire pour ne pas, en plus, rajouter la tartine qui serait nécessaire à l'apprentissage de C++, d'autant plus que Qt fournit de nombreuses classes qui font doublon avec le standard

J'imagine qu'en faisant ainsi, je risque effectivement de m'enfermer dans le framework Qt avec C++ qui ne serait qu'un simple "support" pour utiliser ce framework.

Et surtout (je ne veux pas te décourager, loin de là ) je peux presque jouer à Madame Irma, tant la suite est habituelle :

Tu vas créer des choses qui fonctionneront sans doute exactement comme elles le doivent (c'est en tout cas tout le mal que je te souhaites ) mais tu sera à tel point dépendant de Qt que, un jour, tu voudras rajouter une bête fonctionnalité mais la manière dont ton application a été conçue t'empêchera de le faire.

Le résultat des courses pourrait très bien être à ce moment là de... virer purement et simplement les 50 à 100 000 lignes de code déjà écrites pour tout recommencer (ca sent le vécu, hein Et pour cause, j'ai un jour viré plus de 300 000 lignes de code comme cela re )

Disons qu'en tant que débutant, c'est un peu difficile de savoir où aller quand on a jamais entendu parlé des destinations, alors on va un peu au hasard dans ce que l'on connait déjà, et avec la doc de Qt, de proche en proche, je trouvais de quoi répondre à mes besoins alors que la librairie standard de C++ permet surement de faire la majorité des choses.

Je dois avouer que la doc de Qt est particulièrement bien faite, et je regrette que leur exemple ne soit pas d'avantage suivi

Mais c'est aussi à cela que sert le forum : à te "guider" vers les bonnes pratiques, vers les adresses "intéressantes" et à te conseiller au mieux de tes intérêts

Maintenant, j'ai un avis particulièrement tranché sur la question, et je comprendrais que tu n'aie pas le même, mais je suis d'accord avec moi

Si j'ai stocké les chemins absolus sous forme de QString, c'était parce que je pensais gagner de la mémoire plutôt qu'à stocker des objets QFileInfo / QFile dans un conteneur pouvant posséder plusieurs milliers d'éléments. Dans mon idée, je refabriquai ensuite des QFile à partir du chemin absolu stocké sous forme de QString. Peut-être pas un bon choix, je ne sais pas...

Tu as, très certainement, bien fait...

Il ne sert à rien de se trimbaler des structures monstrueuses si c'est pour n'utiliser que quelques données particulières

Mais mon conseil est, tout simplement, d'aller encore "un peu plus loin" dans le "dégraissage" pour arriver, au niveau du business même de l'application, à t'affranchir carrément de Qt

J'ai vu qu'un de vos membres proposait un tutorat pour construire des jeux en C++/Qt si je me souviens bien, j'avoue qu'un truc pareil m'aurait bien plu pour monter pas à pas mon programme de recherche de doublon.

Malheureusement, il n'y a que 24 heures dans une journée et tous les intervenants du forum, qu'il soient simple participants, rédacteurs, modérateurs et même responsables (si si ) sont sur un pied d'égalité : ce sont des gens qui ont une vie professionnelle et une vie privée en dehors du forum, et qui participent à leur niveau "par passion"

Et puis, il y a tant de domaines à aborder qu'il est malgré tout difficile de satisfaire tout le monde

Mais, qui sais, peut etre voudras tu te lancer dans la rédaction d'un tuto lorsque tu te sera approprié le langage (beaucoup de tuto sont en réalité le résultat d'une recherche personnelle parce que, justement, la ressource manquait )

Je ne suis pas étudiant en informatique (un peu avec regret d'ailleurs), j'ai déjà un boulot, des gamins, et du coup, même si j'ai encore pas mal de temps libre,

Comme je viens de le dire, c'est le cas d'un grand nombre de participants à ce forum...

J'ai personnellement démarré à 6h30 ce matin, et cela ne fait qu'une petite heure que je suis renré (et je suis sur le forum depuis )

ce n'est pas évident de se dire "on va tout reprendre au début tout seul,

C'est, quelque part, le but du (des) forum(s) : t'éviter d'être "tout seul face à ta feuille blanche, fusse-t-elle virtuelle

faire 10 ans de console, et un jour, je commencerai peut-être à faire ce dont j'avais envie au départ"

Je te rassures : il ne faut pas forcément attendre 10 ans et de maitriser le moindre recoins de C++ avant de lancer son projet...

Il est jsute question (ou du moins, c'est le conseil que j'essaye de faire passer ici) de s'accorder "un minimum de temps" pour apprendre le langage...

Sans vouloir tout maitriser (loin de là), il est tout à fait possible d'en "savoir assez" pour se débrouiller en un peu moins de trois mois! C'est un investissement qui vaut la peine, non

Et puis, s'il fallait attendre de maitriser parfaitement le langage avant de se lancer dans un projet, il n'y aurait pas beaucoup de programmeurs actifs, et encore moins de projets : cela fait 7 ou 8 ans que je m'adonne au C++, et je n'en ai pas encore fait le tour

, d'où les raccourcis peut-être un peu malheureux pour se faire plaisir tout en croyant bien faire.

Ne crois pas que je juges en quoi que ce soit ce que tu fais ou les raisons qui t'ont poussé à le faire!!!

Disons juste que j'ai acquis suffisamment d'expérience pour savoir connaitre les peaux de bananes sur lesquelles tu ne manqueras pas de chuter en agissant de cette manière

J'essaye donc de te conseiller, encore une fois, au mieux de tes intérêts

Mais, maintenant, tu sais, il ne tient qu'à toi de m'écouter... ou non, et je ne ferai pas une maladie si tu décide de ne pas le faire

J'ai commencé en partant de zéro le C+++ mi-août et Qt très récemment, avec comme seuls pré-requis un peu de GW BASIC et Turbo Pascal dans l'enfance,

Tout le monde a commencé un jour, et parfois avec moins que toi

Et tu ne démérites absolument pas d'en être déjà à avoir une idée bien précise de ton prochain projet d'importance

et un bref essai de Python / TKinter l'année dernière, abandonné faute de vrai investissement.
Là, j'accroche pas mal sur le C++ que je trouve en fait plus accessible que le python qui fait plein de trucs implicites, mélange les types de variables (en faisant des "transtypages" automatiques si j'ai bien compris), du coup on ne comprend pas forcément comment ça marche, alors que le C++ est plus rigoureux (je ne sais pas si c'est vrai, mais c'est mon ressenti en tout cas).

Je fais bien partie de ceux qui n'arrivent pas à accrocher avec java, uniquement par ressenti personnel... Pourtant je le connais, mais j'aime pas

Si j'arrive à avoir de bonnes bases en C++, je pense que je me laisserai à nouveau tenter par le python, mais pour ça on verra plus tard

Ou peut etre que tu restera à C++

Donc, pour revenir à nos moutons, il faudrait que je pense davantage en C++ et restreindre au maximum le Qt à la seule partie "affichage".

C'est effectivement le principe que j'essaye de mettre en avant

Mais c'est vrai qu'avec la belle doc de Qt, c'est tentant de naviguer dedans, surtout que l'anglais utilisé y est visiblement plus simple par rapport aux docs apparement très éclatées de C++ (et mon anglais pêche pas mal...).

Hé oui, leur doc est vraiment trop bonne

C'est marrant aussi de voir que dans le tutoriel du site "débuter en C++", on ne trouve même pas de façon évidente un lien vers une doc C++. (http://alp.developpez.com/tutoriels/debuter-cpp/).

Parce qu'il n'a pas été conçu à proprement parler comme un tuto, mais plutôt comme une feuille de route...

Il fournit un tas de ressources de qualité qui répondent à la très grosse majorité des besoins que l'on peut envisager

Il y a aussi le fait que la doc elle-même sur les éléments fournis par le standard se compose bien souvent d'une liste de fonctions avec quelques explications et qu'il ne sert sans doute pas à grand chose d'essayer de retenir par coeur l'ensemble des classes et des fonctions fournies par le standard

Il aurait peut etre effectivement été utile de fournir un lien comme cplusplus.com, mais bon, cela fait partie des liens très régulièrement donné sur le forum

Tout ça pour dire qu'avec Qt, on ne se sent pas perdu, on a une doc et pas mal d'outils dedans. Pour les classes de la librairie standard, c'est moins évident. Faudrait que je regarde en détail le site cplusplus.com que vous m'avez mis en exemple.

La grosse différence entre Qt et la bibliothèque standard, c'est que les classes Qt sont destinées à des usages clairement définis, avec une "philosophie" tout aussi bien définie alors que la philosophie de la bibliothèque standard est... d'être tout à fait généraliste...

Il est donc tout de suite beaucoup plus facile de "structurer" la documentation et les exemple pour Qt, simplement parce qu'on sait que si tu t'intéresse à la classe QComBox, c'est que tu veux... présenter une liste déroulante, alors que la classe vector ou la classe map de la stl ne sont jamais que l'implémentation de "concept" de collection, destinés à recevoir... des collections de n'importe quel type d'objet, pour autant qu'ils respectent un certain nombres d'obligations

Pour conclure, merci pour vos remarques, je vais tenter de faire au mieux...

Mais de rien, avec plaisir

Et, surtout, j'espère que tu as bien compris que mon but est simplement de te "pousser dans la bonne direction", et non de te rabaisser ou de te décourager d'une quelconque manière