Savoir le mode : debug ou release

Bonjour,

Je suis sous VS2005, et j'aimerai savoir s'il existe l'équivalent à : #ifdef WIN32, mais pour savoir si on est en mode debug ou release.

Merci

DEBUG (ou _DEBUG, me rappelle jamais). De toute façon ça figure dans les options du projet (C/C++ --> preprocessor).

En théorie dans le langage, il y a uniquement NDEBUG qui indique qu'on n'est pas en debug. Chaque compilateur peut ajouter ses propre choses, comme DEBUG avec visualC++.

Attention à ne pas tout mélanger.

Sous VC++, on à (entre autre chose), les comportements suivants :

- _DEBUG : permet d'indiquer au compilateur que l'on compile avec la CRT debug, et que l'on compile du code debug (nottament utilisé pour switcher entre différentes macros pour malloc(), ... new, ...)

- NDEBUG : désactive toutes les assertions (assert())

Les 2 symboles ne sont PAS DU TOUT équivalents.

Salut,

Utiliser de la compilation conditionnelle pour avoir du code différent en debug et en release c'est dangereux (et pas juste pour les yeux :p).
Pourquoi s'embêter avec deux versions alors qu'en fait on n'en a besoin que d'une (celle qu'on appelle communément release) ?

Surtout que depuis vc8 il est interdit d'après la licence d'utilisation de distribuer une version compilée en mode debug de son code.
edit : cf. MSDN Scenarios for Deployment Examples (la première note)

Je vous remerci pour l'info.

Si je pose cette question, c'est parce que j'utilise une gui en opengl dont les lib ne sont pas compilées pareil pour le mode debug et le mode release, uniquement sous VS2005 apparemment.

Je n'aurai cas changer leur nom juste avant de distribuer le projet.

C'est marrant, en général, je n'ai besoin que d'une version moi aussi, mais c'est celle qu'on appelle communément debug. Celle qui me permet de suivre en pas à pas le code et les valeurs des variables, qui me permet de mettre des tests de validité qui font baisser les perfs sans hésiter une seconde, dans laquelle je log les informations que je veux, sans me poser de questions sur ce que je dévoile du fonctionnement interne du logiciel aux utilisateurs.

Salut,

Oui, ce sont deux manières de procéder différentes, et j'ai longtemps aussi pratiqué toute la phase de développement en version 'debug' pour livrer une version 'release'.
Il y a des avantages et des inconvénients mais à mon sens, comme on livre au final la version 'release', c'est celle qui sera à valider donc autant l'utiliser tout au long du développement.

Les différences entre 'debug' et 'release' ne sont pas juste entre les #ifdef NDEBUG/_DEBUG/etc.. mais toutes les options de compilation peuvent avoir une incidence. L'exemple classique concerne les pointeurs initialisés à 0 en debug et non en release mais des problèmes plus difficiles à débusquer portent par exemple sur les différences dans les calculs avec des flottants.

Les avantages du 'debug' (le déboguage) sont plus ou moins tout à fait activables aussi en 'release' (la génération des symboles).
Effectivement par contre les variables sont souvent un peu fusillées sous le débogueur mais je m'en sers très rarement en pratique (c'est pas que je suis super fort c'est juste que je fais des tests unitaires, et mine de rien ça évite d'avoir à déboguer...).

Bref, c'est juste que j'ai remarqué que ça me faisait gagner du temps de tout faire en 'release'...

MAT.

J'aurais tendance à dire que la réalité est un peu moins tranchée.

Par expérience je développe aussi bien en release sans tests, release + debug + debugger, release + debug + debugger + tests unitaires.
Tout dépend de la situtation.

Personnellement, j'ai déjà rencontré les situations suivantes :

- un projet en C pur, avec des tas de malloc & free : release uniquement => pas un seul memory leak ni erreur dès la première compilation (là je me suis épaté :D)
- un projet de faible taille mais assez compliqué : la totale (deb + rel + tests)
- un projet trés volumineux, mais assez répétitif : release + debug (les tests unitaires auraient été trés couteux un gain faible)
- interface graphique : tests unitaires trés difficiles à écrire

...