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

[Steph_ng8]

mais je suis d'accord avec moi

Encore heureux...

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

Je rajouterai que c'est justement le fait d'être confronté à des cas concrets qui permet de maîtriser les subtilités du langage et les possibilités offertes.
Lorsque l'on a un problème réel, on peut réfléchir à ce que l'on veut exactement, et aux moyens d'y arriver.
Ça donne des pistes, prometteuses ou non ; mais le meilleur, c'est que ça permet de comprendre plus en détails tel ou tel point, et de donner des idées pour des problèmes complètement différents, même si pour le cas présent ça ne donne pas de solution (satisfaisante).

« C'est en essayant qu'on apprend », comme dirait l'autre.
D'ailleurs, c'est bien pour ça que tu fais ce programme, non ?

S'il fallait voir tout ce qu'il est possible de faire rien qu'en regardant les classes disponibles, on ne s'en sortirait pas...

Pour tout le reste, je suis entièrement d'accord avec koala01.
L'investissement de départ pour apprendre le C++ « de base » peut paraître de prime abord rébarbatif, mais sur le long ou le moyen terme, on y gagne.
Après, évidemment, tout dépend du temps que l'on veut/peut y passer.

Concernant la documentation, tu peux également te rendre ici : http://www.sgi.com/tech/stl/.
C'est une documentation assez complète (dans ce qu'elle présente) de la STL, mais peut-être un peu abstraite/conceptuelle.
Ceci dit, elle se concentre essentiellement sur les concepts qui tournent autour des conteneurs (itérateurs, algorithmes, foncteurs...).

[spirzouf]

Merci à vous 2 pour vos conseils avisés.

Je peux dire que j'ai simplement eu un gros coup de déprime...
J'ai pas mal réfléchi à tout ça, et effectivement, vu que mon programme est plus proche de 300 ligne que de 300 000, on efface tout (ou presque) et on recommence... en mode console.

Et surtout, avec un crayon et un papier pendant 2-3 heures cet AM.
En fait, hier j'ai lu un peu le début d'une référence donnée sur ce site, et je me rend compte que je suis partie sur une démarche linéaire (saisie des répertoires - scan des répertoires - affichage du résultat) en prenant comme objet... les onglets ou fenêtres. Bon, qu'en j'y repense, beurk.

Du coup, je vais réessayer en partant de "qu'est ce que je veux faire de mes données ?".

C'est encore en réflexion, mais pour le moment je suis sur 3 classes :
- une classe DirsToScan : contient une "liste" de répertoire à scanner, avec des méthode d'ajout/suppression à cette liste et des méthodes définissant des options globales pour les dossiers (comme la récursivité et le fait de protéger les fichiers dans ces dossier contre l'effacement/déplacement des doublons trouvés). Cette classe contiendrait (par un vector, ou une list, voir un autre conteneur) les dossiers représentés chacun par une classe Directory, a priori sous forme de pointeurs dans le conteneur, mais à voir (pas encore les idées très claires à ce sujet).
- la classe Directory : essentiellement des attributs comme le path, des réglages individuels pour la récursivité et la protection des fichiers contenus.
- une classe Scan : une méthode exec() qui lancerait le scan en fonction de paramètres stockées sous forme d'attributs dans cette classe (type de comparaison, filtres d'inclusion/exclusion, suppression ou déplacement des doublons, sauf s'il ont un statut protégé, etc...)

les classes DirsToScan et Directory sont un peu trop imbriquées à mon goût : où faire l'instance d'un objet Directory : dans le main puis ajout par DirToScan.addDir ? ou directement par DirToScan.addDir qui créé lui-même l'objet, mais dans ce cas, plutôt fusionner les 2 classes ?

Bref, je créerais un autre post avec les prototypes de ces classes et leurs fonctions/attributs quand ce sera à peu près clair pour vous demander vos avis. Je mettrais le lien dans ce post.

A bientôt

[koala01]

Merci à vous 2 pour vos conseils avisés.

Donnés avec plaisir

Je peux dire que j'ai simplement eu un gros coup de déprime...

Je m'en sens un peu responsable, car, si mon avis était donné avec les meilleures intentions du monde, je dois reconnaitre qu'il était un peu brutal et du genre "ce que tu as fait est nul", et je m'en excuses !

J'ai pas mal réfléchi à tout ça, et effectivement, vu que mon programme est plus proche de 300 ligne que de 300 000, on efface tout (ou presque) et on recommence... en mode console.

Ca fait moins mal au ventre

Et surtout, avec un crayon et un papier pendant 2-3 heures cet AM.
En fait, hier j'ai lu un peu le début d'une référence donnée sur ce site, et je me rend compte que je suis partie sur une démarche linéaire (saisie des répertoires - scan des répertoires - affichage du résultat) en prenant comme objet... les onglets ou fenêtres. Bon, qu'en j'y repense, beurk.

Que dire... félicitations

Y en a qui n'arrivent pas à se remettre en question comme tu l'as fait

Du coup, je vais réessayer en partant de "qu'est ce que je veux faire de mes données ?".

Excellente initiative!

En fait, en simplifiant à l'extrême, je conseille généralement de se poser quatre questions, dont tu as déjà une partie des réponses :

1. Que doit faire l'application
2. De quelle données a-t-elle besoin
3. Où (et comment) va-t-elle aller chercher ces données
4. comment va-t-elle les manipuler pour obtenir le résultat attendu

Tu es tout proche d'avoir suivi cette logique

C'est encore en réflexion, mais pour le moment je suis sur 3 classes :
- une classe DirsToScan : contient une "liste" de répertoire à scanner, avec des méthode d'ajout/suppression à cette liste et des méthodes définissant des options globales pour les dossiers (comme la récursivité et le fait de protéger les fichiers dans ces dossier contre l'effacement/déplacement des doublons trouvés). Cette classe contiendrait (par un vector, ou une list, voir un autre conteneur) les dossiers représentés chacun par une classe Directory, a priori sous forme de pointeurs dans le conteneur, mais à voir (pas encore les idées très claires à ce sujet).

- la classe Directory : essentiellement des attributs comme le path, des réglages individuels pour la récursivité et la protection des fichiers contenus.
- une classe Scan : une méthode exec() qui lancerait le scan en fonction de paramètres stockées sous forme d'attributs dans cette classe (type de comparaison, filtres d'inclusion/exclusion, suppression ou déplacement des doublons, sauf s'il ont un statut protégé, etc...)

Ca semble bien parti...

N'hésites pas à demander conseil si tu hésites vraiment trop, nous nous ferons un plaisir de te les donner, et généralement, de les justifier (pour que tu puisse comprendre pourquoi on les donne )

les classes DirsToScan et Directory sont un peu trop imbriquées à mon goût : où faire l'instance d'un objet Directory : dans le main puis ajout par DirToScan.addDir ? ou directement par DirToScan.addDir qui créé lui-même l'objet, mais dans ce cas, plutôt fusionner les 2 classes ?

Malheureuse!!! (comme tu as utilisé le féminin en parlant de toi, je présumes que tu es une fille, si ce n'est pas le cas, n'hésite pas à me reprendre )surtout pas!!!

Il y a deux règles d'or qu'il s'agit de suivre en permanence (en fait, il y en a trois, mais la troisième n'intervient pas dans ce que tu présentes )

La règle dite "de la responsabilité unique" :Si une fonction ou une classe a plus d'une responsabilité, s'occupe de faire plus d'une chose, c'est très certainement que la classe ou la fonction a trop de responsabilité!

Plus tu arriveras à créer des petites classes et fonctions "atomiques", plus tu pourras les réutiliser, et plus tu pourras créer simplement des choses particulièrement complexes en utilisant tes "briques de base", un peu à la manière d'un jeu de légos

La loi dite "demeter", qui dit que si une classe A manipule une classe B et que la classe B manipule en interne une classe C, il n'y a aucune raison pour que la classe A aie connaissance de la classe C.

Un exemple que j'aime bien donner pour illustrer cette loi, c'est celui du réservoir à essence d'une voiture:

Il s'agit d'un objet ayant ses propres caractéristiques dont la responsabilité est... de contenir et de "manipuler" une certaine quantité d'essence.

Nous en attendons donc un certain nombre de services tels que

• dis moi la quantité d'essence qu'il te reste
• rajoute telle quantité d'essence
• retire telle quantité d'essence
• dis moi combien tu peux contenir au maximum

Mais un réservoir d'essence seul n'a strictement aucun sens, car sa seule utilité est... d'être placé dans une voiture!

La voiture manipulera le réservoir, en invoquant le service "retire telle quantité" pour alimenter le moteur, ou les service "quelle quantité maximale" et "que reste-t-il" pour gérer l'affichage de la jauge, ou encore en utilisant le service "ajoute telle quantité" lorsque... l'on fait le plein.

Grace à ces mécanismes, nous ne devrons jamais demander à la voiture "donne moi le réservoir", et, partant de là, nous pourrons utiliser la voiture pendant des années sans même connaitre les détails de celui-ci!

Nous ne serons pas dupes: nous savons pertinemment bien qu'il y a un réservoir à la voiture (autrement l'essence tomberait à terre ) mais on n'a absolument pas besoin de le manipuler directement

Pour répondre à ta question, directory et dirToScan doivent donc bel et bien être clairement séparés, et la fonction main devrait se contenter... de passer les informations qui permettront à dirToScan de créer un objet directory, voir (mais on va un peu loin avec ca ), pour respecter le premier principe que j'ai énoncé, carrément déléguer la responsabilité de la création des directories à... une classe qui ne ferait que cela, sur base des informations nécessaires (on parle de "fabrique" ou de "Factory", vu qu'on aime l'anglais en informatique )

Bref, je créerais un autre post avec les prototypes de ces classes et leurs fonctions/attributs quand ce sera à peu près clair pour vous demander vos avis. Je mettrais le lien dans ce post.

On l'attend avec impatience

[spirzouf]

Bonsoir,

Avant de voir ce post, j'ai posté ici pour la nouvelle structure de mon programme.
Donc tu réponds déjà en partie aux interrogations que j'y présente.

le truc qui m'embêtait pour les 2 classes séparées, c'était plus l'histoire qu'on pouvait potentiellement instancier et manipuler Directory à partir du main. J'envisageait de mettre un lien d'amitié en DirsToScanT et Directory, mais dans ce cas, DirsToScan avait accès direct à tout Directory, et ce n'était pas non plus satisfaisant. Enfin, 3ème voie, c'était de considérer Directory comme un objet semblable au QAbstractItemModel de Qt (dans le sens d'un tableau de valeurs hétérogènes où chaque dossier et ses attribut est représenté sur une seul ligne) et l'intégrer dans Directory, mais au final on en revient au départ, à savoir 2 classes séparés (je ne sais pas si je suis clair, mais ce coup ci, c'est moi qui me comprend )

Après, concernant la question vitale de savoir si je suis une fille ou un gars, et bien que dire que je suis un fille m'apporterait probablement un avantage conséquent en terme de réponses à mes posts , j'ai le regret d'annoncer que je suis un gars... J'ai dû fourcher sur mon clavier je ne sais trop où ?

Pour le coup de déprime, t'inquiète, y'a aussi un contexte et de toute façon, mieux vaut savoir au plus tôt ce qui ne va pas plutôt que de s'enfermer dans des illusions où partir dans des mauvaises directions.

Bon, je passe en résolu sur ce topic, à bientôt j'espère sur le suivant !

[Steph_ng8]

J'ai dû fourcher sur mon clavier je ne sais trop où ?

Ici !

En fait, hier j'ai lu un peu le début d'une référence donnée sur ce site, et je me rend compte que je suis partie sur une démarche linéaire (saisie des répertoires - scan des répertoires - affichage du résultat) en prenant comme objet... les onglets ou fenêtres.

Mais si ça peut te rassurer...

Je suis effectivement débutant et ai fait très peu de programme console C++.

[spirzouf]

effectivement

ça m'arrive parfois sans faire gaffe d'écrire des mots avec la même phonétique, du style "partie" le nom féminin à la place de "parti" le participe passé... Et encore, là c'est pas trop flagrant comme erreur

[koala01]

Après, concernant la question vitale de savoir si je suis une fille ou un gars, et bien que dire que je suis un fille m'apporterait probablement un avantage conséquent en terme de réponses à mes posts , j'ai le regret d'annoncer que je suis un gars... J'ai dû fourcher sur mon clavier je ne sais trop où ?

Oh, ca n'a rien de vital, et ca ne t'apportera surement pas plus de sympathie...

C'est juste que, pris d'un doute, je voulais éviter l'impair en précisant que j'avais un doute

[spirzouf]

salut,

nan, mais c'était pour rire un peu, je me doute que ça n'avait rien de vital