• Décompressez l’archive fournie (par exemple, SampleSFML.zip dans l’exercice d’introduction) dans le répertoire de votre choix.
  • Attention : Le chemin qui mène à votre répertoire ne doit pas contenir de nom contenant le caractère espace ou bien un accent. Par exemple, sous Windows, C:\Users\Barnabé\Mes Documents\CPP est à bannir à cause du é dans Barnabé et de l’espace dans Mes Documents ; il vaut mieux que le chemin soit C:\CPP. Si vous ne respectez pas ce conseil, votre IDE risque de recompiler systématiquement l’ensemble de votre projet.
• Renommez le répertoire racine du répertoire que vous venez d’extraire (par exemple, SampleSFML)
• Dans le fichier nouveau_nom_du_répertoire_racine\CMakeLists.txt, au niveau de la ligne project(nom_projet VERSION 1.0.0 LANGUAGES CXX), remplacer nom_projet par un nom (sans espace) qui correspond à votre projet.
• Passez à la section de ce document correspondant à votre IDE/OS.

• Dans Clion, Menu File > Open et sélectionnez chemin_absolu_vers_votre_projet/CMakeLists.txt. Cliquez sur “OK” : Une fenêtre “Open Project” apparaît. CLiquez sur “Open as Project”
• Etape intermédiaire requise à partir de CLion 2022.1
  • Une fenêtre “Open Project Wizard” s’affiche. Notez que son champ Generator vous dit, par défaut, Use default Ninja
  • Ninja est un système de build, comme make
    • Si vous souhaitez l’installer, tapez sudo apt-get install -y ninja-build (cf. https://zoomadmin.com/HowToInstall/UbuntuPackage/ninja-build).
    • Si vous ne souhaitez pas l’installer, sélectionnez dans le champ Generator : Unix Makefiles ou Let CMake decide
  • Cliquez ensuite sur le bouton “OK”.
• Le chargement de votre projet devrait s’effectuer correctement dans CLion, sauf si c’est la première fois que vous effectuez cette opération dans le contexte de CSC4526 et que votre projet utilise la bibliothèque SFML. Dans ce cas, dans un terminal :

cd chemin_absolu_vers_votreRépertoireProjet
rm -Rf cmake-build-debug
mkdir build
cd build
cmake .. # N'oubliez pas le " .." après la commande cmake
#
# Si cmake affiche l'une des messages suivants:
#    - "cmake not found"
#    - "Error during cmake"
#    - "No CMAKE_CXX_COMPILER"
#    - "Could NOT find X11"
# Alors tapez les 2 commandes suivantes:
#
sudo apt -y install git cmake g++ libx11-dev libxrandr-dev libxi-dev libxcursor-dev libudev-dev mesa-common-dev libfreetype6-dev libopenal-dev libvorbis-dev libflac-dev
# Au final, vous devriez obntenir le message "-- Build files have been written to: absolute_path_to_your_project". Cela signifie que toutes les installations préalables pour Linux sont OK.
#
# Il vous reste à nettoyer votre répertoire de votre test cmake:
cd ..
rm -Rf build

• Si vous avez dû faire toutes ces manipulations dans un terminal, dans CLion, menu Build > Rebuild Project
• Menu Build > Build Project : Cette opération peut prendre un certain temps, notamment si votre projet utilise SFML et que donc CLion doit télécharger le projet SFML. Enfin, CLion affiche “Build finished” : tout s’est bien passé.
• Menu Run > Run ‘sample’ : la fenêtre de message affiche des informations de compilation (cette première compilation peut prendre du temps car CLion doit recompiler des ficheirs de bibliothèques). Notamment, dans le cas de l’exemple SampleSFML), une fenêtre “SFML works !” semblable à la fenêtre ci-dessous s’ouvre:
• Cliquez sur la croix à droite de cette fenêtre pour terminer votre programme.

• brew bundle dump pour créer un Brewfile des packages déjà installés.
• (facultatif) Désinstallez Homebrew
• Installez Homebrew pour ARM

cd /opt
sudo mkdir -p homebrew
sudo chown -R $(whoami) homebrew
curl -L https://github.com/Homebrew/brew/tarball/master |\
    tar xz --strip 1 -C homebrew
#+end_src
- Modifiez *PATH*
#+begin_src bash
PATH=/opt/homebrew/bin:$PATH

• Réinstallez les packages (en tout cas, ceux qui sont disponibles) avec le Brewfile

hash -d brew
brew bundle install --file /path/to/Brewfile

• Dans Clion, Menu File > Open et sélectionner chemin_absolu_vers_votre_projet/CMakeLists.txt. Cliquez sur “OK” : Une fenêtre “Open Project” apparaît. Cliquez sur “Open as Project” :
  • Etape intermédiaire requise à partir de CLion 2022.1
    • Une fenêtre “Open Project Wizard” s’affiche. Notez que son champ Generator vous dit, par défaut, Use default Ninja
    • Ninja est un système de build, comme make
      • Si vous souhaitez l’installer, tapez brew install ninja (cf. https://formulae.brew.sh/formula/ninja).
      • Si vous ne souhaitez pas l’installer, sélectionnez dans le champ Generator : Unix Makefiles ou Let CMake decide
    • Cliquez ensuite sur le bouton “OK”.
  • Le chargement de votre projet devrait maintenant s’effectuer correctement dans CLion. Si ce n’est pas le cas, c’est que vous êtes dans le contexte d’une première utilisation de cmake dans le contexte CSC4526 :
    • Dans un terminal, tapez la commande brew install sfml
    • Dans CLion, menu Build > Rebuild Project
• Pour exécuter une application :
  • Menu Run > Run ‘sample’ : la fenêtre de message affiche des informations de compilation (cette première compilation peut prendre du temps car CLion doit recompiler des fichiers de bibliothèques). Notamment, dans le cas de l’exemple SampleSFML), une fenêtre “SFML works !” semblable à la fenêtre ci-dessous s’ouvre:
  

• Dans Visual Studio, menu Fichier > Ouvrir > CMake… : une fenêtre “Ouvrir des projets CMake s’ouvre”

• Sélectionner le fichier CMakeLists.txt dans le répertoire de votre projet et cliquez sur “Ouvrir” : la fenêtre de sortie de Visual Studio que l’IDE travaille et vous affiche à la fin “Fin de la génération de CMake.”. NB :

  • Cette opération peut prendre un certain temps, notamment si votre projet utilise SFML et que donc Visual Studio doit télécharger le projet SFML
  • Si jamais cmake vous affiche – Configuring incomplete, errors occurred! et que, parmi les messages que cmake vous affiche, vous voyez error: could not find git for clone of sfml-populate ou bien qu’il y a eu des soucis avec un git clone, c’est que git n’est pas installé sur votre machine ou bien qu’il n’est pas assez récent.
    • Installez la dernière version https://gitforwindows.org/
    • Arrêtez et redémarrez Visual Studio
    • Recommencez cette procédure
  • cmake vous affiche éventuellement un warning concernant pugixml : ce warning est normal.

• Menu Générer > Tout générer

• Quand la génération est terminée, cliquez gauche sur la droite du bouton “Sélectionner un élément de démarrage” (2ème ligne de la barre de menu) et sélectionnez “sample.exe”, “mainLauncher.exe” ou “unitTests.exe”

• Cliquez sur ce bouton (ou Ctrl-F5) pour lancer l’application choisie : votre programme s’exécute. Notamment, dans le cas de l’exemple SampleSFML), la fenêtre suivante s’affiche pour vous signifier que SFML fonctionne.

  

• Cliquez sur la croix à droite de cette fenêtre pour terminer votre programme.

• Dans la “Console de débogage Microsoft Visual Studio”, appuyez sur une touche pour fermer cette console.

• Sous Visual Studio, dans l’explorateur de solutions, cliquez droit sur src, puis cliquez gauche sur Ajouter > Ajouter un nouvel élément… : une fenêtre “Ajouter un nouvel élément src” s’ouvre.
• Dans le cadre de gauche, sélectionnez “Visual C++”, puis le type de fichier que vous voulez créer. Enfin, cliquez sur le bouton “Ouvrir” : votre fichier est créé dans le répertoire src
• Indiquez son nom : Une fenêtre “Aperçu des changements - CMake” apparaît
• Cliquez sur le bouton “Annuler” (en effet, Visual Studio vous propose d’ajouter ce nouveau fichier à votre fichier CMakeLists.txt ; c’est inutile, car votre CMakeLists.txt prend en compte tout nouveau fichier grâce à sa ligne file(GLOB SOURCES CONFIGURE_DEPENDS *.h *.cpp)

• Une fois que SonarLint est installé dans votre IDE (VisualStudio ou CLion ; voir la procédure d’installation pour chacun de ces IDE), à chaque fois que vous ouvrirez ou sauvegarderez un fichier source, ce fichier sera analysé par SonarLint. Les problèmes détectés seront listés dans la fenêtre d’erreur de l’IDE, sous la forme de warnings.
• Si vous souhaitez désactivez certains warnings SonarLint (par exemple, le warning S106: Replace this usage of std::cout by a logger qui est trop complexe à résoudre pour nos applications “jouet”), cliquez droit sur la règle (dans la fenêtre d’erreur de VisualStudio ou pour CLion, dans la sous-fenêtre SonarLint) et sélectionnez “Disable SonarLint rule”.
• Si vous souhaitez réactiver une règle
  • Pour VisualStudio
    • Menu Outils > Options: Une fenêtre Options s’ouvre.
    • Dans le champ de recherche, tapez SonarLint: Un sous-menu SonarLint apparaît.
    • Sélectionnez Général et cliquez sur le bouton Edit rules settings: Un fichier settings.json s’ouvre dans l’explorateur de fichier.
    • Remplacez “Off” par “On” sur la règle que vous souhaitez réactiver et sauvegardez le fichier.
  • Pour CLion
    • Menu Window > Editor Tabs > Configure Editor Tabs: Une fenêtre Settings s’ouvre.
    • Cherchez SonarLint et sélectionnez celui qui est dans le sous-menu Tools.
    • Cliquez sur l’onglet Rules, puis C++. Cliquez sur le bouton Filter et sélectionnez Show only Changed.
    • Réactivez la règle souhaitée.

• Menu Build > Build Project : la fenêtre de sortie montre le travail de CLion, puis affiche “Build finished”
• Dans la 2ème ligne de menu, cliquez sur la flèche vers le bas à droite de la petite fenêtre contenant mainLauncher | Debug : une fenêtre avec de nombreuses configuration s’affiche.
• Sélectionnez unitTests : l’icône Google suivie de unitTest | Debug s’affiche désormais dans la petite fenêtre de la 2ème ligne de menu.
• clic sur le triangle vert à droite de cette petite fenêtre OU BIEN Menu Run > Run ‘unitTests’ : en bas de l’écran, le résultat du test est affiché avec une synthèse (que vous pouvez déplier) dans le cadre gauche.
• Si le test révèle une erreur, dans le cadre à droite, cliquez sur le lien bleu signalant la ligne en erreur : CLion ouvre le fichier unitTests.cpp au niveau du test unitaire en erreur.

• Visual Studio offre un “explorateur de tests” dont nous déconseillons l’usage pour l’instant. En effet, si, après avoir fait une séance de tests, vous modifiez le nom/sous-nom d’un test ou bien que vous ajoutez de nouveaux tests, il faut faire menu Générer > Tout nettoyer, puis menu Générer > Tout générer, pour que vos mises à jour soient prises en compte (cf. ce ticket). Or, cette regénération complète peut prendre plusieurs minutes sur certains projets.
• C’est pourquoi nous vous présentons la procédure sans explorateur de tests : elle fonctionne sans regénération, mais ne permet pas d’ouvrir d’un simple clic l’endroit où a eu lieu une erreur.
• Dans la deuxième ligne de menu, à droite du triangle vert, cliquez sur la flèche vers le bas : Les différents exécutables s’affichent.
• Sélectionnez unitTests.exe (unitTests\unitTests.exe) : Ce nom s’affiche désormais à droite de la flèche verte.
• Cliquez sur la flèche verte : une fenêtre s’affiche où s’exécutent vos tests unitaires.
• Si un test est faux, l’affichage vous indique le nom du fichier (unitTests.cpp) et le numéro de ligne où a eu lieu l’erreur.
• Manuellement, ouvrez le fichier mentionné et allez à la ligne concernée.

• Menu Test > Exécuter tous les tests : une fenêtre “Explorateur de tests” apparaît. Elle affiche le conseil “Générez votre solution pour découvrir tous les tests disponibles”
• Très important : Même si vous avez déjà généré votre solution, faites menu Générer > Tout générer : Après quelques secondes, votre fenêtre “Explorateur de tests” affiche désormais “unitTests” et le(s) test(s) qu’il contient.
• Menu Test > Exécuter tous les tests (ou clic sur l’icône en haut à gauche de l’explorateur de tests) : une fenêtre “Explorateur de tests” apparaît. Au bout de quelques secondes, une croix rouge apparaît devant la ligne unitTests (1) : vous avez passé votre premier test unitaire sur votre application.
• Si un test révèle une erreur, dans l’explorateur de tests, dépliez la ligne unitTest (1) et double-cliquez sur la ligne terminale TestName : Visual Studio ouvre le fichier unitTests.cpp au niveau du test unitaire en erreur (et l’explorateur de tests explicite l’erreur dans la sous-fenêtre à droite “Récapitulatif des détails du test”)
• Très important 2 : Si, après avoir fait une séance de tests, vous modifiez le nom/sous-nom d’un test ou bien que vous ajoutez de nouveaux tests, il faut faire menu Générer > Tout nettoyer, puis menu Générer > Tout générer, pour que vos mises à jour soient prises en compte (cf. ce ticket). Cette regénération complète peut prendre plusieurs minutes sur certains projets.

• Vidéo des manipulations ici.
• Fichier exemple ici

• Vidéo des manipulations ici.
• Fichier exemple ici

6.2.1 Introduction

Dans ce tutoriel vidéo, je vous propose une initiation aux principales fonctions de débogage offertes par Visual Studio. Vous pourrez ainsi gagner en efficacité et en rapidité dans la mise au point de vos programmes, qu’ils soient écrits en C++ ou dans d’autres langages. En effet, les notions présentées ici sont génériques à tous les langages de programmation.

Notez que, pour ce tutoriel, nous nous appuierons sur le fichier ExempleDeDebugDeProgramme.cpp que je vous invite à télécharger maintenant, si vous ne l’avez pas déjà fait.

6.2.2 Mise en place de l’environnement

1. Création d’un projet console
2. Recopie du code pour debugging

6.2.3 Déboguer un plantage qui ne semble pas dans notre code

1. Menu Déboguer > Exécuter sans débogage
2. La fenêtre affiche Expression: vector subscript out of range
3. Vu que la fenêtre dit Please retry to debug the application, clic sur Recommencer
4. Expliquer affichage “Windows recherche une solution au problème” (pour info, MacOS a le même comportement). Le pb ne vient pas de votre OS ou de votre IDE (VisualStudio), mais bien de votre application !
5. Cliquer sur “Déboguer” : patienter (environ 20 secondes).
6. Choisir l’instance courante : vous arrivez dans le menu de débug.
7. Nous pourrions commencer le débogage. Mais, pour vous montrer qu’on peut s’économiser le temps d’attente qu’on vient de vivre, voyons ce qui se passe si on lance notre programme directement en débogage.
8. Faisons le ménage et démarrons maintenant en mode debug, par exemple en cliquant sur le bouton “Débogueur Windows Local” ou bien en appuyant sur la touche F5
9. La fenêtre affiche toujours Expression: vector subscript out of range.
10. Vu que la fenêtre dit Please retry to debug the application, clic sur Recommencer
11. On arrive directement dans VisualStudio, dans le code du module vector qui affiche vector subscript out of range
12. Dans le cadre en bas à droite, sélectionner l’onglet “Pile des appels” : la flèche montre où est arrêté votre programme.
13. Double-cliquez sur la ligne juste en dessous : vous êtes à votre ligne de code qui a appelé vector et qui a généré le souci.
14. Sélectionnez v.size : VS vous affiche 4.
15. Sélectionnez v et cliquez sur la flèche pour voir le contenu de v : il y a 4 éléments. NB : on peut aussi voir le contenu de v dans le cadre des variables locales en bas à gauche.
16. OK, nous comprenons le bug : ajoutons le -1 et cliquons sur le bouton “Redémarrer”

6.2.4 Pas à pas

1. Nous obtenons une erreur, plus loin : division par zéro. Effectivement c vaut 0 (qui ne fait pas bon ménage avec l’opérateur modulo).
2. Pour comprendre comment c s’est retrouvé avec la valeur 0, mettons un point d’arrêt au niveau de la définition de c, puis exécutons pas à pas le programme.
3. Arrêter le programme
4. Clic droit, Exécuter jusqu’au curseur
5. Bouton “Pas à pas principal” (y compris au-dessus de l’appel à unCalcul()) ==> Zut, la valeur de c a changé.
6. Exécuter jusqu’au curseur de l’appel à unCalcul()
7. Bouton “Pas à pas détaillé” ==> Vous rentrez dans unCalcul()
8. Faire “Aperçu de la définition” ==> On voit l’origine du problème.

6.2.5 Pose d’un point d’arreêt conditionnel

1. Insérer un point d’arrêt au niveau du return resultat
2. Dans le cadre en bas à droite, clic sur l’onglet “Points d’arrêt”
3. Clic-droit sur le point d’arrêt, Paramètres
4. Clic sur Conditions, resultat == 0
5. Redémarrez
6. Désactivez ce point d’arrêt

6.2.6 Arrêter l’exécution quand la valeur d’une variable change

1. Exécutez jusqu’à ce que la variable c soit définie.
2. Dans le cadre des variables locales, clic-droit sur c et “Arrêtez quand la valeur change”. Notez que la variable a change aussi de couleur (vu que c est une référence vers a).
3. Cliquez sur “Continuer” ==> Arrêt quand a (et donc c) change.
4. Hélas, si vous cliquez sur “Redémarrez”, le programme ne s’arrête pas sur le changement de c : il faut programmer un nouveau point d’arrêt pour cette variable.

6.2.7 Nettoyage de tous les points d’arrêt

1. Menu Déboguer > Supprimer tous les points d’arrêt

6.2.8 Conclusion

Pour tester ces outils, vous pouvez créer un projet console et substituer le code automatiquement généré par le contenu de codeQuiFuit.cpp.

7.1 CLion (Linux)

1. Installez Valgrind. Par exemple, sous Ubuntu : sudo apt install valgrind
2. Dans CLion, menu Run > Run ‘unitTests’ with Valgrind Memcheck : la fenêtre Console indique que valgrind a été lancé.
3. Au bout de quelques secondes, la fenêtre en bas à droite de l’écran indique que les “Tests Results” sont OK. En fait, ceci ne concerne que les tests unitaires qui sont tous OK. SI vous cliquez sur l’onglet “Valgrind” (à côté de l’onglet “Console” actuellement affiché), vous voyez un message Leak-DefinitelyLost 3 Warnings. Si vous dépliez ce message, vous accédez au détail de ces fuites mémoire. En dépliant l’une de ces fuites, vous avez accès à la pile d’appel qui a amené à l’allocation mémoire sans libération associée. En double-cliquant sur l’une des lignes de la pile d’appel (par exemple, dans la figure 1, sur la ligne Group::Group(pugi::xml_node) Group.cpp:15)), vous accédez au code de la ligne qui a fait le new.

7.2 MacOS ==> Outil leaks

Sous MacOS, il faut s’appuyer sur l’outil leaks fourni en standard (cf. cet article).

Dans un terminal, compiler votre programme avec l’option -g (NB: Clion compile votre programme directement avec cette option). Par exemple:

cc -g -Wall -Werror nomFichier.c -o nomFichier

• Tapez la commande :

leaks --atExit --list -- ./nomFichier
# ==> Détection des leaks sans voir leur emplacement précis dans le code

• Tapez la commande :

export MallocStackLogging=1
# Rien ne se passe

• Tapez la commande :

leaks --atExit --list -- ./nomFichier
# ==> Affichage des emplacements précis dans le code

7.3 Visual Studio (Windows)

7.3.1 Visual Studio Profiler

Par rapport à Valgrind sous Linux, le Visual Studio Profiler est un peu plus compliqué à mettre en oeuvre, mais présente l’avantage de ne pas du tout ralentir l’application profilée.

Cet outil étant disponible en standard dans Visual Studio, il n’y a aucune installation à faire.

Commencez par poser un point d’arrêt au niveau de l’appel à la fonction que vous souhaitez tester. Par exemple, dans le cas d’une application CSC4526, l’appel à la fonction myMain().

Si vous souhaitez voir si vos tests unitaires révèlent des fuites mémoire :

1. Posez un point d’arrêt au niveau de la première ligne de votre premier test unitaire,
2. Cliquez sur le bouton “Débogueur Windows Local”
3. Quand vous êtes arrêté au niveau de votre ligne, dans la fenêtre en bas à droite, sélectionnez l’onglet “Pile des appels”
4. Recherchez dans cette pile la ligne unitTests.exe!RUN_ALL_TESTS() et double-cliquez dessus : le code de gtest.h s’affiche.
5. Posez un point d’arrêt sur la ligne return ::testing::UnitTest::GetInstance()->Run();
6. Dans la fenêtre en bas à droite, sélectionnez l’onglet “Points d’arrêt” et désactivez ou effacez le point d’arrêt de la première ligne de votre test unitaire.
7. Cliquez sur l’icône “Redémarrez votre session de debug” (Ctrl+Maj+F5)
8. Dans la fenêtre “Outils de diagnostic”

• Onglet “Utilisation de la mémoire”
• Cliquez sur le bouton “Profilage du tas” s’il est grisé.
• Cliquez sur le lien “activer les instantanés pour commencer le profilage du tas” : le bouton “Prendre un instantané” n’est plus grisé.
• Cliquez sur le bouton “Prendre un instantané”

9. Mettez un point d’arrêt sur la ligne qui suit l’appel à la fonction dont vous souhaitez tester les fuites.
10. Cliquez sur le bouton “Continer”
11. Cliquez sur le bouton “Prendre un instantané” : une deuxième ligne d’instantané apparaît dans la fenêtre “Outils de diagnostic” avec des flèches rouge.
12. Cliquez sur le lien à gauche de la première flèche rouge : un onglet “Instantané n°2” apparaît.
13. Pour chaque type d’objet correspondant à votre code (par exemple, unitTests.exe!Circle[])

• Double-cliquez sur ce type : vous voyez les différentes instances qui ont été perdues (cf. figure ci-dessous).
• En desssous, la pile d’appel vous montre l’endroit où le new a été fait dans le code.
• Doublez-cliquez sur une ligne de la pile pour visualiser la ligne de code qui a fait le new.

7.3.2 Dr Memory