Méthode d'affichage et prob de const

Version imprimable

06/01/2008, 11h00
allserv

Méthode d'affichage et prob de const

Bonjour tout le monde,

J'ai un petit problème concernant ma méthode d'affichage.
Cette méthode contient la définition suivante :

Code:

void Recette::afficher_mieux(std::ostream& os) const{

J'aimerais savoir s'il est possible dans le corps de cette fonction d'appeler une autre fonction modifiant une variable locale de celle-ci ?

Exemple : dans le corps j'ai ceci

Code:

modifSousRecette(ingredients,(*it).first,(*it).second,1.00);

Le compilateur me sort :

Citation:

103 passing `const Recette' as `this' argument of `void Recette::modifSousRecette(string_double_map&, Ingredient*, Quantite*, double)' discards qualifiers

Cette erreur est-elle due au mot clé const ? Comment faire pour résoudre ca ?

Merci d'avance
06/01/2008, 11h18
yan

Bonjour,
Oui, mais ce n'est pas une erreur.
T'as fonction est const, elle ne doit donc pas modifier la class pendant l'appel. A part les variable mutable, si je ne me trompe pas.
Pourquoi l'affichage devrait modifier t'as class??
06/01/2008, 11h27
allserv

Cet affichage doit récuperer par exemple les matieres premieres. Cette classe contient une map d'ingredient (classe mere de Recette et Matiere) et de Quantite.

Lors de l'appel de cette fonction d'affichage je souhaitais créer une map temporaire de <string,double> (variable locale appelée ingredients) que j'allais modifier gràce à l'appel de la fonciton récursive :

Code:

modifSousRecette(ingredients,(*it).first,(*it).second,1.00);

Et après l'appel je n'aurais plus qu'a afficher ce que contient la map.

Comment faire ?
06/01/2008, 11h35
yan

Citation:

Envoyé par allserv

Lors de l'appel de cette fonction d'affichage je souhaitais créer une map temporaire de <string,double> (variable locale appelée ingredients)

Tout compte fait t'as choisi une map alors :D.
Sinon une variable local à la fonction y as pas de problème, tu peut la modifier. Pour faire ce que tu veut il faudrait que it soit un const_iterator et que
modifSousRecette soit const aussi.
Peut tu montrer le code de cette fonction?
06/01/2008, 11h42
allserv

Ah d'accord, je viens de mettre const à ma fonction recurisve et du coup je n'ai plus cette erreur.
En fait je pensais que le mot clé const en fin de déclaration de méthode disait qu'aucun argument n'allait être modifié et en fait ca joue seulement sur les attributs de la classe.

Merci de ton aide
06/01/2008, 12h04
yan

Citation:

Envoyé par allserv

Ah d'accord, je viens de mettre const à ma fonction recurisve et du coup je n'ai plus cette erreur.
En fait je pensais que le mot clé const en fin de déclaration de méthode disait qu'aucun argument n'allait être modifié et en fait ca joue seulement sur les attributs de la classe.

Merci de ton aide

A ce que j'ai compris oui. Et ca t'empêche aussi d'appeler des fonctions non const de ta class.
Je t'avoue que je ne suis pas encore à l'aise avec les const non plus. Mais ça permet de bien structurer tes class.
08/01/2008, 04h51
koala01
Salut,

Les trois possibilités d'usage du mot clé const sont:
- Code:
  
  const type LaClasse::laFonction()
  
  Tu t'engage à ne pas essayer de modifier l'élément renvoyé par cette fonction (parce que c'est un pointeur, par exemple)
- Code:
  
  type LaClasse::laFonction(const typearg argument)
  
  tu t'engage à ne pas modifier l'argument fournit, si c'est une référence, tu évite également la recopie ;)
- Code:
  
  type LaClasse::laFonction() const
  
  tu t'engage à ce que la fonction ne modifie rien: ni les éventuels arguments fournits, ni les membres de la classe...
  Cela implique que tu dois utiliser des const_iterator pour accéder aux conteneurs, et que tu ne peux pas appeler d'autres méthodes non const
  Par contre, rien ne t'empeche de créer des variables temporaires que tu peux tenter de modifier... quant à voir si c'est opportun...
Ensuite, viennent les variantes tirées de ces trois possibilités ;)
08/01/2008, 10h31
yan
merci :king:
par contre
Citation:
Envoyé par koala01

Salut,

Code:

type LaClasse::laFonction() const

tu t'engage à ce que la fonction ne modifie rien: ni les éventuels arguments fournits, ni les membres de la classe...
Cela implique que tu dois utiliser des const_iterator pour accéder aux conteneurs, et que tu ne peux pas appeler d'autres méthodes non const
Par contre, rien ne t'empeche de créer des variables temporaires que tu peux tenter de modifier... quant à voir si c'est opportun...
tu es sur ??
08/01/2008, 10h51
Biozic

Citation:

ni les éventuels arguments fournits

Non, du moment que ces arguments ne sont pas const, on peut toujours les modifier.
08/01/2008, 12h13
JolyLoic

Une façon de voir les choses qui peut aider à s'en souvenir (ou pas, ça dépend des gens), c'est de dire que dans une fonction membre non const d'une classe A, this est de type A*, alors que dans une fonction const, this est de type A const *.
08/01/2008, 12h21
yan

Petite question,
A const * , const A * c'est bien la même chose?? ou la position de const modifie sa signification?
08/01/2008, 12h53
JolyLoic

Vi, A const * et const A * sont équivalents. Ils sont différents de A* const.

La règle veut que const s'applique à l'élément placé juste devant, sauf s'il est au début, auquel cas il s'applique à l'élément placé après. Je préfère me mettre dans le cas de la règle générale que dans l'exception, et donc écrire A const *.
08/01/2008, 12h53
Médinoc

Là, c'est la même chose.
C'est A * const qui est différent.

Et quand on combine les deux, const A * const et A const * const reviennent au même.
08/01/2008, 12h58
yan

Citation:

Envoyé par Médinoc

Là, c'est la même chose.
C'est A * const qui est différent.

Et quand on combine les deux, const A * const et A const * const reviennent au même.

ok merci.
C'est quoi la différence?
08/01/2008, 13h04
koala01

Citation:

Envoyé par Biozic

Non, du moment que ces arguments ne sont pas const, on peut toujours les modifier.

Mais d'un autre coté, cela me choque énormément qu'une méthode déclarée constante se mette à modifier des valeurs... fussent celle d'arguments non const passés en paramètre...

De là à dire que je préférerais ne fournir que des paramètres constants à une méthode constante, il n'y a qu'un pas ;)

Je suis peut etre un peu obtu sur ce coup là, mais, selon moi, une méthode constante sert à obtenir un acces en "lecture seule", et il n'y a donc, a priori (mais bon, on peut en débattre, n'est-ce pas :question:), aucune raison qu'elle n'aille modifier quoi que ce soit de manière permanente (ce qui est un risque majeur si tu fournis des paramètres non constants... principalement s'il s'agit de pointeurs ou de références :P) ;)
08/01/2008, 13h08
Jack_serious
Citation:
Envoyé par koala01

Code:

type LaClasse::laFonction() const

tu t'engage à ce que la fonction ne modifie rien: ni les éventuels arguments fournits, ni les membres de la classe...
Cela implique que tu dois utiliser des const_iterator pour accéder aux conteneurs, et que tu ne peux pas appeler d'autres méthodes non const
Par contre, rien ne t'empeche de créer des variables temporaires que tu peux tenter de modifier... quant à voir si c'est opportun...
Il y a quand meme une exception.

Les donnees membres d'une classe declarees comme mutable peuvent etre modifiees dans des methodes declarees const.

Cette possibilite n'est toutefois qu'a utiliser que dans des cas tres precis et justifies.
L'exemple le plus courant est un compteur d'acces que l'on veut pouvoir incrementer lors de l'acces a des methodes de type Get().
08/01/2008, 13h19
JolyLoic

Citation:

Envoyé par Jack_serious

L'exemple le plus courant est un compteur d'acces que l'on veut pouvoir incrementer lors de l'acces a des methodes de type Get().

Plus encore qu'un compteur d'accès, qui est souvent plus une technique de débug que de vrai code, implémenter un cache servant à précalculer un résultat long est typique de l'utilisation de mutable.
08/01/2008, 13h24
Jack_serious

Citation:

Envoyé par JolyLoic

Plus encore qu'un compteur d'accès, qui est souvent plus une technique de débug que de vrai code, implémenter un cache servant à précalculer un résultat long est typique de l'utilisation de mutable.

La ca m'interesse. Tu pourrais detailler et donner un exemple s'il te plait ?
08/01/2008, 13h24
JolyLoic
Citation:

Envoyé par koala01

Mais d'un autre coté, cela me choque énormément qu'une méthode déclarée constante se mette à modifier des valeurs... fussent celle d'arguments non const passés en paramètre...

Il y a des cas...
Code:

1 2 3 4 5 class Note { public: bool estDansLeTop10(vector<int> autresNotes) const; };
Pour calculer le top10, il va falloir trier le tableau, donc le modifier. Il n'empêche que ça ne modifie en rien la note testée...
L'alternative est de passer le tableau par référence constante, et de créer une copie locale du tableau que l'on triera, mais bon, c'est plus lourd d'écriture.

Un autre cas, bien plus courant :

Code:

void Affiche(std::ostream &) const;

Heureusement que j'ai le droit de modifier mon stream...

Citation:

Envoyé par Jack_serious

La ca m'interesse. Tu pourrais detailler et donner un exemple s'il te plait ?

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
class Eleve
{
public:
  double moyenne() const;
private:
  double calculerMoyenne() const;
  mutable bool maMoyenneEstAJour;
  mutable double maMoyenne;
  vector<double> mesNotes;
};
 
double Eleve::moyenne() const
{
  if (!maMoyenneEstAJour)
  {
    maMoyenne = calculerMoyenne();
    maMoyenneEstAJour = true;
  }
  return maMoyenne;
}

08/01/2008, 13h31
koala01

Oui, mais, dans ce cas là, est ce que la création du cache sera dévolue à une méthode constante :question:

Selon toute vraissemblance, il y aurait, à mon sens, deux classes entrant en jeu, chacune ayant sa propre responsabilité:
une classe "cache" avec une méthode (non constante) "create", recevant éventuellement (car elle peut etre un membre de la classe;)) la liste des éléments à utiliser pour créer le cache, et une autre "élément" qui aura un (ou plusieurs) accesseur(s) cohérent(s) avec les informations nécessaires pour la création du cache, qui sera (seront) une (des) méthode(s) constante(s)...

La méthode "create" de "cache" se chargeant d'appeler l' (les)accesseur(s) (constant(s)) de "element" pour chacun des éléments à utiliser pour créer le cache, non :question:
08/01/2008, 13h41
koala01

Pour la gesion de flux, je l'accorde, je l'avais completement oublié :aie:... pour l'exemple de la fonction estDansleTopDix(), selon moi, il y aurait lieu de correctement séparer les responsabilités:
le gestionnaire de note d'une part (celui qui dispose du tableau de note) s'occupe du tri des notes, vraissemblablement lors de chaque ajout, d'ailleurs (histoirre de garder le tableau trié en permanence... maintenant, il faut peut etre voir s'il n'est pas plus opportun de le faire une fois de temps en temps: avant une recherche par résultat ;)) et la fonction estDansLeTopDix d'autre part se contenant de... rechercher dans le tableau qui sera alors passé... en tant que paramètre constant ;)
08/01/2008, 13h44
Jack_serious

Je suis d'accord.

Je vois bien le principe, mais j'aurais plutot tendance a deleguer le calcul de la moyenne a une methode/classe dediee pour ca, qui mettrait a jour le cache...
08/01/2008, 15h22
JolyLoic

Je ne vois pas forcément l'intérêt de créer une classe séparée simplement pour gérer le cache d'une valeur (ou à la limite, simplement associer le booléen de test et la valeur, dans ce cas, j'utiliserais probablement boost::optional). Mais si je le faisais, l'instance de cette classe cachant la valeur serait une donnée membre de ma classe, et il faudrait soit qu'elle soit mutable, soit qu'elle même possède des données membre mutable.
08/01/2008, 15h34
koala01
En fait, mon idée personnelle est même que l'éleve n'a normalement aucun besoin ni aucun droit de disposer de ses notes, et que donc, les notes devraient être gérées par "quelque chose d'autre".

C'est ce "quelque chose d'autre" qui se charge de maintenir la liste des notes (en mettant chaque note en relation avec l'élève qui l'a obtenue), de calculer les moyennes et de fournir la place que cette moyenne vaut au sein du groupe concerné.

L'élève peut s'adresser à ce "quelque chose d'autre" pour disposer d'une note particulière, de sa moyenne ou de sa position dans le groupe, mais en lecture seule, quoi qu'il arrive...

Ainsi, la méthode estDansLeTopDix serait sans doute implémentée sous la forme de
Code:

1 2 3 4 bool Eleve::estDansLeTopDix() const { return gestionnaire->Position(monid)<=10; }
et toutes les autres méthodes de Eleves permettant d'obtenir des informations sur ses notes seraient dans la même veine :P
08/01/2008, 15h47
Biozic

Citation:

Envoyé par koala01

L'élève peut s'adresser à ce "quelque chose d'autre" pour disposer d'une note particulière, de sa moyenne ou de sa position dans le groupe, mais en lecture seule, quoi qu'il arrive...

OK, mais pour avoir accès à la moyenne dans un système en lecture seule, tu es obligé de la recalculer à chaque accès. Pour garder la valeur de la moyenne en cache, tu es obligé d'avoir un champ non constant, c'est-à-dire mutable s'il doit être appelé à partir d'une méthode constante, que ce soit une méthode de la classe qui gère le cache ou une d'une classe qui la contient.
08/01/2008, 15h57
Jack_serious

Citation:

Envoyé par Biozic

OK, mais pour avoir accès à la moyenne dans un système en lecture seule, tu es obligé de la recalculer à chaque accès. Pour garder la valeur de la moyenne en cache, tu es obligé d'avoir un champ non constant, c'est-à-dire mutable s'il doit être appelé à partir d'une méthode constante, que ce soit une méthode de la classe qui gère le cache ou une d'une classe qui la contient.

La methode qui regenere le cache et recalcule les moyennes n'est pas constante dans ce cas.
Par contre les methodes pour acceder au moyennes le sont.

L'inconvenient c'est qu'il faut appeler la methode qui regenere le cache a la main...
08/01/2008, 16h14
koala01

Mais le cache ne doit être régénéré que quand on fournit une nouvelle note au système, et cela peut donc pleinement rentrer dans une méthode "AddNote(ideleve,idexam,resultat)", qui n'est pas constante... mais qui n'est accessible que par les profs ;)

En fait, et pour etre préci, je verrais bien des classes prenant la forme de

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
 
class GestionnaireVuParEleve
{
    public:
       GestionnaireVuParEleve();
       ~GestionnaireVuParEleve();
        size_t position(const IdEleve &) const;
        double moyenne(const IdEleve &) const;
        double resultat(const IdEleve &, const IdExam&) const;
    protected:
        /* toutes les données en cache, protected pour qu'elle soient
         * accessible par les méthodes de GestionnaireVuParProf
         */
};
class GestionnaireVuParProf: public GestionnaireVuParEleve
{
    public:
       GestionnaireVuParProf();
       ~GestionnaireVuParProf();
       void AddResultat(IdEleve &, const IdExamen&, const double resultat);
};
class Eleve
{
    public:
        Eleve(GestionnaireVuParEleve*, const IdExamen&);
        ~Eleve();
        /* méthodes (exclusivement constantes) d'interrogation 
         * sur le résultat de l'éleve concerné
         * + 1 méthode non constante pour indiquer qu'il a présenté un examen
         */
    private:
        GestionnaireVuParEleve gestionnaire;
        std::list<IdExamen> presente;
        IdEleve id; 
};
class Prof
{
    public:
        Prof(GestionnaireVuParProf*);
        ~Prof();
    private:
        GestionnaireVuParProf* gestionnaire;
};

où IdEleve et IdExamen sont les structures les plus adéquate pour représenter respectivement l'éleve et l'examen de manière unique, et où il n'est pas impossible d'envisager une classe mere commune entre Eleve et Prof (une classe Personne :question:)

Et, en y réfléchissant bien, GestionnaireVuParProf n'hériterait meme pas de GestionnaireVuParEleve, mais serait une composition avec déclaration d'amitié, les comportements de gestion du cache pourraient etre (en privé ou en protégé) dans GestionnaireVuParEleve et appelés uniquement par la méthode d'ajout de résultat (ou les besoins de récupération de résultats persistants après redémarrage du système:))

Ce qui donnerait les deux classes sous la forme de
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 class GestionnaireVuParEleve { friend class GestionnaireVuParProf; public: GestionnaireVuParEleve(); ~GestionnaireVuParEleve(); size_t position(const IdEleve &) const; double moyenne(const IdEleve &) const; double resultat(const IdEleve &, const IdExam&) const; private: /* toutes les données en cache */ void readFile(); void addres(IdEleve &, const IdExamen&, const double resultat); }; class GestionnaireVuParProf { public: GestionnaireVuParProf(GestionnaireVuParEleve*); ~GestionnaireVuParProf(); void AddResultat(IdEleve &, const IdExamen&, const double resultat); private: GestionnaireVuParEleve* gestionnaire; };
Avec de forte présomptions sur le fait que GestionnaireVuParEleve et GestionnaireVuParProf finissent sous la forme de singletons :P, ou du moins, en membre static des classes dans lesquelles ils apparaissent

08/01/2008, 20h02
JolyLoic

Citation:

Envoyé par koala01

Mais le cache ne doit être régénéré que quand on fournit une nouvelle note au système, et cela peut donc pleinement rentrer dans une méthode "AddNote(ideleve,idexam,resultat)", qui n'est pas constante... mais qui n'est accessible que par les profs ;)

L'idée est de ne pas régénérer le cache à chaque ajout, mais uniquement à la demande. Parce qu'on va peut-être faire 50 ajouts avant de faire une demande, voire on ne va jamais demander. Si jamais on demande un jour. Or la demande est naturellement une opération constante, et elle va modifier l'état du cache. L'alternative consiste plutôt à mon avis à demander à l'utilisateur de la classe de gérer lui même l'état du cache, avec les risques que ça implique.
08/01/2008, 21h41
koala01
Je crois au contraire que tu risque, dans le cadre d'une gestion de notes d'étudiants, d'avoir plus de recherches que d'ajouts (un ajout par éleve et par examen, contre combien de recherches possible :question:)

Et l'on pourrait meme alors déléguer la décision de recréer le cache apres la dernière introduction.
qui s'intégrerait en définitive la forme de
Code:

1 2 3 4 5 6 7 while( ajouter) { /* récupération des valeurs */ gestionnaire->addres(eleve,exam,resultat); } gestionnaire->UpdateCache();
(mais dans la méthode permettant au prof d'ajouter ses notes ;))

De telle manière, la création du cache se fait de manière régulière, tout en ne monopolysant pas des ressources inutiles, alors que c'est pour le refaire tout de suite après ;)

En effet, il faut garder en tete que, si l'éleve dispose de la moindre possiblité de modifier ses cote, il risque fort de le faire, ce qui n'est acceptable dans aucun cas.
08/01/2008, 22h32
JolyLoic

Citation:

Envoyé par koala01

Je crois au contraire que tu risque, dans le cadre d'une gestion de notes d'étudiants, d'avoir plus de recherches que d'ajouts (un ajout par éleve et par examen, contre combien de recherches possible :question:)

Possible. Dans mon cas, pour n ajouts puis m recherches, il y a 1 calcul seulement. Dans le cas où tu calcules à chaque ajout, il y en a n.

Citation:

Envoyé par koala01

Et l'on pourrait meme alors déléguer la décision de recréer le cache apres la dernière introduction.

C'est ce que j'appelais la méthode manuelle. Elle peut être risquée.

Citation:

Envoyé par koala01

De telle manière, la création du cache se fait de manière régulière, tout en ne monopolysant pas des ressources inutiles, alors que c'est pour le refaire tout de suite après ;)

Je ne sais pas trop ce que tu entends par régulier ou monopolisation de ressources. La solution à base de recalcule à le demande impose un overhead d'un bool et d'un test par rapport à la solution manuelle, mais on gagne en échange une plus grande clarté du code, et moins de risques de bug.

Citation:

Envoyé par koala01

En effet, il faut garder en tete que, si l'éleve dispose de la moindre possiblité de modifier ses cote, il risque fort de le faire, ce qui n'est acceptable dans aucun cas.

Peut-être, mais je la discussion ne portait pas pour moi sur ce point (et si tel était le cas, qui associe la classe élève avec du code que pourrait appeler élève physique ??), mais sur un cas typique d'utilisation de mutable pour implémenter un cache automatiquement mis à jour.

Fuseau horaire GMT +2. Il est actuellement 11h39.