CS-112(g): Notes série notée

Bonjour,

Je viens de mettre dans Moodle les notes de la série notée et voici les commentaires généraux sur les résultats (corrigés attachés en pièce jointe tout en bas, pour questions si jamais) et je vais vous envoyer sous peu par email vos résultats et commentaires personnels.

MERCI DE LIRE ATTENTIVEMENT le corrigé et le présent message avant de poser d'autres questions.

Concernant les notes mises dans Moodle (onglet Notes) :

les notes publiées correspondent à la fraction que vous avez obtenue, multipliée par 100 : par exemple pour cette série notée, cela correspond à
100 * votre total de points / 95
car l'épreuve est notée sur 95 points ;
la note « Total du cours » est calculée automatiquement par Moodle et correspond à la fraction moyenne à ce stade, laquelle est arrondie pour calculer la note « Note » ;
la note « Note » correspond à la note arrondie, sur l'échelle habituelle 1-6, avec un arrondi vers le haut (c.-à-d. : > 50% = 3.75, > 55% = 4, > 60% = 4.25, etc.), que vous auriez si on arrêtait là.
Je la remettrai à jour à la fin du semestre, après l'examen.

Tout ceci a été expliqué en détail dans le premier cours.

L'histogramme ci-dessous (en fin de message) représente la répartition des points à cette série notée. Le min est de 16.5 et le max de 95.25 ; la moyenne de 69 (note équiv. : 4.75) et la médiane à 72.25. Le taux de réussite est de 87.2%.

C'est donc une série globalement bien réussie. Bravo pour votre travail !

Voici néanmoins ci-dessous les principale remarques globales, afin de vous corriger/vous améliorer dans votre future vie de programmeur/programmeuse. Voyez aussi les éventuelles remarques de vos correcteurs dans votre rendu personnel (que je vais vous envoyer).

Redondance des attributs privés (plus que 2 Complexes), donc pas encore bien intégré la différence entre interface et implémentation
aussi on trouve trop de getters, setters et des constructeurs qui exposent complètement l'implémentation de la classe, donc, même si la grande majorité sait comment écrire de la POO, trop n'ont pas encore *vraiment* internalisé ce qu'est l'encapsulation.
Dans certaines copies ayant utilisé des vector pour attributs, on accédait aux éléments du vector encore non initialisés.
utilisation d'un typedef à la place d'une classe.
Pas de constructeur par défaut (ce qui, surtout pour un groupe (mathématique), semble assez naturel).
Pas de gestion/vérification du déterminant dans le constructeur
quelques confussions de type entre vector et array
Les questions 1.2 - 1.5 (incluses) se sont globalement très bien passées ; quelques remarques cependant ci-dessous.
extraction directe d'attributs (impossible lorsque surcharge externe) au lieu d'utiliser des getter
quelques surcharges externes déclarées const et quelques surcharges internes non déclarées const (on parle ici du + , pas du +=)
Dans plusieurs copies, != n'était pas redéfini avec ==
toujours du mal à utiliser directement les booléens :
```
  if (condition) {

      return true;

   } else {

      return false;

   }
```
au lieu de simplement : return condition;
la question 1.5, si répondue, est en général bien réussie ; quelques personnes n'implémentent pas la bonne opération

Et pour l'exercice 2 :

Cet exercice a été plutôt bien réussi en général. Les notions de classes, inheritance, construction et même polymorphisme sont souvent bien acquises.
Cependant, beaucoup trop de « test de type » indirect comme ajouter un attribut std::string Catégorie ou JobName pour pouvoir moduler l'affichage dans la méthode affiche() ou le destructeur, bien que les mêmes utilisent le polymorphisme pour spécialiser le calcul du taux ou les lignes d'affichage supplémentaires.
Souvent ils/elles oubliaient les const pour les fonctions affiche() et revenu() ou ils/elles oubliaient de les noter dans les classes à la question 2.1.
aussi pas mal de confusion sur les destructeurs (ne pas le mettre dans Employé, oublier le virtuel, et très souvent ils ne comprennent pas la différence entre celui d'Employé et ceux des sous-classes).
aussi très souvent oublié la valeur par défaut dans le constructeur.
Et quand elle est mise c'est rarement au bon endroit (i.e. dans le prototype, comme dernier argument)
Certains y pensent dans la super-classe mais pas dans les sous-classes (pensent-ils/elles que c'est « hérité » ??)
Souvent ils/elles ne mettaient pas l'initialisation de "taux" dans la liste du constructeur et la faisait que dans le corps du constructeur.
Les autres constructeurs étaient majoritairement corrects.
La faute qui revenait souvent pour le calcul du salaire était l'oubli de la division par 100 pour le taux.

syntaxe: des virtual et override dans les définitions hors classe

Pour les pointeurs, ils

s'en sont assez bien sortis, la classe Entreprise était en général correct dans sa conception, mais c'est plutôt lors de l'implémentation dans le main() que ça posait problème. La plupart avait de la peine a créer le pointeur qui entrerait dans la collection de la classe (oubli du & ou du new).

Ou alors des copies de unique_ptr.

Ou des delete sur des objets alloués statiquement.

Et très peu pensent à gérer la mémoire.

Finalement pour l'affichage, très souvent celui de la classe Employé est oublié ce qui entraîne pas mal de duplication de code.
De plus, on a aussi vu de la confusion sur le polymorphisme et l'usage du *this.

Histogramme des points :
pic autour de 80 points

SNPrintemps2022-corrige.pdf