Apprendre à utiliser le débogueur

Bonjour

Depuis plusieurs années, je fais des petits programmes pour m'amuser et je les ai toujours débogués à la main. C'est à dire à coup de "std::cout". :oops: Ce qui, je sais, est loin d'être une bonne méthode. Parce qu'il serait temps que j'apprenne la bonne façon de faire et parce que j'ai commencé un projet qui est beaucoup plus complexe et volumineux que ce que j'avais fait jusqu'à présent, j'ai décidé d'apprendre à utiliser le débogueur de mon EDI. Mieux vaut tard que jamais. :lol:

J'ai commencé par chercher un tutoriel et jai trouvé celui-ci:
https://loulou.developpez.com/tutori...visual-studio/

Ce tutoriel semble très bien, mais lorsque je tente d'exécuter le programme à partir de l'interface de VS ("Start Debugging" ou "Start Without Debugging") mon programme ne trouve pas les fichiers dont il a besoin pour fonctionner. (.png, .wav, .ttf, etc.) J'ai copié ces fichiers dans les dossiers où se trouvent les exécutables ("Release" et "Debug" du projet) et quand j'ouvre mon programme directement depuis les dossiers je n'ai pas ce problème. Les fichiers sont chargés et utilisés par le programme sans problème. (sauf quelques petits bogues que je cherche justement à corriger avec le débogueur)

Donc voila ma question, pouvez-vous m'expliquer ce qui ne va pas avec mon utilisation de VS et/ou me guider vers des tutoriels qui me permettraient de maitriser les généralités de cet EDI?

Merci

Info supplémentaire:
J'utilise Visual Studio Express 2015 sur Windows 8
Mon programme fonctionne avec SDL, SDL_image, SDL_mixer et SDL_ttf

Bizarre que ce tutoriel n'aborde pas ce "détail" des plus importants, quand on débute.
Avec un peu d'expérience, on fait des programmes qui ne sont pas sujet à "planter" pour cause d'un répertoire de travail "défaillant".
Il a donc dû oublier que les débutants se prennent souvent ce problème dans les dents.
Vous devriez assez vite faire en sorte que votre programme fonctionne quelque-soit le répertoire de travail du processus que vous lancez.
En attendant de correctement maitriser ce "concept", il est assez simple de palier le "problème".
Allez dans les options de votre projet.
Propriétés de configuration -> Débogage -> Répertoire de travail.
Tous les chemins relatifs seront par rapport à ce répertoire (ou à l'évaluation des valeurs qui seront calculées via les "MACRO" variables).

Merci beaucoup bacelar, cela à effectivement réglé mon problème.

Cependant, je suis intrigué par votre "concept" de programme indépendant du répertoire de travail. J'aimerais en savoir plus. J'ai fait quelques recherches avec des mots-clés comme visual c++ répertoire travail, mais je n'ai rien trouvé à ce sujet. Auriez-vous l'amabilité d'aiguiller ma recherche? Ce "concept" porte-t-il un nom ou connaissez-vous un tutoriel sur le sujet?

Le "concept" de répertoire de travail est au moins aussi vieux qu'Unix, au début des années 70.
https://en.wikipedia.org/wiki/Working_directory

Ce n'est pas lié à un langage (C++) ou un IDE (VS) ou un compilateur (VC++), c'est lié au système d'exploitation.
Je ne connais aucun OS qui ne l'implémente pas. (Même dans les firmware de cartes à puce, il y a ce "concept")

C++ dérive du langage C, lui-même inventé pour le système Unix. Il est donc assez naturel que le langage tire partie de cette fonctionnalité offerte par l'OS, via des chemins relatifs.
Sauf qu'il faut bien comprendre comment ça fonctionne pour ne pas se retrouver avec des programmes qui fonctionnent si on les lance d'une certaine manière et plantent lamentablement en les lançant autrement.

Souvent, une "gestion" de cela se résume à faire en sorte que le répertoire de travail soit fixé par le processus lui-même et plus hérité par son processus "parent" via une fonction du genre :
https://www.boost.org/doc/libs/1_53_...l#current_path
(ou plein d'autres moyen moins portable, moins standard, ...)

On fixe ce répertoire de travail à un truc qui a été conçu pour être un point de fixation, comme l'endroit dans le système de fichier où le fichier image du processus est stocké :
https://stackoverflow.com/questions/...table/34109000

Mais dans es petit programme utilitaire "console", on cherche à ne pas modifier ce "working directory" pour que le processus parent ait toujours le contrôle et puisse facilement piloter le travail du processus suivant dans la chaine de traitement (usage principal dans le cadre des programmes sous Unix dans les années 70).

Merci encore pour ces informations. J'étudierai tout ça.