Reprise du message précédent :

C'est le métier qui veut ça. Tu es sûr de vouloir devenir développeur ?  

Pas vraiment, m'enfin on ne sait jamais

Mon diagramme de classes
 

 
(je précise que je suis novice en UML   )
 
Le point d'entrée est un groupe racine (pas de groupe parent)

Bon, j'avance avec ma fonction de recherche récursive, mais ... Elle fonctionne quand il s'agit de renvoyer des char*, mais dès que la change pour qu'elle renvoie des pointeurs sur des List::Node, ça marche plus, l'appel récursif ne se fait pas
 
Voyez par vous-meme:
 

 
Tout fonctionne à tous les niveaux de hierarchie de groupes. Mais maintenant:
 

 
Il ne me trouve plus que les résultats de 1er niveau, on dirait que l'appel récursif ne se fait pas
 
 
 
 
         

Je réitère ma remarque : pourquoi avoir un deuxième argument de type Liste, alors que ta fonction estPresentFull est membre de la classe Liste ?
 
Encore une fois, tu as mélangé uneListe avec la liste appelante : lorsque tu crées l'itérateur, c'est bien sur uneListe, mais par contre ton test estVide() s'effectue sur la liste pointée par this
 
Pourquoi ne pas faire tout simplement :

 
Jep c'est vrai, j'ai oublié le if(!estVide()), mais si je garde le 2eme parametre et que je mets if(!uneListe.estVide()), ça reviens à la meme chose

 
C'est vrai, pourquoi faire simple alors qu'on peut faire compliqué

Bon j'ai fait comme tu as dit, m'enfin j'ai tjrs une erreur de pointeur ... quand l'objet recherché est ds le 1er niveau, c'est bon il trouve. Sinon, paff

La réponse de mon prof par mail (jlui avais posé la meme question)
 

 
Qqun m'aide à surcharger l'operateur == ?  

google

Je comprends pas trop comment marche ton truc :

• Qu'est-ce que la fonction est censée renvoyer quand elle n'a pas trouvé l'objet recherché
• A quoi sert le bloc "else" du "if(!estVide())" : si ta liste est vide, tu ne peux rien chercher dedans
• tu devrais tester le retour de l'appel récursif: si tu as trouvé l'objet cherché, il faut s'arrêter tout de suite

Heu ton prof t'a encore conseillé une solution mettant en oeuvre reinterpret_cast<> alors finalement te fais pas chier : code n'importe quoi n'importe comment pour peu que ça ressemble à du C++ et si possible que ça marche...  
 
Au fait personne n'a parlé de mon design...  

C'est quoi ces reinterpret cast tout laid la ? le bout de code donné par le prof, il se trouve ou ? pas dans la liste, quand meme ?

Je suis entièrement d'accord avec ça. Par contre, je tiens à insister sur le fait que les formes (et groupes) devraient être stockés dans une grande liste (ou plutôt hashmap) sans se soucier de la hiérarchie. Ceci simplifierait grandement la recherche d'une forme particulière et le déplacement des formes de groupe en groupe...

Le reinterpret_cast, c'est moi qui l'ai mis la. Je ne voyais pas d'autre solution pour transformer un pointeur sur un objet en pointeur sur un Groupe. Mais bon, ça marche ... et c'est mon objectif primaire. ça marche plutot bien, d'ailleurs... sauf la recherche globale récursive
 
Est ce que ces 2 lignes de code sont identiques ?
 

 
Ou, autrement dit, peut-on appeller une méthode (estPresentFull) sans mettre d'instance de classe devant ?

Tu ne peux appeler une fonction membre sans mettre d'objet devant que si la fonction en question est statique. Dans ce cas, la fonction en peut faire appel qu'à des données membres statiques, et sa valeur de retour est donc indépendante de l'instance pour laquelle tu l'appelles. L'appel de la fonction sans préciser d'instance a donc un sens. Du coup, si maliste1 et maliste2 sont deux instances de la classe Liste, les appels maliste1.foncStatique(), maliste2.foncStatique() et Liste::foncStatique() sont tous équivalents.
 
Dans ton cas, la fonction membre estPresentFull n'est pas statique, ce qui signifie que tu DOIS l'appeler pour un objet particulier, comme dans tmp->getMonGroupe().estPresentFull(...)
Si tu es dans le contexte d'une fonction membre (non statique) de la classe et que tu ne précises pas d'objet particulier, la fonction membre sera appelée pour l'objet courant this.
Dans ton cas, l'appel estPresentFull(...) est équivalent à : this->estPresentFull(...)

Merci
 
Jy retourne

En poussant un peu, je me dis que Shape:: label doit être un discriminant de la relation d'agrégation entre Groupe et Forme. Ainsi, un groupe ne peut contenir que des groupes et formes de nom différent.    
 
Le problème se pose pour assurer la même unicité de nom dans toute la hiérarchie...  
 
A moins, qu'on permette un adressage hiérachisé de ce genre là :
/groupe1/groupe5/groupe1/triangle25
 
[Séquence nostalgie...]
 
Ca me rappelle un système graphique que j'ai mis au point:
 
J'en avais marre des systèmes graphiques qui ne gèrent qu'un seul repère métrique (souvent exprimé en pixels qui plus est) alors que par exemple je voulais représenter une figure ne nécessitant pas plus de 10 unités de large et 5 unités de haut - unité étant une métrique abstraite. En l'occurence, il était très compliqué et pas du tout souple d'adapter les objets graphiques à l'espace disponible à leur représentation (affichage à l'écran, sur imprimante, etc).
 
Je voulais un système s'appuyant infine sur GDI qui me permettait de manipuler des sous-ensembles graphiques combinés les uns aux autres et disposant d'un repère de coordonnées propre! L'espace disponible pour leur représentation devait être géré au mieux selon des règles de comportement définies pour chaque objet graphique !
Au besoin, je devais pouvoir afficher uniquement une vignette et ses composants graphiques.
 
L'objectif ultime : disposer d'une planche graphique qui s'adpate à la surface disponible pour sa représentation (et au sens du système de coordonnées sous-jacent) mais dont les éléments n'étaient pas figés. Bien entendu, la gestion devait être rigoureuse et supprimer un objet ou une vignette devait libérer tous les composants sous-jacents ainsi que les outils graphiques nécessaires à sa représentation (plusieurs composants graphiques pouvaient se partager un pool d'outils graphiques commun)!
 
Autre exigence: je voulais pouvoir changer dynamiquement la plage d'adressage de chaque repère et que ma représentation graphique s'adapte en conséquence!  
 
En option, chaque planche autorisait une mode "respect du ratio hauteur/largeur" et un centrage paramétrable.
 
Le principe était de gérer une superposition de planches chacune disposant de son repère métrique propre et insérée dans un planche de plus haut niveau (n'importe laquelle !) en spécifiant un rectangle exprimé dans le repère du plan englobant. En plus l'unité métrique était libre : entier, réel, date (coton a traiter celui-là), etc. Le tout permettait un rendu graphique totalement vectoriel et dynamique à la manière des IHM java. Chaque objet graphique était nommé de manière unique au niveau d'un plan  
 
A la fin, j'ai spécialisé certaines classes pour produire un présentation de graphes comportant des courbes, des axes, des graduations d'axes (plage de graduation, pas de graduation, - le tout défini dans le repère du graphique!)  
Le top, modifier les plages d'abscisses et d'ordonnées du graphe pour le voir s'adapter sans aucun effort. Hop une fonction zoom sans frais!
 
J'ai poussé le vice jusqu'à pourvoir définir un système personnalisable et extensible pour représenter les traits, les formes pleines,... Gros délire, à la fin je pouvais, en une seule instruction, peindre le fond d'une planche en vert et dessiner un rectangle à bord arrondi en rouge d'une largeur définie (dans le repère de la planche concernée)
 
Enfin, j'ai ajouté un système d'adressage hiérarchisé par nom (y compris pour les objets responsable du rendu graphique!).
 
Qu'est-ce que je me suis éclaté là-dessus. Pas long pourtant.

Oui mais dans ce cas, tu doubles le nombre de références sur les formes et les groupes qui sont déja disponibles.

que veux-tu dire ?

La classe Groupe gère, à son niveau propre, le listing des groupes et celui des formes. On peut donc énumérer tous les objets de la hiérarchie et y accéder sans risque. L'agrégation suppose que les formes sont manipulées par un groupe (à défaut par le groupe racine)
 
Le modèle se suffit donc à lui-même. L'index "à plat" que tu proposes est intéressant pour optimiser la recherche dans l'arbre. Dans le cadre d'un projet d'étude, il est peut être inutile de compliquer la réalisation.

C'est vrai que ça demanderait sûrement un gros effort de reconception. Autant garder la structure hiérarchique déjà bien avancée.
 
En tous cas, il est intéressant de voir les problèmes qui se posent à partir d'un sujet qui paraît au premier abord assez simple.
 
ParadoX > Bon courage !!!  Au fait, il est pour quand ce projet ?

Pour lundi ^^
Tout fonctionne, sauf la recherche globale récursive.  
 
Elle plante quand:  
 

• On recherche qqch qui n'est pas dans la liste (:D)
• On recherche un objet qui est en derniere position d'une liste

 
Si qqun a une solution pour virer ce "goto" (la 1ere fois que j'en utilise un, c'est pratique   ), je prends. Je ne veux faire la recherche "simple" qu'une seule fois, sur la liste de départ.
 
 

Pour l'instant, tu ne traites pas du tout le cas où tu ne trouves jamais l'objet. En fait, dans ce cas, ta fonction ne passe jamais par une instruction "return" et tu dois récupérer n'importe quoi en sortie (en fait, je suis surpris que ton compilo ne te donne pas de warnings)

 
En ce qui concerne les objets en dernière position, il faut voir d'un peu plus près. Comment fonctionne exactement ton finDeListe() ?
Si fin de liste renvoie true lorsque l'itérateur est placé sur le dernier élément, alors celui-ci n'est jamais parcouru dans ton while car tu fais ton iterateur.avance() à la fin de la boucle.
 
 

Je ne comprends pas trop ce que tu fais avec ta recherche simple.
 
Mais en tous cas, ton goto ne sert absolument à rien ici : il ne fait que demander à exécuter le bloc else dans tous les cas ... ce que tu peux aussi bien faire en sortant toutes tes instruction du bloc else:

Un rush quoi    
 
A quoi sert le paramètre uneListe ? On a déja formulé une remarque dessus.
 
Quelques conseils:
- choisi un titre de méthode descriptif. J'ai été incapable de comprendre ce que faisait ta méthode en première lecture!
- il n'est pas utile de déclarer ta méthode statique (enfin je suppose que c'est l'explication au paramètre uneListe   dans le prototype de la méthode)
- avant de coder le corps de ta méthode réfléchi à l'algorithme voir pose le par écrit. Une technique consiste à mettre en commentaire dans le code, les étapes de l'algorithme et expliquer (justifier?) les instructions conditionnelles.

 
Bien sûr il te faut réajuster le code avec tes classes à toi.

Merci, j'ai refait l'algo de recherche, mais encore un petit truc qui cloche.
 
J'ai avancé dans la recherche récursive, elle est structurée plus logiquement. Seul probleme: quand il s'agit de "redescendre" dans la hierarchie, ça pose des problemes. Voyez vous-même:
 
Plan de maListe, dans laquelle on va effectuer les recherches:
 
+--Groupe
+------Rond2
+------Groupe2
+----------LeRond777
+--Groupe4
+------Groupe3
+----------LeTriangle
+----------LeTriangle2
+--Groupe5
+-------LePolygone
+--LeCarre
 
Code:

Annotatiions:  
Pour la recherche, l'algo est le suivant:
 
2 Iterateurs sur la Liste, un principal et un de recherche
Tant que l'itérateur de recherche n'arrive pas en fin de liste:
- Si le noeud recherché est l'actuel, trouvé !
- Sinon:  
--> C'est un Groupe  
--> on refait une recherche dedans, en lui précisant cette fois ce groupe comme Liste
 
ou bien
 
--> C'est une Forme, 2 cas:
----> C'est la derniere forme d'une liste, auquel cas il faut "revenir dans la hierarchie" (exemple: LeRond777)
----> Ce n'est pas la derniere forme, on continue
 
L'algo trouve LeRond777, mais plus le Groupe 4 ! Alors je me suis dit qu'il faut faire revenir l'iterateur de recherche au même niveau que l'itérateur principal, puis recommencer (on se retrouve alors dans le même cas de figure qu'au début, à savoir que les 2 itérateurs sont au meme niveau)
 
Quand je mets monIterateur = monIterateurPrincipal là ou il ya "#Position" dans les commentaires du code, l'algo me trouve tous les objets jusqu'au triangle2 inclus ! Sauf qu'il plante quand il arrive au groupe 5 qu'il ne trouve plus.
 
Avez-vous une idée ? Je ne suis pas loin de la fin !
Désolé pour le pavé ^^

Je comprends rien à ton algo : pourquoi as-tu besoin de deux listes (et même trois avec 'this') et deux itérateurs ?
Pourquoi as-tu besoin de gérer à la main les remontées dans la hiérarchie (alors que c'est la récursivité qui s'occuppe de ça)
Dans le cas où ta liste de départ est vide, tu ne passes toujours par aucune instruction return ...
 
Bref, tout ça est bien compliqué pour pas grand chose.
 
Pourquoi ne pas faire quelque chose de plus direct, dans le genre de ça :

Le probleme c'est que si l'objet recherché est un groupe vide !
 
Genre le groupe 2:
 
+--Groupe
+------Rond2
+------Groupe2 (vide)
+--Groupe4
+------Groupe3
+----------LeTriangle
+----------LeTriangle2
+--Groupe5
+-------LePolygone
+--LeCarre  
 
 
Je sais pas encore pkoi, mais ton code plante ^^ Jvais débugger, m'enfin ça m'étonnerait que ça soit si simple !

Mais tu te prends vraiment la tête pour rien.
 
Tu construis une méthode Liste::TrouveObjet(const char* leNom, ...)
 
De ce fait elle est utilisable pour n'importe quelle Liste donc aussi bien pour la Liste de premier niveau que la Liste gérée dans un groupe.
 
La méthode a seulement à faire ceci:
 

il ne devrait pas y avoir de problème avec les groupes vides : dans ce cas tmp->getMonGroupe() doit être une liste vide, et l'appel récursif de estPresentFull() doit renvoyer immédiatement NULL
 

Ca veut dire quoi, "plante" ?

Le prof m'a donné un coup de pouce,  
 

 
ça marche maintenant. C'était le  
 

 
que j'avais jamais mis
 
Merci beacoup à tous
La semaine prochaine je vous dirai la note qu'on a eu ^^
 
 

Ce code est une horreur. Simple avis personnel.

Pkoi ?  
 
N'oubliez pas que vous autres programmeurs voyez ça d'un autre angle que moi, et qu'avec le recul que vous avez ça peut vous choquer. Pour moi, aucun pas n'est injustifié dans ce code

+1
 
 
Pour commencer, je n'arrive toujours pas à comprendre pourquoi tu fais une méthode statique avec 2 arguments alors que le seul argument devrait être l'étiquette à rechercher, et la seule liste impliquée dans l'affaire est this.

Tu n'as pas vu le code que je t'ai proposé alors.
http://forum.hardware.fr/hardwaref [...] m#t1317579
 
Combien vois tu de return ? As tu du mal à lire le code et comprendre l'algorithme ?

C'est pourtant le prof qui m'a dit (mot pour mot, dans son mail) :
 

 
Le coup des return multiples, etc ... c'est une question de point de vue. La philo de notre prof c'est "Moi je fais du c++, pas de l'algo" !
Alors c'est peut-être à l'encontre de vos idées (et de la plupart des programmeurs ), mais moi on m'apprends comme ça cette année. Et c'est la première année ou je fais vraiment du C / C++.
 
Je vais néanmoins essayer de modifier la fonction pour n'avoir qu'un seul return et de ne lui donner qu'un char* comme parametre, si vous dites que c'est moche / pas utile ce n'est certainenement pas injustifié. Il faut juste se mettre à ma place aussi
 
Merci pour toutes vos aides, je n'y serais probablement pas arrivé sans tout ça, et je vais quand meme revoir ce que vous m'avez conseillé  
 
 

Faire du C++ n'interdit pas d'apprendre les pratiques à éviter.
 
La multiplication des return et des goto est néfaste au programme sauf pour une utilisation justifiée.
 
Si ton prof dit vous apprendre à faire du C++ sans vous avoir enseigné les rudiments de l'algorithmie, il fait fausse route. En théorie tu commences par concevoir l'algorithme avant de coder.
 
N'oublies pas que la lisibilité de ton programme est aussi importante que le bon fonctionnement de celui-ci. Si un jour tu es amené à utiliser ou maintenir un système que tu n'as pas créé, ais une pensée pour moi.

 
pour les return, je proteste.
 
je prefere largement un truc genre
 

a  

Je suis plutôt de l'avis de chrisbk : il me paraît assez lisible d'évacuer les cas faciles avec des 'return'.
 
Ce qui me gêne dans le code de ParadoX, c'est plutôt le reinterpret_cast et la signature de la méthode.
 
 

Et pense à moi aussi

La signature est corrigée, un seul *this suffit effectivement
Les return, j'ai laissé ... autant dans une fonction "normale" je l'aurait corrigé, mais dans une fonction récursive c'est moins facile
 
Enfin, le reinterpret_cast, je n'ai pas trop le choix, cf le design de mes classes !
 

Oui mais il s'agit du "cas particulier" que j'évoquais, c'est à dire quand cela facilite la lecture.
 
Je suis un habitué du  
 

 
Mais les return dans les boucles ben je ne le sens pas (et ça peut compliquer le debuggage)
 
Deux écoles s'opposent sur cette question, il me semble.