Bonjour à tous, je voudrais trier mon tableau qui contient des équipes en fonction de celui qui a le plus de points, j'ai réalisé le code parfaitement, c'est à dire que ça ne signale aucune erreur au compilation mais le vector n'est pas trié. Je vous présente la partie de mon code source qui gére le tri. Tout aide de votre part sera le bienvenu.

Team.cpp

void Team::win()
{
    t_points+=3;
}

bool Team::estInferieur(const Team& A,const Team& B){
    return A.t_points < B.t_points;
}

Merci

-
Edité par Glitter 16 septembre 2017 à 18:57:08

Salut,

La première chose à faire, si ton tableau n'est pas trié comme tu l'espérais, est de t'intéresser aux valeurs qui auraient du être utilisées.  Après avoir fait gagner les nets deux fois et les bulls une fois, tu devrais peut-être t'assurer que les points acquis ont bel et bien été pris en compte

Ensuite, pourquoi créer une fonction statique de classe ?

Pourquoi ne pas créer des fonctions qui pourraient être proches de

bool lessByPoints(Team const & a, Team const & b){
    return a.points() < b.points();
}
bool lessByName(Team const & a, Team const & b){
    return a.name() < b.name();
}

(étant entendu que la fonction Team::points() renvoie le nombre de point de l'équipe et que la fonction Team::name() renvoie son nom)

Enfin, ta logique (ainsi que celle suivie par lessByPoint) fait que les éléments seront triés par ordre décroissant: l'équipe ayant obtenu le moins de points arrivant la première.  Je présumes que tu aurais sans doute préféré voir le résultat par ordre croissant.

Pour ce faire, rien de plus facile: il suffit de corriger la logique de ton critère de tri pour qu'il renvoie true si la première équipe transmise en paramètre obtient d'avantage de points que la deuxième.

Merci mille fois j'ai enlevé le const et changé l'ordre de tri et ça marche à la perfection

Tu ne dois JAMAIS enlever un const!!!!

Ce mot clé permet de t'assurer que tu n'essayeras pas de modifier un élément là où il n'a aucune raison de l'être.  Il représente donc l'une des sécurités principales que tu peux avoir, car, le compilateur t'engueulera si tu essayes par mégarde d'appeler une fonction qui risque de modifier l'élément depuis une fonction qui n'a aucune raison de le faire.

Tu remarqueras d'ailleurs que j'ai bel et bien mis le const dans mon code d'exemple.  Simplement, je l'ai mis à un autre endroit que toi.

Mais la position du mot clé const ne change absolument rien: simplement, j'utilise la règle de base de son utilisation (le mot clé const s'applique à ce qui se trouve directement à sa gauche ) alors que tu utilises l'exception à cette règle (sauf si rien ne le précède, dans ce cas, il s'applique à ce qui se trouve à sa droite)

Tu peux plus simplement définir l'opérateur '<' qui triera automatiquement ton vector comme souhaité.

Dans la classe team déclare :

bool operator < (const Team& str) const
{
  return (t_points > str.t_points);
}

et tu appelles simplement ton sort avec std::sort(Schedule.begin(), Schedule.end()); qui utilisera naturellement l'operator< défini.

Et effectivement, ce n'est jamais une bonne idée d'enlever les const pour résoudre ses problèmes.

Encore merci pour cette remarque

XaviW a écrit:

Tu peux plus simplement définir l'opérateur '<' qui triera automatiquement ton vector comme souhaité.

Dans la classe team déclare :

bool operator < (const Team& str) const
{
  return (t_points > str.t_points);
}

et tu appelles simplement ton sort avec std::sort(Schedule.begin(), Schedule.end()); qui utilisera naturellement l'operator< défini.

Hummm... Comment dire pour être gentil ??? C'est du grand n'importe quoi.

D'abord, le symbole < est associé à la sémantique "est plus petit que" et ce, dans toutes les langues de l'arc-en-ciel.  Là, tu voudrais lui associer la sémantique "est plus grand que", ce qui risque d'en dérouter plus d'un. 

Y compris le PO lorsqu'il relira son code dans 3 mois ou dans un an, alors qu'il aura eu tout le temps d'oublier le fait qu'il voulait un tri décroissant.  Il voudra alors modifier le code en se disant "mais comment ai-je pu laisser passer une connerie pareille".

Il en arrivera alors à se demander pourquoi l'affichage des équipes se fait dans le mauvais sens (celles qui devraient selon lui apparaitre en dernier apparaissant en premier).

Ensuite, le symbole < a certes une sémantique très claire, mais aussi très imprécise, car beaucoup "trop générale" lorsque tu peux envisager l'idée d'avoir plusieurs critères de tri. 

Cela ne pose pas de problème lorsque la donnée comparée représente un intervalle ou une unité quelconque (un poids, une durée, une distance, une vitesse, ...), mais lorsque la donnée en question est composée de plusieurs données qui pourraient toutes servir de critère de tri, cela ne convient plus parce que cela nie le fait que d'autres critères soient possible.

C'est la raison pour laquelle il est impératif, lorsque tu envisages la possibilité qu'il y ait plusieurs critères de tri, d'indiquer clairement quel critère de tri sera utilisé, et si possible, le sens de ce critère de tri.

Ainsi, j'ai parlé de fonction lessByXXX, mais elles seraient normalement utilisées pour un tri croissant.  Si l'on souhaite utiliser des fonctions spécifiques en vue d'obtenir un tri croissant, il faudrait les appeler greaterByXXX, afin d'éviter tout malentendu.

Enfin, les opérateurs de comparaisons (ou toute fonctions agissant en ce sens) ne devraient jamais être définis comme des fonctions membres d'une classe, car cela pose des restrictions quant à leur usage.  Pour t'en convaincre, observe cette classe "toute bête"

class MyInt{
public:
    MyInt(int i):m_int{i}{}
    bool operator <(MyInt const & other) const{
        return m_int < other.m_int;
    }
    int value() const{
        return m_int;
    }
private:
    int m_int;
};

Elle fonctionnera sans aucun problème avec un code proche de

int main(){
   MyInt a{3};
   MyInt b{5};
   if(a <b){
      /* ... */
   }
}

Et grâce au fait que l'on utilise une référence constante dans l'opérateur < (et au fait que le constructeur de MyInt accepte un paramètre de type int), nous pourrions tout aussi bien écrire un code qui serait proche de

int main(){
    MyInt a{3};
    int i{5};
    if(a < i){
        /* ... */
    }
}

(c'est ce qui s'appelle utiliser une variable temporaire anonyme)

Et, du coup, on se dit que le code

int main(){
    MyInt a{3};
    int i{5};
    if(i < a){
        /* ... */
    }
}

devrait fonctionner itou, non? Hé bien, essaye de compiler ce code, et tu te fera jeter sous prétexte qu'il n'existe aucun opérateur < prenant un int en premier paramètre et un MyInt comme second paramètre.  La raison est toute simple : cet opérateur ne fonctionne que si l'opérande de gauche est de type MyInt.

Par contre, si tu modifies la classe MyInt de manière à ce que l'opérateur < soit une fonction libre, lui donnant la forme de

class MyInt{
public:
    MyInt(int i):m_int{i}{}
    int value() const{
        return m_int;
    }
private:
    int m_int;
};
bool operator < (MyInt const & a, MyInt const & b){
    return a.value() < b.value();
}

Alors, tu n'auras plus de problème à écrire le code que je viens de montrer, car tu pourras aussi utiliser la variable temporaire anonyme comme opérande de gauche.

(PS: je sais, j'ai occulté certains autres problèmes, pour garder une explication simple )

-
Edité par koala01 10 septembre 2017 à 22:06:09

L'operator < ne signifie pas forcément "est plus petit que", c'est le tri par défaut d'un vecteur qu'il faut définir pour trier des objets... tu te fais une montagne pour quelque chose que tu ne semble pas avoir bien saisi.

Enfin, si t'a le temps pour ça...

XaviW a écrit:

L'operator < ne signifie pas forcément "est plus petit que", c'est le tri par défaut d'un vecteur qu'il faut définir pour trier des objets... tu te fais une montagne pour quelque chose que tu ne semble pas avoir bien saisi.

Enfin, si t'a le temps pour ça...

Non, c'est toi qui ne semble pas assimiler le fait que, depuis l'école primaire, tout le monde apprend que < signifie "plus petit que", et que si tu commence à détourner son sens pour exprimer que c'est "juste un critère de tri", tu risques d'en larguer plus d'un au passage. Dont l'auteur du code lui-même, si tu lui laisse "assez de temps" pour oublier la raison qui l'a poussé à implémenter l'opérateur < d'une manière "non conventionnelle".

Et, contrairement à ce que tu crois, je n'ai pas vraiment le temps pour cela, mais je me force à le prendre.

Parce que j'ai appris il y a longtemps déjà que mon rôle, en tant que développeur, est de me casser la tête pour éviter que ceux qui "viendront après moi" ne doivent le faire.

Et parce que je sais que les quelques secondes que j'aurai "perdues" à réfléchir à un nom correct pour exprimer l'usage d'une fonction par son nom m'évitera d'en perdre bien plus à me poser des questions idiotes ou à mal utiliser ma fonction par la suite.

On dit souvent, en parlant de l'utilisateur que c'est un imbécile distrait, que 90% des bugs trouvent leur origine entre la chaise et le clavier.

Mais il faut bien te dire que tu n'es le développeur des fonctions que tu développes que le temps d'en déterminer la logique et d'en écrire le code.  Une fois cette étape franchie, tu deviens un utilisateur de la fonction comme n'importe qui d'autre, et tu es donc soumis aux même contraintes.

Rends toi service, à toi et/ou à l'équipe avec laquelle tu travailles: ne commet pas l'erreur de croire que tu (ou ton équipe) es à l'abri d'une erreur provoquée par la distraction ou par une mauvaise interprétation. 

Mais pars du principe que, selon la loi de Finagle, s'il n'y a qu'une connerie à faire, ce n'est qu'une question de temps avant que "quelqu'un" ne la fasse.

Fais plutôt en sorte d'empêcher quiconque de faire n'importe quelle connerie.  Tu verras, cela t'évitera bien des cheveux blancs et des séances de débugage

@XaviW: Pour appuyer ce que dit Bacelar, on va prendre l'exemple des voitures.

Lorsque l'on dit qu'une voiture est plus petite qu'une autre, la majorité des gens se référerons au volume qu'elle occupe, tu écriras donc ton operateur "inférieur à" en ayant cela en tête.

Puis arrive le premier cas particulier: le vendeur, qui compare par prix.
Puis arrive le second cas particulier: Le pilote de course qui compare par chevaux sous le capot.
Puis arrive le 3e cas particulier: ect ect ...

oula .... ca fais bcp de cas particuliers qui utilisent les même mots, mais ne parlent pas tout à fais de la même chose....

Conclusion: Soyons précis, ca évite les cas particulier (et tous les désagréments qui vont avec).

Slt les gars c'est encore moi

Entre temps j'ai crée deux autres classes, j'ai donc Team(qui contient les infos sur le équipes), Table(qui trie les équipes et affiche le classement) et Game(qui gère les matches). J'ai alors implanté la fonction sort dans la classe Table au lieu de la classe Team, car ça me semblait plus logique cependant après compilation ça m'affiche un nouveau header stl_algo.h, je ne sais pas vraiment ce que cela veut dire alors que tout me semble normal.

#include "Table.h"
#include <vector>
#include <algorithm>

using namespace std;

Table::Table(): t_listeTeams(0) {}

Table::~Table()
{
    for (int i(0); i<t_listeTeams.size(); i++)
    {
        delete t_listeTeams[i];
        t_listeTeams[i] = 0;
    }
}

bool estDevant(Team const& A,Team const& B)
{
    return A.points() > B.points();
}

void Table::addTeam(Team *newTeam)
{
    t_listeTeams.push_back(newTeam);
}

void Table::affiche()
{
    sort(t_listeTeams.begin(),t_listeTeams.end(),estDevant);
    for(int i(0); i<t_listeTeams.size(); i++)
    {
        cout << i << " - " << *t_listeTeams[i] << endl;
    }
}

Voici le fichier Table.h

Je tiens à préciser que je travaille avec CodeBlocks 13.12 in ça a un rapport avec le IDE.

-
Edité par Glitter 11 septembre 2017 à 21:21:27

Juste un petit problème de syntaxe, quand tu utilise une fonction (libre ou membre), alors il faut l'écrire comme ça:

std::sort(t_listeTeams.begin(),t_listeTeams.end(), &estDevant);

J'ai ajouté & devant le comparateur et ça ne fonctionne toujours pas. Je pense que l'erreur se situe au niveau des t_listeTeams.*, lorsque je mets un * devant le console s'ouvre et reférme automatiquement en m'envoyant un code d'erreur.

void Table::addTeam(Team *newTeam)
{
    t_listeTeams.push_back(newTeam);
}

C'est suspect ça ! (mot clef: pointeur)
On peut voir les definitions complete des classes Table et Team ?

Je t'invite également à réflechir sur le sens de la classe Table (conteneur direct ou indirect), la sémentique de la classe Team (valeur ou entité), ainsi que la notion de propriétaire entre tes deux classes.

-
Edité par Deedolith 12 septembre 2017 à 10:36:56

Table.h

class Table
{
private:
    std::vector <Team*> t_listeTeams;
public:
    Table();
    ~Table();
    void addTeam(Team* newTeam);
    void affiche();
};
bool estDevant(Team const& A, Team const& B);

Team.h

#ifndef TEAM_H_INCLUDED
#define TEAM_H_INCLUDED

#include <string>
#include <iostream>
#include <vector>

class Team
{
private:
    std::string t_name;
    int t_points;
public:
    Team(std::string name);
    void show(std::ostream &Flux)const;
    int points()const;
    void winPoints();
    std::string name() const;
};
std::ostream& operator<<(std::ostream &Flux, Team const &B);

#endif // TEAM_H_INCLUDED

-
Edité par Glitter 12 septembre 2017 à 12:52:39

Pourquoi un std::vector<Team*>, c'est trop hautement casse-gueule (C++ est un langage à exception). Si tu veux des pointeurs sur Team, il faut faire un vecteur de pointeurs intelligent typiquement ici un std::vector<std::unique_ptr<Team>>.

void Table::addTeam(std::string const & name)
{
   t_listTeams.push_back(std::make_unique<Team>(name));
}

// tri

std::sort(std::begin(t_listTeams),std::end(t_listTeams),
     [](std::unique_ptr<Team> const & lhs,std::unique_ptr<Team> const &rhs)
         {return estDevant(*lhs,*rhs);});

Mais tu peux probablement te débrouiller sans pointeurs et utiliser simplement un std::vector<Team> quitte à définir le move constructor et le move assigner, si tu veux que ta classe soit non copiable, il serait assez logique qu'elle le soit, étant donné que la notion de Team a très clairement une sémantique d'entité.

-
Edité par int21h 12 septembre 2017 à 13:34:55

C'est bien ce que je pensais: Des pointeurs nu.

Ta fonction estDevant ne peut fonctionner en l'état.
Elle recevra en paramètre ce sur quoi pointent les iterateurs, en l'occurence des pointeurs vers des objets de type Team (puisque t_listeTeams contient des pointeurs).

Je laisse mes co-intervenants te tapper sur les doigts à propos de la sémantique de la classe Team, ainsi que les pointeurs nu.

Edit: *grilled*

-
Edité par Deedolith 12 septembre 2017 à 13:44:44

@Deedolith, Le problème est réglé grâce à ton aide et j’accepte de me faire taper, c'était tellement évident.

Pour la  class Team, elle contient  les propriétés relatifs à une équipe. J'arrive pas à voir ce qu'il y a avec la sémantique.

Si ta team joue à Marseille, elle ne peut pas jouer en même temps à Bordeaux. Ta team possède la caractéristique d'être unique, c'est à dire qu'elle ne peut exister à un instant donné qu'à un seul endroit. C'est ce qui caractérise une entité. Pour les objets qui ont cette propriété, on parle d'objets à sémantique d'entité.

int21h a écrit:

Si ta team joue à Marseille, elle ne peut pas jouer en même temps à Bordeaux. Ta team possède la caractéristique d'être unique, c'est à dire qu'elle ne peut exister à un instant donné qu'à un seul endroit. C'est ce qui caractérise une entité. Pour les objets qui ont cette propriété, on parle d'objets à sémantique d'entité.

Ce qui implique donc, que les objets à sémantique d'entité ne sont ni copiables, ni assignables.
C++ offre une mécanique enforçant cela:

class Entite
{
private:
public:
	Entite(Entite const&) = delete;		 		// suppression du constructeur de recopie
	Entite& operator=(Entite const&) = delete;	// suppression de l'operateur d'assignation
};

Ainsi, le compilateur se plaindra si tu essaies de faire une copie.

Je comprends ce que vous voulez dire par Objets à sémantique d'entité, je voudrais savoir comment j'ai réussi à définir ma classe Team comme tel sans pour autant m'en rendre compte ?

Tout simplement parce que la sémantique d'une classe (ou d'un type de donnée, de manière plus générale) n'est qu'une notion purement conceptuelle.  Or, le langage n'a aucun droit de regard sur la conception.  Ca, c'est l'affaire du type qui est devant son clavier: Si le type fait une erreur, le langage et le compilateur dit "amen" et fait comme le type a dit de le faire.

Par contre, on a fait en sorte de pouvoir dire au compilateur que "je ne veux pas pouvoir copier ou assigner les différentes instances de telle classe" (ce qui est la grande caractéristique des types ayant sémantique d'entité), et on lui a donné les outils pour refuser systématiquement toute tentative de copie et d'affectation.

Si bien que, une fois que tu le lui a dit, en brave petit soldat, le compilateur respectera scrupuleusement tes ordres.  Mais, tant que tu ne lui dit rien, il n'aura aucune raison de s’immiscer dans la conception, et partira du principe que ta classe peut -- à l'instar de ce qu'a décrit Coplien -- être créée, copiée, assignée et détruite

Slt c'est encore moi

J'ai étudié la notion de sémantique d'entité sur http://guillaume.belz.free.fr/doku.php?id=semantique_d_entite, ça a été très bien expliqué mais est ce vraiment nécessaire de définir la class Team comme tel en sachant déja qu'on ne vas pas copier des Objets de type Team, ni les comparer, ni les additionner en plus il n'y a pas d'héritage entre les classes. Ce que je veux dire est que Est ce obligatoire de déclarer ma classe Team comme tel, ou bien si ça fait juste parti des bonnes manières de coder

lax95 a écrit:

Slt c'est encore moi

J'ai étudié la notion de sémantique d'entité sur http://guillaume.belz.free.fr/doku.php?id=semantique_d_entite, ça a été très bien expliqué mais est ce vraiment nécessaire de définir la class Team comme tel en sachant déja qu'on ne vas pas copier des Objets de type Team, ni les comparer, ni les additionner en plus il n'y a pas d'héritage entre les classes. Ce que je veux dire est que Est ce obligatoire de déclarer ma classe Team comme tel, ou bien si ça fait juste parti des bonnes manières de coder

Tu veux dire : sachant que l'on va essayer de ne pas la copier, en fait ?

Une erreur est très vite arrivée, il suffit d'oublier un & "quelque part" pour qu'une copie soit effectuée.  Et tu peux me croire, c'est le genre de truc que l'on oublie encore assez facilement, surtout au début

En disant au compilateur que tu ne veux pas qu'une instance de ta classe soit copiée ou assignée à une autre, tu feras du compilateur ton meilleur allié, car, si une copie ou une assignation est tentée "par erreur", il te le signalera, et il sera plus buté que toi : tant que l'erreur subsistera, il t'engueulera et refusera de travailler correctement

Quand tu écris en français, te dis-tu "Ai-je besoin de mettre toutes ces lettres muettes quand, de toute façon, on me comprend ? Je joue pas ma vie." ? Si la réponse est non, alors dis-toi que si tu le fais tout le temps, ça deviendra un automatisme : "Ma classe a-t-elle sémantique d'entité ou de valeur ?", "Qui a la charge de libérer cette ressource ?",... Ce sont des questions simples mais elles évitent 95% des bugs.

De plus, si tu indiques clairement à ton compilateur "cette classe ne peut pas être copiée.", il te donnera un message d'erreur à la compilation.

-
Edité par anolya 16 septembre 2017 à 16:49:42

Merci pour vos précisions, je vais me familiariser avec cette notion  alors😁🤓

-
Edité par Glitter 16 septembre 2017 à 18:13:59

Slt à tous c'est encore moi ^^, j'ai décidé de revenir ici plutôt que de refaire un nouveau sujet sur le site parce que ça concerne toujours le même projet. J'ai terminé la partie sur Qt du cours de Mateo21 et je voudrais refaire mon projet en GUI. J'ai déjà dessiné l'interface de mon programme(voir capture d'écran ci-dessous), mais je ne sais vraiment pas comment procéder c'est à dire si je dois refaire tout le projet et dans ce cas comment instancier un objet, comment  insérer un Objet Team dans le tableau, où faire le tri etc... ou bien s'il y'a un moyen plus direct de transformer mon programme console en programme GUI.

Sur CodeBlocks

Sur QtCreator