www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2000/08/17/10:45:22

From: "Rafał Maj" <r_maj AT poczta DOT onet DOT pl>
Newsgroups: comp.os.msdos.djgpp
Subject: Odp: big program with macros
Date: Thu, 17 Aug 2000 16:21:37 +0200
Organization: Academic Computer Center CYFRONET AGH
Lines: 63
Message-ID: <8ngta7$27b$1@info.cyf-kr.edu.pl>
References: <8ndkcu$lt8$1 AT info DOT cyf-kr DOT edu DOT pl> <8ne316$jmi$1 AT nets3 DOT rz DOT RWTH-Aachen DOT DE> <8ngd0u$nsv$1 AT info DOT cyf-kr DOT edu DOT pl> <8ngk5n$c2c$1 AT nets3 DOT rz DOT RWTH-Aachen DOT DE>
NNTP-Posting-Host: d-94-53-08.cyfronet.krakow.pl
X-Trace: info.cyf-kr.edu.pl 966523015 2283 149.156.1.168 (17 Aug 2000 14:36:55 GMT)
X-Complaints-To: news AT cyf-kr DOT edu DOT pl
NNTP-Posting-Date: 17 Aug 2000 14:36:55 GMT
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

> In the long run, you'll have to re-think your debugging strategy, I
> think.  Writing out everything, all the time, usually gets you
> nowhere, because you simply won't find the necessary information in
> that homungously large debug output.
[...]
> That will save only about half of the operator<< calls, which may not
> be enough to get your work done. I really think you'll need to
> reconsider the more basic question whether this type of debugging is
> useful. And if so, whether iostreams are a good method to implement
> it, compared to, say, C-style fprintf() calls.

Of course, it's stupid to print out every debug information.

But in my program, all important classes have  static, constant, and private
variables  :
  char* my_name;
  debug_level,
When I use DBG(XXX) from any class function, computer compares
(this->debug_level) with
global variable DEBUG_LEVEL and print to cerr (or disk file) only some
informations.
Debug_level variables are defined like this :
#define ClInf(Name,  DefaultDbgLevel)        \
  const int Name :: my_name = #Name;        \
  const int Name :: debug_level = find_debug_level(#Name, DefaultDbgLevel);

so I can define at begining of program array of names of functions, with I
want to be debugged
  const char* classes_to_dbg_to_cerr[] = {"cMyClass"};
  const char* classes_to_dbg_to_disk_file[] = {"cGfxDriver"};

After running program, in cerr (or disk file) I'll have in each line name of
class that printed that line.
In release version I can add line   #define ANY_DBG 0  that will cause all
debug macros to be convert to nothing, like this :
#if ANY_DBG==0
  #define DBGstr(XXX)
#else
  #define DBGstr(XXX) _dbg_fun(XXX,__FILE__,__LINE__);
#endif

I think, that this debugging strategy isn't so bad after all ?
I have only problems with debugging all classes at once.
Normaly I don't need to have so much debugging informations, so now, when I
now that pogram can be very big, until it doesn't use more then 0xFFFF
relocations - I'm very happy :)

> #define DBG(string) _debugline(cerr << string, __LINE__, __FILE__,
__TIME__);
> and have _debugline take an ostream object as its first argument.

Thanks, that is good idea.

Rafal








- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019