home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / cplus / 16024 < prev    next >
Encoding:
Text File  |  1992-11-10  |  1.5 KB  |  48 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!ascent!eb
  3. From: eb@ascent.com (Ed Barton)
  4. Subject: Re: Debugging output
  5. In-reply-to: ort@netcom.com's message of 9 Nov 92 11:20:51 GMT
  6. Message-ID: <EB.92Nov10081925@ascent.ascent.com>
  7. Date: 10 Nov 92 08:19:25
  8. References: <spuler.720931050@coral> <1992Nov9.112051.21350@netcom.com>
  9. Organization: Ascent Technology, Inc., Cambridge Massachusetts
  10. Lines: 36
  11.  
  12.  
  13. In article <1992Nov9.112051.21350@netcom.com> ort@netcom.com (David Oertel) writes:
  14.  
  15.    >> I was wondering whether anyone has any suggestions as to how to use the neat
  16.    >> operator << to produce debugging output in a way that it can be removed
  17.    >> easily from production code.  The obvious method is:
  18.  
  19.    >> #ifdef DEBUG
  20.       >> cerr << .....
  21.    >> #endif
  22.  
  23.    >> but I'd like to avoid the #ifdef -#endif lines.
  24.  
  25.        I didn't see the truly obvious answer to this post.  That is to
  26.        put the #ifdef,#endif around the body of an inline function.
  27.  
  28. Someone please correct me if I'm wrong, but I thought the arguments to
  29. an inline function still had to be evaluated, even if they aren't used
  30. in the body.  So if you write
  31.  
  32. void debug(ostream& expr) { 
  33. #ifdef DEBUG
  34.   if (debug_flag) expr << endl;
  35. #endif
  36. }
  37.  
  38. debug(cout << "foo: " << foo);
  39.  
  40. wouldn't the compiler still have to arrange to do the output anyway as
  41. part of argument evaluation, even when DEBUG is not defined?  I
  42. thought it's not supposed to matter to the result whether a function
  43. is inline or not.
  44.  
  45. Or maybe I misunderstood the suggestion?
  46.  
  47.  
  48.