Discussion :

[zora700]

svp j'ai besoin de votre aide je dois calculer les moyennes par matière et les moyennes par étudiant dans la classe Feuille

Code :

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

1
2
3
4
5
6
7
8
9
10
11
#include "Cellule.h"
#include "Ligne.h"
class Feuille : public map<string,Ligne>{
 
    public:
      Feuille(std::vector <std::string> & e, std::vector <std::string> & m );
 
      Feuille();
 
      float MoyenneMatiere(string mat);
      float MoyenneEtudiant(string etudiant);

et ma classe ligne c'est bien:

Code :

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

1
2
3
4
5
6
7
8
9
#include "Cellule.h"
 
class Ligne : public map<string,Cellule>{
      public:
 
      Ligne();
      Ligne (std::vector <std::string> & m );
 
           };

la classe Cellule contient la note et la presence
j'ai définit ma fonction comme suit mais ça marche pas:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
float Feuille :: MoyenneEtudiant(string etudiant)
{
      Feuille :: iterator it;
      Ligne :: iterator it2;
      int nb=0;
      double s=0;
 
      for(it=begin(); it!=end();it++){
                      it=find(etudiant);
                      if(it!=end()){
                                    for(it2=begin();it2 != end(); it2++)
                                    {
                                                        s=s+it2->second.SetValeur(double);
                                                        nb++;
                                                        return 0;}
                                                        }
                                                        }}

si vous avez une idée merci de me guider

[Ekleog]

C'est un prof qui a cité developpez.net et qui fournit du code horrible pour un devoir, ou quoi ?

Sinon, je conseillerais la fonction rechercher pour voir tout ce que nous avons déjà expliqué à tes camarades ...

[3DArchi]

si vous avez une idée merci de me guider

Ne pas hériter de std::map. utiliser const dans tes passages de paramètres.
Et poser l'algorithme sur papier et l'essayer à la main avant de l'implémenter.

[themadmax]

Ne pas hériter de std::map.

Pour quelle raison conseille tu cela ?

[Ekleog]

std::map a une sémantique de valeur, l'héritage public a une sémantique d'entité.

cf. http://cpp.developpez.com/faq/cpp/?p...s#CLASS_valeur

[koala01]

Salut,

Pour quelle raison conseille tu cela ?

Il y a une raison "technique" et une raison "conceptuelle"...

La raison technique est que le destructeur des différents conteneurs de la STL n'est ni virtuel, ni protégé, condition indispensable à l'héritage.

En effet, avec l'héritage public, tu peux parfaitement avoir une classe prenant la forme de

Code :

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

1
2
3
4
5
6
7
8
9
10
class MyClass : public std::map<std::string, Type>
{
    public:
        ~MyClass()
        {
            /* appels à delete ??? */
        }
    private:
        /* une foule de membres différents (gestion de mémoire dynamique ? ) */
};

dont tu te rends compte qu'il faut impérativement invoquer le destructeur une fois que l'objet n'est plus nécessaire (pour éviter les fuites mémoires)

Mais, cette classe héritant de std::map<std::string, Type>, tu serait parfaitement en droit d'écrire un code proche de

Code :

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

1
2
3
4
5
6
int main()
{
    std::string<std::string, Type> * ptr = new MyClass;
    /* utilisation de ptr, en n'utilisant que l'interface de std::string<std::string, Type> */
    delete ptr;
}

et là, le destructeur de std::map n'étant pas virtuel, l'appel au destructeur de MyClass ne serait jamais appelé

Tu imagines aisément les problèmes que cela peut représenter au niveau de la mémoire, surtout si tu passes ton temps (contrairement à ce que montre le code) à créer et à détruitre des instances de MyClass

La raison conceptuelle est que l'héritage doit respecter LSP, et donc les pré / post conditions et les invariants.

Nous rejoignons en cela des problèmes du meme type que ceux qui font que, malgré ce que l'on apprend en math (un carré EST-UN rectangle particulier en cela que tous ses cotés sont égaux), la classe Carre ne peut pas hériter de la classe Rectangle, ou de ceux qui font que ListeTriee ne peut pas hériter de Liste :

Dans le cas d'un tel héritage, si tu respectes les invariants de la classe de base, tu ne respectes pas ceux de la classe dérivée, et inversement

De plus, on nous répète à satiété que l'héritage (public) est une relation EST-UN, et c'est tout à fait vrai.

Par contre, il faut grandement se méfier de notre manière de parler, car c'est phrase n'a de sens que dans une optique de substituabilité : Un objet de la classe X EST-UN objet de type Y si (et seulement si) je peux passer en paramètre un objet de la classe X à une fonction attendant un objet de type Y et que la fonction continue à fonctionner correctement et à fournir un résultat exploitable cohérent

Il faut donc se méfier tout particulièrement de notre manière de parler, car quand on dit "MyClass EST-UNE std::map" on pense en réalité "MyClass EST implémentée pour utiliser une std::map", ou si tu préfères "MyClass UTILISE std::map pour rendre les services que l'on attend d'elle "

Et nous nous rendons alors compte que nous ne sommes plus dans un contexte d'héritage, mais bien dans un contexte de composition

En outre, ce n'est pas parce que l'on veut disposer de deux ou trois fonctions issues de la classe std::map que toutes les fonctions vont nous intéresser, ni meme avoir le moindre sens pour MyClass:

Tu vas, très certainement être intéressé par la fonction insert, mais au niveau de MyClass, elle serait bien mieux nommée sous la forme de "addResult" (par exemple).

On peut de même envisager le fait que tu seras sans doute intéressé par les fonctions begin et end, mais, outre le fait que tu ne seras intéressé que par leurs versions constantes (une fois un résultat inséré, il n'est théoriquement plus question de le modifier ), elles seraient largement mieux nommées sous les formes respectives de "resultBegin" et "resultEnd" (par exemple).

Enfin, toutes les fonctions de suppression d'élément (clear, remove, ...) n'ont aucun sens pour MyClass car cela permettrait de supprimer des résultats afin de... de quoi, en sommes de "tricher" sur les résultats afin de favoriser (ou pire, de bloquer) un étudiant

On se rend donc compte que, malgré le fait que notre (mauvais) parlé nous incite à envisager l'héritage, LSP ne nous permet pas de l'utiliser parce que n'importe quelle fonction prenant une std::map<std::string, Type> en argument peut avoir des résultat désastreux sur la cohérence d'un objet de type (réel) MyClass