Discussion :

[Rafy]

Un ami a voulu me coller, et il a réussi, je craque, j'ai plus de cheveu sur le crane
J'ai des objets, qui contiennent un int que nous nommerons altitude.
Il faut qu'en parcourant ce conteneur (avec begin, end) on parcours les objets introduit de l'objet qui a la plus basse altitude à l'objet qui a la plus haute. (en cas d'égalité il n'y a pas d'importance d'ordre).
Jusque la c'est faisable.
La ou ça se complique :
Chaque objet est lié, comme dans un map à une chaine de caractère.
C'est à dire que si mon conteneur s'appel Cont, en apellant Cont["Coucou"] ça me retourne l'objet associé, de même avec l'affectation, Cont["Salut"] = MonObjet, doit introduire l'objet dans le conteneur.
Le truc qui coince c'est que si notre conteneur est un map, le map range ses membre par ordre croissant des Key. On peut redéfinir l'opérateur qui permet le trie, mais je ne vois pas trop comment faire...
Je pense tout de même que la base du truc est un std::map<std::string, MonTypeDObjet>
Merci d'avance.
Si vous n'avez pas compris, dite moi

[Alp]

Salut
Ce lien risque de d'intéresser.
Il suffit de préciser à la déclaration de ta map un foncteur qui sera le critère de rangement ...
Pour toi, il suffira donc de ranger par altitude, n'est-ce pas?

[Rafy]

Je suis d'accord avec toi pour tout ça, mais le truc qui est dur c'est que le foncteur il travail sur les Key, pas sur les données qui sont stockées, or l'altitude est stockée dans la partie donnée !!!!
eheheheh
Elle est là la ruse.
Dans ton exemple, par exemple, il faudrai que je trie les moi non plus par ordre alphabétique, mais par ordre de nombre de jour....

[Alp]

Hmmm ... hé bien là, un sort() n'irait pas?

[Rafy]

Quand on détermine un foncteur dans le map, il va travailler sur les Key qu'on va lui donner.
J'en suis arrivé à me dire qu'il fallait faire un type hybride entre la chaine de caractère et l'int

Code :

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

1
2
3
4
5
struct Hybride
{
    std::string Name;
    int Altitude;
};

Et de définir des opérateur de copie entre mon hybride et les chaines de caractères, pour pouvoir permettre de faire un std::map<Hybride, MonTypeDObjet>, ainsi je peux définir un foncteur valable, mais c'est un truc de fou trop lourd...

[Rafy]

Hmmm ... hé bien là, un sort() n'irait pas?

J'y avais penser mais il faut trier en permance alors...
Juste avant de lire il faut trier, à chaque fois et ça c'est pas dans le cahier des charges, il faut juste apeller l'opérateur operator[](const std::string& ).
Et que dis-je, le sort, je crois que lui aussi il ne travail que sur les Key.

[Alp]

J'y ai pensé aussi, mais pas très pratique ...
Car :

Code :

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

1
2
3
 
tamap[tonHybride] // peu pratique
tamap["Coco434"] // beaucoup plus pratique

Car il faudrait un Hybride par objet inséré ... un peu lourd ...
D'ou la proposition d'utiliser sort, auquel tu peux fournir :
- l'itérateur de début
- l'itérateur de fin
- le prédicat(foncteur retournant bool) permettant de trier

Là tu n'as pas à jouer sur des Key ou quoique ce soit, tu as juste les objets directement à comparer dans ton predicat... et ce, de la manière que tu veux, avec les variables que tu veux ...

[Alp]

Hmm ... dans ce cas tu pourrais faire une class contenant un set et un tableau de string ...
Tu gèrerai l'association des 2 via un opérateur [ ]
Il faudrait juste stocker dans l'objet mis dans le set la string qui lui correspond ...
Et là, pas trop de problèmes.

Mais bon, peut-être long ? ...

Tu préfères sort ?

[Rafy]

J'y ai pensé aussi, mais pas très pratique ...
Car :

Code :

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

1
2
3
 
tamap[tonHybride] // peu pratique
tamap["Coco434"] // beaucoup plus pratique

Car il faudrait un Hybride par objet inséré ... un peu lourd ...

Ce que je voulais faire c'était un opérateur de copie de std::string vers mon Hybride ainsi la copie se ferai de manière implicite :
En définissant l'opérateur je peux faire donc l'insertion :

Code :

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

tamap["coucou"] = MonObjet;

La chaine coucou serai copié dans mon hybride, mais la où sa coince cette fois, c'est que l'autre champs de mon hybride n'est pas renseigné !!!
Je viens de vérifier :
Le test de comparaison qui demande un prédicat.
Ce fameux prédicat, il demande deux objets du type des Key, donc il est impossible de trier avec sort mon map de la manière que je veux
C'est diabolique comme truc.

[Alp]

Et l'idée de class avec le set et tout ?

[Rafy]

Hmm ... dans ce cas tu pourrais faire une class contenant un set et un tableau de string ...
Tu gèrerai l'association des 2 via un opérateur [ ]
Il faudrait juste stocker dans l'objet mis dans le set la string qui lui correspond ...
Et là, pas trop de problèmes.

Mais bon, peut-être long ? ...

Tu préfères sort ?

Hum j'avais pas pensé à ça....
J'avais pensé à un truc de dingue avec des listes... mais pas avec des sets... Il faut que j'étudie ça.

[Rafy]

Alors c'est peu être bon :
Il faut travailler avec un std::set.
Il faut ajouter dans MonTypeDObjet un champ pour qu'il puisse stocker son propre nom.
Coder un foncteur qui va trier les objets suivant leur altitude.
Créer un conteneur perso, qui contient un std::set, créer un opérateur [] pour la lecture, un autre pour l'écriture....
Il faudra comme avec le map, faire gaffe à ne pas mettre dans le set 2 objet référencés par une même chaine.... Grâce à un petit find ça se fera bien.
Ouais ça marche ça !!!! Yes, ça marche. Je suis content !!!! Merci beaucoup Alp, je vais me coucher moins bête ce soir

[Luc Hermitte]

boost.multi_index pourrait fournir des services que tu recherches peut-être ?

Sinon, on retrouve une problématique proche de celle évoquée dans l'article d'Andrei Alexandrescu dans le dernier (:'-() CUJ -- l'article est accessible en passant via developper-pipeline (pas me demander pourquoi ; le lien vers DP se trouve sur le site du CUJ).

Autrement, tu peux passer par une surcouche à un std::set, pour lequel tu as spécifié le foncteur de comparaison. Tu définis ensuite dans ta surcouche les opérateurs [] travaillant sur des clés. De base, la recherche sera en O(n). Sauf si tu te définis trois tableaux dans ton nouveau container
-> les élements non triés
-> un tableau (ou set) d'index sur les clé-chaine (trié)
-> un tableau (ou set) d'index sur les altitudes (trié)
Ce qui t'assurera de meilleures complexités pour les insertions et recherches.

(On retrouve des principes de boost.multi_index)

[Alp]

Pfouh, moi aussi!
Et puis surtout, je vais _enfin_ me coucher.
Enfin c'est une idée que je garde au chaud desfois que j'en ai besoin...
COntent d'avoir trouvé une solution!