Macro magic

Sorry about all of the no-impending-doom code-practice-centered questions lately. I figure there's no better place to ask. The computer science guys don't talk to us physicists on campus (I think we've abused them enough).

I've always learned that, in C++, using macros (and hiding code in a non-type-safe way in general) is evil. However, I've come up with a little short hand that seems innocuous. Please show me how this macro could be dangerous, and/or propose a better solution.

Code:

---

#define THE_DEBUG_STREAM std::cout
#ifndef NDEBUG
    #define PRINT_TO_DEBUG_STREAM( x ) { (THE_DEBUG_STREAM) << "{ " << (#x) << " }: " << (x) << '\n'; }
#else
    #define PRINT_TO_DEBUG_STREAM( x ) { (x); }
#endif
#define printdb PRINT_TO_DEBUG_STREAM

---

Ex:

Code:

---


int function()
{
    return 17;
}

int main()
{
    int variable;
    printdb(variable = function());
}

---

Output:

Code:

---

{ variable = function() }: 17

---

The only issue I could think of is all of the pieces of code like this

Code:

---

some_variable;

---

that would be littered throughout my program ifdef NDEBUG..... but that's skipped over, right?

EDIT:
Oops, I made a mistake by testing in the wrong order.

I think variable would be assigned 17 in either case, since

Code:

---

//if NDEBUG is defined
#define PRINT_TO_DEBUG_STREAM( x ) { (x) };

---

But I think that's why the Monkey defined it the way he did -- if NDEBUG is defined, the statement still happens, so variable is 17. (That's why you can go wrong with assert.)

There's situations where you can't introduce braces -- somebody recently tried to do that in a ternary operator and that didn't go well at all. That's not dangerous per se, it just doesn't work.

The reason the computer science guys may say its evil is that because in C++ you always have the option of creating inline functions.

Code:

---


#ifndef NDEBUG
    template<typename T>
    void debug_output_function(std::ostream &stream, const T &x, const char *name)
    {
      stream << "{" << name << "};" << x << std::endl;
    }
    #define PRINT_TO_DEBUG_STREAM( x ) debug_output_function(THE_DEBUG_STREAM, x, (#x))
#else
    #define PRINT_TO_DEBUG_STREAM( x )
#endif

---

Firstly, don't put code that does something (has side-effects) into macros that are not executed in release. :)

Secondly, std::cerr might be more suitable for debug output (for example, it is flushed automatically, so you should see all the output that you have printed in case of crash).

Thirdly, to compile the macro to nothing you can use:

Code:

---

    #define PRINT_TO_DEBUG_STREAM( x ) (void(0))

---

That does look nicer, sphynxter. And thanks for the heads up, tabstop.

*edit* And thank you, anon, but I must stress that I don't want the code to do nothing if NDEBUG, I just want it not to print anything.

Thanks again.

Quote:

---

Originally Posted by CodeMonkey

That does look nicer, sphynxter. And thanks for the heads up, tabstop.

*edit* And thank you, anon, but I must stress that I don't want the code to do nothing if NDEBUG, I just want it not to print anything.

Thanks again.

---

Having a macro that "debug prints" something and actually evaluates its argument even when disabled sounds like a good recipe for confusing the crap out of people.

"I took that line out because all it's doing is printing a diagnostic."

"No, that line keeps the life support systems running."

"Then why is it called DEBUG PRINT?"

Typically one would be printing debug info to std::cerr, but I suppose this is just adding on to brewbuck's previous statement.

Point well made.

Quote:

---

Originally Posted by brewbuck

Having a macro that "debug prints" something and actually evaluates its argument even when disabled sounds like a good recipe for confusing the crap out of people.

"I took that line out because all it's doing is printing a diagnostic."

"No, that line keeps the life support systems running."

"Then why is it called DEBUG PRINT?"

---

Yes. We had a case of something along those lines in one of our test-platforms:

Code:

---

debug_print("Doing %d\n", x++);

---

Someone was annoyed that this code produced 8000 lines of output in one test, so took the line out. Unfortunately, that meant that x++ got removed too, which mean that a bunch of OTHER tests, that relied on x being "which test to run next" didn't get updated, and x never reached the value of "all tests done". Some tests were using their own counter, so it didn't matter, but for others, it was critical.

Debug statement should be removable without ANY side effect to the actual funciton of the code.

--
Mats