Bonjour,
Je voudrais poser quelques questions concernant l'évaluation du code source, pour mieux comprendre les libertés et les contraintes imposées.
- Par rapport à l'architecture du projet, est-ce qu'on est libre de créer des modules supplémentaires, par exemple un module pour la validation des différents aspects de la ville, si on respecte l'architecture (et l'hiérarchie) de base (ville, tools, noeud) imposé par les spécifications du projet? Cela permettrait de diviser de grands modules en plusieurs fichiers, favorisant une plus grande modularisation du programme.
- "Le module error est fourni dans un fichier archive sur moodle ; il ne doit pas être modifié [...] Il n’est pas autorisé de modifier le code source de ce module car il sera utilisé par notre programme de notation automatique du rendu1" – (source)
Est-ce que cela entend que le module error ne doit en aucun cas être modifié (les fichiers error.cc et error.h doivent se retrouver dans le code source comme ils sont fournis), ou que seulement les strings retournés par les fonctions ont une importance et doivent être conservés, car elles sont utilisées lors de l'évaluation automatique du program? Autrement dit, est-ce qu'on peut augmenter le module avec nos propres erreurs/logique, si on respecte les erreurs de base qu'il faudra retourner lors de la lecture du fichier? - Selon ce post, il ne peut y avoir qu'une seule erreur par fichier de test. Cépendent, dans le fichier test e04.txt (fourni par Moodle), il se trouve deux erreurs différentes, un lien en double pour (14, 24), mais aussi une violation du nombre maximum de liens d'un noeud logement. Un autre cas de bord que j'ai trouvé est dans e10.txt. Le nœud #24 dépasse la capacité maximale (1000001), mais en conséquence, entre également en collision avec le nœud #366 à cause de son rayon disproportionné. Pourriez-vous nous donner une indication de la façon dont nous devrions aborder ces conflits? Est-il sûr de ne pas tomber sur ce genre de conflits lors de l'évaluation?
- "On doit pouvoir produire l’exécutable projet à partir du Makefile après décompression du contenu du fichier zip. La commande make ne doit faire AUCUN déplacement de fichier ; tout reste dans l’unique répertoire créé par la décompression du fichier archive." – (source)
Dans notre cas, notre code source se trouve dans un sous-répertoire "src/" (par rapport au Makefile). Les étapes intermédiaires du Makefile (la compilation des modules) se font sous un dossier "obj/" et l'exécutable final sous "dist/". Ces sous-répertoires sont générés automatiquement par le Makefile (s'il y a besoin) avec mkdir, comme dépendances des fichiers intermédiaires.
Est-ce que cela posera problème pour l'évaluation? Il n'y a pas de déplacement de fichier, seulement une création de fichiers dans des sous-répertoires par g++ pour favoriser une meilleure organisation du code source.
Est-ce qu'il est nécessaire que tout se trouve dans un seul répertoire mélangé "plat"? Ou il suffit de construire l'exécutable exceptionnellement à côté du Makefile? - Certains noms de module sont proposés en anglais (tools, error, gui) et d'autres en français (ville, projet, constantes (mais les constantes elles-mêmes sont en anglais), noeud).
Si on respecte toujours l'architecture qui est imposée, est-ce qu'on a le droit de renommer ces fichiers en leurs équivalents en anglais ou en français pour rendre le projet un peu plus uniforme (i.e. town.cpp au lieu de ville.cc)? Et les noms des constantes?