define macro for debug printing in C

Question

Trying to create a macro which can be used for print debug messages when DEBUG is defined  like the following pseudo code    define DEBUG 1  define debug print args      if  DEBUG  fprintf stderr  args    How is this accomplished with a macro

User · Answer

define debug print FMT  ARGS     do         if  DEBUG            fprintf stderr    s  d   FMT   n     FUNCTION      LINE       ARGS           while  0

User · Answer

Here s the version I use    ifdef NDEBUG  define Dprintf FORMAT         void 0   define Dputs MSG    void 0   else  define Dprintf FORMAT             fprintf stderr    s   in  s  line  i    FORMAT   n               func      FILE      LINE      VA ARGS     define Dputs MSG  Dprintf   s   MSG   endif

User · Answer

For a portable  ISO C90  implementation  you could use double parentheses  like this    include  lt stdio h gt   include  lt stdarg h gt    ifndef NDEBUG    define debug print msg  stderr printf msg  else    define debug print msg   void 0  endif  void stderr printf const char  fmt           va list ap    va start ap  fmt     vfprintf stderr  fmt  ap     va end ap      int main int argc  char  argv        debug print   argv 0  is  s  argc is  d n   argv 0   argc      return 0      or  hackish  wouldn t recommend it    include  lt stdio h gt    define      ifndef NDEBUG    define debug print msg  fprintf stderr  msg   else    define debug print msg   void 0  endif  int main int argc  char  argv        debug print  argv 0  is  s  argc is  d   argv 0    argc     return 0

User · Answer

My favourite of the below is var dump  which when called as   var dump   d   count    produces output like   patch c 150 main    count   0  Credit to   Jonathan Leffler   All are C89-happy   Code   define DEBUG 1  include  lt stdarg h gt   include  lt stdio h gt  void debug vprintf const char  fmt             va list args      va start args  fmt       vfprintf stderr  fmt  args       va end args         Call as   DOUBLE PARENTHESES ARE MANDATORY        var debug   outfd    d  somefailed    d n   outfd  somefailed        define var debug x  do   if  DEBUG    debug vprintf    s  d  s               FILE       LINE      func     debug vprintf x     while  0      var dump   s  variable name       define var dump fmt  var  do   if  DEBUG    debug vprintf    s  d  s               FILE       LINE      func     debug vprintf    s     fmt   var  var      while  0    define DEBUG HERE do   if  DEBUG    debug vprintf    s  d  s    HERE n           FILE       LINE      func        while  0

User · Answer

I use something like this    ifdef DEBUG   define D if 1    else   define D if 0    endif   Than I just use D as a prefix   D printf  x  0 3f n  x     Compiler sees the debug code  there is no comma problem and it works everywhere  Also it works when printf is not enough  say when you must dump an array or calculate some diagnosing value that is redundant to the program itself   EDIT  Ok  it might generate a problem when there is else somewhere near that can be intercepted by this injected if  This is a version that goes over it    ifdef DEBUG   define D   else   define D for  0    endif

User · Answer

I ve been stewing on how to do this for years  and finally come up with a solution   However  I didn t know that there were other solutions here already   First  at difference with Leffler s answer  I don t see his argument that debug prints should always be compiled   I d rather not have tons of unneeded code executing in my project  when not needed  in cases where I need to test and they might not be getting optimized out   Not compiling every time might sound worse than it is in actual practice   You do wind up with debug prints that don t compile sometimes  but it s not so hard to compile and test them before finalizing a project   With this system  if you are using three levels of debugs  just put it on debug message level three  fix your compile errors and check for any others before you finalize yer code    Since of course  debug statements compiling are no guarantee that they are still working as intended    My solution provides for levels of debug detail also  and if you set it to the highest level  they all compile   If you ve been using a high debug detail level recently  they all were able to compile at that time   Final updates should be pretty easy   I ve never needed more than three levels  but Jonathan says he s used nine   This method  like Leffler s  can be extended to any number of levels   The usage of my method may be simpler  requiring just two statements when used in your code   I am  however  coding the CLOSE macro too - although it doesn t do anything   It might if I were sending to a file   Against the cost the extra step of testing them to see that they will compile before delivery  is that   You must trust them to get optimized out  which admittedly SHOULD happen if you have a sufficient optimization level  Furthermore  they probably won t if you make a release compile with optimization turned off for testing purposes  which is admittedly rare   and they almost certainly won t at all during debug - thereby executing dozens or hundreds of  if  DEBUG   statements at runtime  thus slowing execution  which is my principle objection  and less importantly  increasing your executable or dll size  and hence execution and compile times   Jonathan  however  informs me his method can be made to also not compile statements at all    Branches are actually relatively pretty costly in modern pre-fetching processors   Maybe not a big deal if your app is not a time-critical one  but if performance is an issue  then  yes  a big enough deal that I d prefer to opt for somewhat faster-executing debug code  and possibly faster release  in rare cases  as noted    So  what I wanted is a debug print macro that does not compile if it is not to be printed  but does if it is   I also wanted levels of debugging  so that  e g  if I wanted performance-crucial parts of the code not to print at some times  but to print at others  I could set a debug level  and have extra debug prints kick in   I came across a way to implement debug levels that determined if the print was even compiled or not   I achieved it this way   DebugLog h      FILE  DebugLog h    REMARKS  This is a generic pair of files useful for debugging   It provides three levels of     debug logging  currently  in addition to disabling it   Level 3 is the most information     Levels 2 and 1 have progressively more   Thus  you can write          DEBUGLOG LOG 1   a number  d   7      and it will be seen if DEBUG is anything other than undefined or zero   If you write        DEBUGLOG LOG 3   another number  d   15      it will only be seen if DEBUG is 3   When not being displayed  these routines compile    to NOTHING   I reject the argument that debug code needs to always be compiled so as to     keep it current   I would rather have a leaner and faster app  and just not be lazy  and     maintain debugs as needed   I don t know if this works with the C preprocessor or not      but the rest of the code is fully C compliant also if it is    define DEBUG 1   ifdef DEBUG  define DEBUGLOG INIT filename  debuglog init filename   else  define debuglog init       endif   ifdef DEBUG  define DEBUGLOG CLOSE debuglog close  else  define debuglog close       endif   define DEBUGLOG LOG level  fmt       DEBUGLOG LOG    level  fmt      VA ARGS      if DEBUG    0  define DEBUGLOG LOG0       endif   if DEBUG  gt   1  define DEBUGLOG LOG1 fmt       debuglog log  fmt      VA ARGS     else  define DEBUGLOG LOG1       endif   if DEBUG  gt   2  define DEBUGLOG LOG2 fmt       debuglog log  fmt      VA ARGS     else  define DEBUGLOG LOG2       endif   if DEBUG    3  define DEBUGLOG LOG3 fmt       debuglog log  fmt      VA ARGS     else  define DEBUGLOG LOG3       endif  void debuglog init char  filename   void debuglog close void   void debuglog log char  format          DebugLog cpp      FILE  DebugLog h    REMARKS  This is a generic pair of files useful for debugging   It provides three levels of     debug logging  currently  in addition to disabling it   See DebugLog h s remarks for more     info    include  lt stdio h gt   include  lt stdarg h gt    include  DebugLog h   FILE  hndl  char  savedFilename   void debuglog init char  filename        savedFilename   filename      hndl   fopen savedFilename   wt        fclose hndl      void debuglog close void          fclose hndl      void debuglog log char  format             hndl   fopen savedFilename  at        va list argptr      va start argptr  format       vfprintf hndl  format  argptr       va end argptr       fputc   n  hndl       fclose hndl       Using the macros  To use it  just do   DEBUGLOG INIT  afile log      To write to the log file  just do   DEBUGLOG LOG 1   the value is   d   anint     To close it  you do   DEBUGLOG CLOSE      although currently this isn t even necessary  technically speaking  as it does nothing   I m still using the CLOSE right now  however  in case I change my mind about how it works  and want to leave the file open between logging statements   Then  when you want to turn on debug printing  just edit the first  define in the header file to say  e g    define DEBUG 1   To have logging statements compile to nothing  do   define DEBUG 0   If you need info from a frequently executed piece of code  i e  a high level of detail   you may want to write    DEBUGLOG LOG 3   the value is   d   anint     If you define DEBUG to be 3  logging levels 1  2  amp  3 compile   If you set it to 2  you get logging levels 1  amp  2   If you set it to 1  you only get logging level 1 statements   As to the do-while loop  since this evaluates to either a single function or nothing  instead of an if statement  the loop is not needed   OK  castigate me for using C instead of C   IO  and Qt s QString  arg   is a safer way of formatting variables when in Qt  too     it s pretty slick  but takes more code and the formatting documentation isn t as organized as it might be - but still I ve found cases where its preferable   but you can put whatever code in the  cpp file you want   It also might be a class  but then you would need to instantiate it and keep up with it  or do a new   and store it   This way  you just drop the  include  init and optionally close statements into your source  and you are ready to begin using it   It would make a fine class  however  if you are so inclined   I d previously seen a lot of solutions  but none suited my criteria as well as this one    It can be extended to do as many levels as you like  It compiles to nothing if not printing  It centralizes IO in one easy-to-edit place  It s flexible  using printf formatting  Again  it does not slow down debug runs  whereas always-compiling debug prints are always executed in debug mode   If you are doing computer science  and not easier to write information processing  you may find yourself running a CPU-consuming simulator  to see e g  where the debugger stops it with an index out of range for a vector   These run extra-slowly in debug mode already   The mandatory execution of hundreds of debug prints will necessarily slow such runs down even further   For me  such runs are not uncommon    Not terribly significant  but in addition    It requires no hack to print without arguments  e g  DEBUGLOG LOG 3   got here       thus allowing you to use  e g  Qt s safer  arg   formatting   It works on MSVC  and thus  probably gcc   It uses    in the  defines  which is non-standard  as Leffler points out  but is widely supported    You can recode it not to use    if necessary  but you will have to use a hack such as he provides     Warning  If you forget to provide the logging level argument  MSVC unhelpfully claims the identifier is not defined   You might want to use a preprocessor symbol name other than DEBUG  as some source also defines that symbol  eg  progs using   configure commands to prepare for building    It seemed natural to me when I developed it   I developed it in an application where the DLL is being used by something else  and it s more convent to send log prints to a file  but changing it to vprintf   would work fine  too   I hope this saves many of you grief about figuring out the best way to do debug logging  or shows you one you might prefer   I ve half-heartedly been trying to figure this one out for decades   Works in MSVC 2012  amp  2015  and thus probably on gcc  as well as probably working on many others  but I haven t tested it on them   I mean to make a streaming version of this one day  too   Note  Thanks go to Leffler  who has cordially helped me format my message better for StackOverflow

User · Answer

This is what I use    if DBG  include  lt stdio h gt   define DBGPRINT printf  else  define DBGPRINT              endif   It has the nice benefit to handle printf properly  even without additional arguments  In case DBG   0  even the dumbest compiler gets nothing to chew upon  so no code is generated

User · Answer

So  when using gcc  I like    define DBGI expr    int g2rE3 expr  fprintf stderr    s  d  s       s- gt  i n     FILE       LINE      func     expr  g2rE3   g2rE3      Because it can be inserted into code   Suppose you re trying to debug  printf   i n    1 2 3 4 5 6     720   Then you can change it to   printf   i n   DBGI 1 2 3 4 5 6     hello c 86 main    1 2 3 4 5 6- gt 720 720   And you can get an analysis of what expression was evaluated to what    It s protected against the double-evaluation problem  but the absence of gensyms does leave it open to name-collisions   However it does nest   DBGI printf   i n   DBGI 1 2 3 4 5 6      hello c 86 main    1 2 3 4 5 6- gt 720 720 hello c 86 main    printf   i n   DBGI 1 2 3 4 5 6  - gt 4   So I think that as long as you avoid using g2rE3 as a variable name  you ll be OK   Certainly I ve found it  and allied versions for strings  and versions for debug levels etc  invaluable

User · Answer

I believe this variation of the theme gives debug categories without the need to have a separate macro name per category    I used this variation in an Arduino project where program space is limited to 32K and dynamic memory is limited to 2K   The addition of debug statements and trace debug strings quickly uses up space  So it is essential to be able to limit the debug trace that is included at compile time to the minimum necessary each time the code is built   debug h   ifndef DEBUG H  define DEBUG H   define PRINT DEBUG CATEGORY  VALUE   do   if  DEBUG CATEGORY  amp  DEBUG MASK  Serial print VALUE    while  0     endif   calling  cpp file   define DEBUG MASK 0x06  include  Debug h       PRINT 4   Time out error  t

User · Answer

I would do something like    ifdef DEBUG  define debug print fmt       fprintf stderr  fmt    VA ARGS     else  define debug print fmt       do    while  0   endif   I think this is cleaner

User · Answer

If you use a C99 or later compiler   define debug print fmt                     do   if  DEBUG  fprintf stderr  fmt    VA ARGS       while  0    It assumes you are using C99  the variable argument list notation is not supported in earlier versions    The do         while  0  idiom ensures that the code acts like a statement  function call    The unconditional use of the code ensures that the compiler always checks that your debug code is valid  mdash  but the optimizer will remove the code when DEBUG is 0   If you want to work with  ifdef DEBUG  then change the test condition    ifdef DEBUG  define DEBUG TEST 1  else  define DEBUG TEST 0  endif   And then use DEBUG TEST where I used DEBUG   If you insist on a string literal for the format string  probably a good idea anyway   you can also introduce things like   FILE      LINE   and   func   into the output  which can improve the diagnostics    define debug print fmt                 do   if  DEBUG  fprintf stderr    s  d  s      fmt    FILE                                        LINE      func      VA ARGS       while  0    This relies on string concatenation to create a bigger format string than the programmer writes   If you use a C89 compiler  If you are stuck with C89 and no useful compiler extension  then there isn t a particularly clean way to handle it   The technique I used to use was    define TRACE x  do   if  DEBUG  dbg printf x    while  0    And then  in the code  write   TRACE   message  d n   var      The double-parentheses are crucial  mdash  and are why you have the funny notation in the macro expansion   As before  the compiler always checks the code for syntactic validity  which is good  but the optimizer only invokes the printing function if the DEBUG macro evaluates to non-zero   This does require a support function  mdash  dbg printf   in the example  mdash  to handle things like  stderr    It requires you to know how to write varargs functions  but that isn t hard    include  lt stdarg h gt   include  lt stdio h gt   void dbg printf const char  fmt             va list args      va start args  fmt       vfprintf stderr  fmt  args       va end args       You can also use this technique in C99  of course  but the   VA ARGS   technique is neater because it uses regular function notation  not the double-parentheses hack   Why is it crucial that the compiler always see the debug code    Rehashing comments made to another answer    One central idea behind both the C99 and C89 implementations above is that the compiler proper always sees the debugging printf-like statements   This is important for long-term code  mdash  code that will last a decade or two   Suppose a piece of code has been mostly dormant  stable  for a number of years  but now needs to be changed   You re-enable debugging trace - but it is frustrating to have to debug the debugging  tracing  code because it refers to variables that have been renamed or retyped  during the years of stable maintenance  If the compiler  post pre-processor  always sees the print statement  it ensures that any surrounding changes have not invalidated the diagnostics  If the compiler does not see the print statement  it cannot protect you against your own carelessness  or the carelessness of your colleagues or collaborators   See  The Practice of Programming  by Kernighan and Pike  especially Chapter 8  see also Wikipedia on TPOP     This is  been there  done that  experience  mdash  I used essentially the technique described in other answers where the non-debug build does not see the printf-like statements for a number of years  more than a decade   But I came across the advice in TPOP  see my previous comment   and then did enable some debugging code after a number of years  and ran into problems of changed context breaking the debugging  Several times  having the printing always validated has saved me from later problems   I use NDEBUG to control assertions only  and a separate macro  usually DEBUG  to control whether debug tracing is built into the program  Even when the debug tracing is built in  I frequently do not want debug output to appear unconditionally  so I have mechanism to control whether the output appears  debug levels  and instead of calling fprintf   directly  I call a debug print function that only conditionally prints so the same build of the code can print or not print based on program options    I also have a  multiple-subsystem  version of the code for bigger programs  so that I can have different sections of the program producing different amounts of trace - under runtime control   I am advocating that for all builds  the compiler should see the diagnostic statements  however  the compiler won t generate any code for the debugging trace statements unless debug is enabled   Basically  it means that all of your code is checked by the compiler every time you compile - whether for release or debugging   This is a good thing   debug h - version 1 2  1990-05-01          File              RCSfile  debug h v       Version           Revision  1 2       Last changed      Date  1990 05 01 12 55 39       Purpose          Definitions for the debugging system     Author           J Leffler      ifndef DEBUG H  define DEBUG H     -- Macro Definitions      ifdef DEBUG  define TRACE x     db print x  else  define TRACE x   endif    DEBUG        -- Declarations      ifdef DEBUG extern  int     debug   endif   endif     DEBUG H      debug h - version 3 6  2008-02-11          File             RCSfile  debug h v       Version          Revision  3 6       Last changed     Date  2008 02 11 06 46 37       Purpose         Definitions for the debugging system     Author          J Leffler     Copyright        C  JLSS 1990-93 1997-99 2003 2005 2008     Product          PRODUCT       ifndef DEBUG H  define DEBUG H   ifdef HAVE CONFIG H  include  config h   endif    HAVE CONFIG H           Usage   TRACE  level  fmt            level  is the debugging level which must be operational for the output    to appear   fmt  is a printf format string        is whatever extra    arguments fmt requires  possibly nothing      The non-debug macro means that the code is validated but never called     -- See chapter 8 of  The Practice of Programming   by Kernighan and Pike      ifdef DEBUG  define TRACE x     db print x  else  define TRACE x     do   if  0  db print x    while  0   endif    DEBUG      ifndef lint  ifdef DEBUG    This string can t be made extern - multiple definition in general    static const char jlss id debug enabled              DEBUG        endif    DEBUG     ifdef MAIN PROGRAM const char jlss id debug h           Id  debug h v 3 6 2008 02 11 06 46 37 jleffler Exp      endif    MAIN PROGRAM     endif    lint      include  lt stdio h gt   extern int      db getdebug void   extern int      db newindent void   extern int      db oldindent void   extern int      db setdebug int level   extern int      db setindent int i   extern void     db print int level  const char  fmt       extern void     db setfilename const char  fn   extern void     db setfileptr FILE  fp   extern FILE     db getfileptr void       Semi-private function    extern const char  db indent void                                                MULTIPLE DEBUGGING SUBSYSTEMS CODE                                                    Usage   MDTRACE  subsys  level  fmt            subsys  is the debugging system to which this statement belongs     The significance of the subsystems is determined by the programmer     except that the functions such as db print refer to subsystem 0      level  is the debugging level which must be operational for the    output to appear   fmt  is a printf format string        is    whatever extra arguments fmt requires  possibly nothing      The non-debug macro means that the code is validated but never called      ifdef DEBUG  define MDTRACE x   db mdprint x  else  define MDTRACE x   do   if  0  db mdprint x    while  0   endif    DEBUG     extern int      db mdgetdebug int subsys   extern int      db mdparsearg char  arg   extern int      db mdsetdebug int subsys  int level   extern void     db mdprint int subsys  int level  const char  fmt       extern void     db mdsubsysnames char const   const  names     endif    DEBUG H      Single argument variant for C99 or later  Kyle Brandt asked      Anyway to do this so debug print still works even if there are no arguments  For example       debug print  Foo       There s one simple  old-fashioned hack   debug print   s n    Foo      The GCC-only solution shown below also provides support for that   However  you can do it with the straight C99 system by using    define debug print                    do   if  DEBUG  fprintf stderr    VA ARGS       while  0    Compared to the first version  you lose the limited checking that requires the  fmt  argument  which means that someone could try to call  debug print    with no arguments  but the trailing comma in the argument list to fprintf   would fail to compile    Whether the loss of checking is a problem at all is debatable   GCC-specific technique for a single argument  Some compilers may offer extensions for other ways of handling variable-length argument lists in macros   Specifically  as first noted in the comments by Hugo Ideler  GCC allows you to omit the comma that would normally appear after the last  fixed  argument to the macro   It also allows you to use     VA ARGS   in the macro replacement text  which deletes the comma preceding the notation if  but only if  the previous token is a comma    define debug print fmt                     do   if  DEBUG  fprintf stderr  fmt      VA ARGS       while  0    This solution retains the benefit of requiring the format argument while accepting optional arguments after the format   This technique is also supported by Clang for GCC compatibility     Why the do-while loop      What s the purpose of the do while here    You want to be able to use the macro so it looks like a function call  which means it will be followed by a semi-colon   Therefore  you have to package the macro body to suit   If you use an if statement without the surrounding do         while  0   you will have      BAD - BAD - BAD     define debug print                    if  DEBUG  fprintf stderr    VA ARGS      Now  suppose you write   if  x  gt  y      debug print  x   d   gt  y   d  n   x  y   else     do something useful x  y     Unfortunately  that indentation doesn t reflect the actual control of flow  because the preprocessor produces code equivalent to this  indented and braces added to emphasize the actual meaning    if  x  gt  y        if  DEBUG          fprintf stderr   x   d   gt  y   d  n   x  y       else         do something useful x  y       The next attempt at the macro might be      BAD - BAD - BAD     define debug print                    if  DEBUG    fprintf stderr    VA ARGS         And the same code fragment now produces   if  x  gt  y      if  DEBUG                fprintf stderr   x   d   gt  y   d  n   x  y              Null statement from semi-colon after macro else     do something useful x  y     And the else is now a syntax error   The do         while 0  loop avoids both these problems   There s one other way of writing the macro which might work      BAD - BAD - BAD     define debug print                      void   DEBUG    fprintf stderr    VA ARGS      0     This leaves the program fragment shown as valid   The  void  cast prevents it being used in contexts where a value is required  mdash  but it could be used as the left operand of a comma operator where the do         while  0  version cannot   If you think you should be able to embed debug code into such expressions  you might prefer this   If you prefer to require the debug print to act as a full statement  then the do         while  0  version is better   Note that if the body of the macro involved any semi-colons  roughly speaking   then you can only use the do         while 0  notation   It always works  the expression statement mechanism can be more difficult to apply   You might also get warnings from the compiler with the expression form that you d prefer to avoid  it will depend on the compiler and the flags you use      TPOP was previously at http   plan9 bell-labs com cm cs tpop and http   cm bell-labs com cm cs tpop but both are now  2015-08-10  broken      Code in GitHub  If you re curious  you can look at this code in GitHub in my SOQ  Stack Overflow Questions  repository as files debug c  debug h and mddebug c in the src libsoq sub-directory

User · Answer

According to http   gcc gnu org onlinedocs cpp Variadic-Macros html  there should be a    before   VA ARGS     Otherwise  a macro  define dbg print format       printf format    VA ARGS    will not compile the following example  dbg print  hello world

[c] #define macro for debug printing in C?

Examples related to c

Examples related to c-preprocessor