TITLE: Using debugging macros ........................................................................... RESPONSE: spuler@coral.cs.jcu.edu.au (David Spuler) #ifdef DEBUG # define CDEBUG if ( debug ) cerr #else # define CDEBUG // #endif CDEBUG << "here\n"; This allows the flexibility of having debugging "togglable" during development, presumeably by a command-line option, but can be compiled-out in the final version. ........................................................................... RESPONSE: p j l @cs.uiuc.edu (Paul Lucas) ****> That only works if you have a C++-ignorant preprocessor, i.e., so it won't strip the // comment. This is one instance, among others, why I would like to keep cpp //-ignorant; you can do all sorts of hokey stuff that way. ........................................................................... RESPONSE: grahamd@swdev.research.otca.oz.au (Graham Dumpleton), 8 Nov 92 Noting that cfront, and I imagine any 'good' compiler, will optmise away the body of an 'if' statement if given a condition which can be evaluated at compile time, you can say. #ifdef DEBUG #define CDEBUG if (debug) cerr #else #define CDEBUG if (0) cerr #endif One problem with this though, which David Spuler pointed out to me when I told him about it, is that for safety you are best off writing #ifdef DEBUG #define CDEBUG if (!debug) ; else cerr #else #define CDEBUG if (1) ; else cerr #endif If you didn't and some one wrote if (...) CDEBUG << "here\n"; else ... you would end up with the 'else' matching the 'if' within the CDEBUG macro which could give some unexpected results. ........................................................................... RESPONSE: hansen@deci.cs.umn.edu (David M. Hansen), 6 Nov 92 I think it is a mistake to rely on what is essentially a bug in many C++ compilers. According to the ARM (section 16.1, page 370) "...a single white space replaces each comment..." _before_ preprocessing directives are executed. The annotation recognizes that C preprocessors, unless adapted for use with C++, will not recognize the // comment form, but it also makes it clear that is is inappropriate behavior. It is a bug because it means you have to be _very_ careful about how you comment your code. For example, #define MAX_WIDGETS 12 // maximum number of widgets available to the user Widget user_widgets[MAX_WIDGETS]; will not parse appropriately, leading to non-sequiter error messages. ........................................................................... RESPONSE: pjl@cs.uiuc.edu (Paul Lucas), 6 Nov 92 *****> I already pointed out that this only works on C++-ignorant preprocessors; the above example is a well-known pitfall and I consider it irrelevant. You always have to do everything carefully.