Informations générales

Voici le corrigé (en pièce jointe) et les principales remarques de l'examen :

Q1

1.1.
  Il était explicitement demandé de justifier chaque réponse, cochée ou non :
  pourquoi ne pas le faire ?

  Beaucoup pensent qu'un seul constructeur existe pour Ville alors
  qu'il y a au moins 2.

  Si on n'appelle pas le constructeur, il n'est pas nécessaire d'avoir sa
  définition (pas recherché lors de l'édition de liens)

1.2
Bonne justification dans l'ensemble ; quelques fois oubli de
mentionner la vraie raisons d'être : les AUTRES fichier C++ (sinon :
pourquoi séparer en deux ??)

1.3
- parfois non répondue ; par « peur » de la notion ? ou par manque de temps ?
- attribut size souvent non géré / mal compris (certainement lié au point suivant)
- confusion array/vector (size() mal utilisée et push_back() / pop_back() )
- beaucoup oublient le const de empty()
- trop hard-codent la valeur 32 dans push()
- grande variabilité dans la gestion de l'erreur dans pop() :
  les exceptions sont mal comprises par plusieur(e)s

1.4
Bonne compréhension dans l'ensemble mais cependant (c) et (d)
nettement moins réussies

1.5
Presque tout le monde cite (correctement) l'édition mais de liens,
mais mauvaise compréhension de la raison de l'erreur :
presque tout le monde mentionne les includes (pourquoi ??).

----------------------------------------------------------------------

Q2
Il y a un clair contraste entre les étudiant(e)s « moyen(ne)s »
 et « ayant vraiment compris ».

La conception est globalement assez réussie, notamment:

* l'héritage depuis les classes Personne ou Véhicule, ainsi que
  constructeurs hérités

* droits d'accès honorés (malgré quelques getter qui return un
  pointeur ou référence non-const.. !! cf aussi le projet !)

* overloading operator << est majoritairement présent (mais pas
  toujours pour classe Personne, faute de lecture d'énoncé ?), et
  fonction affiche() très majoritairement noté virtual (mais sans
  affichage polymorphique derrière...)

* notion de véhicule qui a deux pointeurs, vers chauffeur et vers proprio

* getters et affiche majoritairement notés const

Cependant :

* quasiment personne ne fait correctement l'affiche polymorphique

* très peu pensent à faire une classe Named_entity (et donc,
  duplication de code !)

* pratiquement pas de prédéclaration (dépendance circulaire)

* il n'y a que quelques copies qui réfléchissent « vraiment » à ce que
  se passe lors de l'achat (checks, changer proprio, supprimer
  véhicule de ancien proprio)

* lorsqu'un pointeur est passé en argument, le cas nullptr est rarement vérifié

* quelques copies font l'erreur d'avoir un argument const sur lequel
  une fonction non-const est appellée (ou autres problèmes du type)

* quelques copies utilisent des string au lieu de Personne*, puis,
  lorsque ça a été abordé, comparent les noms au lieu des adresses
  (c'est bien sûr faux)

* Parfois les prototypes des méthodes de personnes ont un argument
  const& : il faut vérifier que cela ne pose pas de problème dans la
  définition de ces méthodes

* autres problèmes de conception : Voiture sans passagers, oubli des
  méthodes afficher() ou vendre(), fonctions acheter(), vendre() ou
  conduire() sans arguments, (plus rare) changement d'une copie locale
  au lieu d'une référence

----------------------------------------------------------------------
Q3
Très peu relèvent l'erreur de l'éditeur des liens, et la segfault à l'exécution.

Des non-erreurs indiquées comme erreur font perdre beaucoup de points à certain(e)s.

L'erreur « section deux points » est généralement trouvée mais mal justifiée.

Très peu ont trouvé l'erreur de la ligne 34.


----------------------------------------------------------------------
Q4

Un certain nombre ont purement et simplement oublié les destructeurs
(pas compris que les accollades symbolisent une fin de portée ?)

D'autres les ont mis dans un ordre un peu aléatoire.

Enfin, j'ai trouvé régulièrement des élèves qui imaginaient que la prise d'une référence (e.g., Livre& livre(livre_signe);) utilisait le constructeur de copie.

Aussi, très peu ont correctement construit le livre 3 (souvent, oubli
d'appeler le constructeur de copie, voire ne construisent pas du tout
le livre).

Enfin, plusieurs d'étudiant(e)s ont encore du mal avec le
polymorphisme (dans la partie affichage de la partie 2).

Et les principales remarques sur l'examen :

c'est un projet globalement très très bien réussi (et apparemment bien compris sur le fond).

Bravo pour vos efforts !

Les notions de OOP ont été bien comprises, sauf, par beaucoup, la notion de fuite d'encapsulation via
des getter de pointeurs (ou de collection de pointeurs) ou de référence non constante.
Aussi trop de get/set abusifs : réflexe de définir des get & set pour
 tous les attributs privés, sans trop réfléchir à leur nécessité (en
  particulier pour les set). Il faudra que j'insiste plus là dessus dans la PREMIERE (!)
  leçon de POO l'an prochain ;-)

La gestion de mémoire est aussi souvent hasardeuse et la conception de
base de l'utilisation des pointeurs (« les trois cas d'utilisation »)
encore mal comprise en pratique.  Aussi beaucoup de fuite de mémoire.
Exemple :
  Tissu qui n'est pas responsable des Masses et main() passe des
  pointeurs en arguments (OK, pourquoi pas...), mais TissusRectangle qui
  fait des new sans delete lors de la destruction !!

Au niveau modularisation, beaucoup ont aussi simplement copié collé
leurs fichiers .cc et .h pour faire le graphisme séparément (ce qui n'est
pas la bonne façon de faire). Et plusieurs n'ont pas modularisé mais tout
mis ensemble sur P12 à P14.

De nombreux codes sont bien commentés, mais pas toujours bien hiérarchisés, avec
quelques fois une prise en main laborieuse du projet.