_DEBUG vs NDEBUG

Visual Studio définit _DEBUG lorsque vous spécifiez l’ /MTd ou /MDd , NDEBUG désactive les assertions C standard. Utilisez-les le cas échéant, par exemple _DEBUG si vous souhaitez que votre code de débogage soit cohérent avec les techniques de débogage MS CRT et NDEBUG si vous souhaitez être cohérent avec assert() .

Si vous définissez vos propres macros de débogage (et que vous ne piratez pas le compilateur ou le runtime C), évitez de commencer par des noms comportant un trait de soulignement, car ceux-ci sont réservés.

Je compte sur NDEBUG , car il est le seul dont le comportement est normalisé entre les compilateurs et les implémentations (voir la documentation de la macro assert standard). La logique négative est une petite vitesse de lecture, mais c’est un langage commun auquel vous pouvez rapidement vous adapter.

_DEBUG sur quelque chose comme _DEBUG reviendrait à s’appuyer sur un détail d’implémentation d’un compilateur et d’une implémentation de bibliothèque particuliers. D’autres compilateurs peuvent ou non choisir la même convention.

La troisième option consiste à définir votre propre macro pour votre projet, ce qui est tout à fait raisonnable. Avoir votre propre macro vous offre une portabilité entre les implémentations et vous permet d’activer ou de désactiver votre code de débogage indépendamment des assertions. Bien que, en général, je déconseille d’avoir différentes classes d’informations de débogage activées au moment de la compilation, car cela entraîne une augmentation du nombre de configurations à construire (et à tester), ce qui est sans doute peu bénéfique.

Avec l’une de ces options, si vous utilisez un code tiers dans le cadre de votre projet, vous devez connaître la convention qu’il utilise.

La norme NDEBUG est-elle?

Oui, il s’agit d’une macro standard avec le sémantique “Not Debug” pour les standards C89, C99, C ++ 98, C ++ 2003, C ++ 2011, C ++ 2014. Il n’y a pas de macros _DEBUG dans les standards.

La norme C ++ 2003 envoie le lecteur à la “page 326” dans “17.4.2.1 En-têtes” à la norme C.

Ce NDEBUG est similaire à Ceci est la même que la bibliothèque Standard C.

En C89 (les programmeurs C ont appelé cette norme en standard C) dans la section “4.2 DIAGNOSTICS”

http://port70.net/~nsz/c/c89/c89-draft.html

Si NDEBUG est défini comme un nom de macro au point dans le fichier source où est inclus, la macro assert est définie simplement comme

  #define assert(ignore) ((void)0) 

Si vous regardez la signification des macros _DEBUG dans Visual Studio https://msdn.microsoft.com/en-us/library/b0084kay.aspx, vous verrez que cette macro est automatiquement définie par votre version de la langue du runtime de la langue .

La macro NDEBUG contrôle si les instructions assert () sont actives ou non.

À mon avis, cela est distinct de tout autre débogage – donc, j’utilise autre chose que NDEBUG pour contrôler les informations de débogage dans le programme. Ce que j’utilise varie selon le cadre avec lequel je travaille; différents systèmes ont des macros activasortingces différentes, et j’utilise tout ce qui est approprié.

S’il n’y a pas de framework, j’utiliserais un nom sans trait de soulignement. ceux-ci ont tendance à être réservés à «l’implémentation» et j’essaye d’éviter les problèmes avec les collsions de noms – doublement quand le nom est une macro.

Soyez cohérent et peu importe lequel. Aussi, si pour une raison quelconque vous devez interagir avec un autre programme ou outil utilisant un identifiant DEBUG certain, il est facile à faire

 #ifdef THEIRDEBUG #define MYDEBUG #endif //and vice-versa 

Malheureusement, “DEBUG” est surchargé. Par exemple, il est recommandé de toujours générer et enregistrer un fichier pdb pour les versions RELEASE. Ce qui signifie l’un des drapeaux -Zx et de l’éditeur de liens -DEBUG. Alors que _DEBUG concerne des versions de débogage spéciales de la bibliothèque d’exécution telles que les appels à malloc et free. Alors NDEBUG désactivera les assertions.