0

Global.h

#ifndef GLOBAL_H
#   define GLOBAL_H

#define DEBUG

#ifdef DEBUG
#   define IF_DEBUG( ... )   __VA_ARGS__
#else
#   define IF_DEBUG( ... )
#endif /* DEBUG */

#endif /* GLOBAL_H */

Main.cpp

#include <string>
#include <iostream>
#include "Global.h"

int main() {
    int A = 1;
    int B = 2;
    int C = 0;

    IF_DEBUG(
        std::cout << "\nStep 1> Calculating...\n";
    )

    C = A + B;

    // DO WHATEVER

    IF_DEBUG(
        std::cout << "\nStep n> ...\n";
    )

    // ...

    std::cout << C << std::endl;

    // Note: I could also do some operations within the IF_DEBUG macro.
    IF_DEBUG(
        int X = 10;
        int Y = 5;
        int Z = X / Y;
        std::cout << Z << std::endl;
    )

    IF_DEBUG(
        std::cout << "\nDebugged! This program has been paused. Enter any key to continue!\n";
        ::getchar();
    )
    return 0;
}

Do you see how I defined IF_DEBUG in the Global header file (Global.h) and how I constantly used it in the Main source file (Main.cpp) for debugging purposes? Is it okay and safe to do that?

I am asking this question because I am unsure if its okay to do that. When I show this to my friend and he said its "bad" to do that. Therefore, I am unsure.

user2864740
  • 60,010
  • 15
  • 145
  • 220
Robert Wish
  • 155
  • 2
  • 9
  • 2
    I've seen worse forms of macro abuse than this. IMO, this is pretty tame... – Mysticial Mar 29 '13 at 00:47
  • Yeah. I mean, I don't know if this would have an impact on the performance of the program or not. So, I am a bit a worried. – Robert Wish Mar 29 '13 at 00:48
  • A little unorthodox to have `#define DEBUG` followed in the next line by `#ifdef DEBUG`?... But performance wise I don't see it as a problem. You want things printed out, it will affect performance; you turn that off, performance hit goes away. But right now including the header file means debug is always turned on. – Floris Mar 29 '13 at 00:49
  • No it will not impact performance. It's done by the compiler during preprocessing. – Mysticial Mar 29 '13 at 00:49
  • 1
    It's super odd though. The typical pattern is to use a single parameter and double brackets if it needs a comma, like `IF_DEBUG((a,b))`. I believe that `__VA_ARGS__` is non-standard. – Dave Mar 29 '13 at 00:49
  • Oh because when I show this code a person and he said that its "bad" to do that. But I wasn't sure if he was right or wrong, so I decided to posted it for some feedbacks. – Robert Wish Mar 29 '13 at 00:51
  • @Dave what do you mean by that its odd? :0 – Robert Wish Mar 29 '13 at 00:52
  • 1
    @RobertWish: I explained it in the comment; the more usual method is to use double brackets if needed, so that only a single (non-variadic) argument is needed (because variadic arguments are non-standard in C++ pre-11, have 2 syntaxes for different compilers, and aren't supported in others). For example, look at GCC's `__attribute__(())` syntax. – Dave Mar 29 '13 at 01:00
  • @Dave tyvm. I'll go check it out. – Robert Wish Mar 29 '13 at 01:01
  • @Dave __VA_ARGS__ is standard. It is part of C++11, Variadic macros. – Benilda Key Jun 24 '14 at 06:02
  • @BenKey "because variadic arguments are non-standard in C++ **pre-11**" – Dave Jun 24 '14 at 11:37

1 Answers1

3

This is a very common and useful trick. But it's better not to have the #define DEBUG in the source code. You can define it in the compile command line instead. g++ -DDEBUG -c file.cpp will compile the code as if DEBUG was defined.

If you're using a Makefile you can add it to the CPPFLAGS (C Preprocessor Flags) variable: CPPFLAGS=-DDEBUG.

If you're using an IDE try to find the C Preprocessor Flags in the project settings.

felipecrv
  • 1,780
  • 2
  • 15
  • 14
  • 2
    The `__VA_ARGS__` bit isn't common, but aside from that I agree. – Dave Mar 29 '13 at 00:57
  • Okay, thanks philix. I was just making sure. :) @Dave I thought so too. Guess I was the first? Lol. – Robert Wish Mar 29 '13 at 00:58
  • 2
    +1: I worked at a place that used a set of fancier macros, generally akin to this, to implement a pretty sophisticated logging system. And when the release version was built, *poof*, all that code just vanished in the executable. – Bob Murphy Mar 29 '13 at 00:59
  • Often, compilers define `_DEBUG`, if you truly want to do this for debug builds, you might consider using that as your switch, instead. That being said, I often use tricks like this that I can conditionally enable when I need a little more help/info while debugging. It's not a substitute for a debugger, but it can help to give a little more context on where an issue is occurring, so you know where to debug. – Nathan Ernst Mar 29 '13 at 03:28
  • I think `_DEBUG` is Visual Studio specific. The standard (used to control C assertions) is `NDEBUG`. http://stackoverflow.com/questions/2290509/debug-vs-ndebug – felipecrv Mar 29 '13 at 18:56