From: Hans-Bernhard Broeker Newsgroups: comp.os.msdos.djgpp Subject: Re: big program with macros Date: 17 Aug 2000 12:00:55 GMT Organization: Aachen University of Technology (RWTH) Lines: 56 Message-ID: <8ngk5n$c2c$1@nets3.rz.RWTH-Aachen.DE> 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> NNTP-Posting-Host: acp3bf.physik.rwth-aachen.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: nets3.rz.RWTH-Aachen.DE 966513655 12364 137.226.32.75 (17 Aug 2000 12:00:55 GMT) X-Complaints-To: abuse AT rwth-aachen DOT de NNTP-Posting-Date: 17 Aug 2000 12:00:55 GMT Originator: broeker@ To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com "Rafał Maj" wrote: [...] > It isn't that easy, because I'm, using this macro (for example) like this : > char *chunk = new [1024]; > int time, i; > DBG("varible i= "< (void*)chunk ) Doesn't change much of the principle, I think. You still could #define DBG(string) _debugline(cerr << string, __LINE__, __FILE__, __TIME__); and have _debugline take an ostream object as its first argument. 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. > will expand to : > debugprintline( MyClass << "time = " << time << " i = " << i, __LINE__, > __FILE__, __TIME__ ) > So it will be only 6 function calls (one for converting MyClass to char*, > one for debugprintline(...), and 4 for > operators << ) 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. You could alternatively reduce the size of your .cpp file, of course. The number of relocation is only limited per .o file, I think, so splitting the source file could save you. > How can I check how many relocations is currently used by program ? Read 'objdump -r' output. In a nutshell: objdump -r foo.o | wc -l gives you the number (with a little offset). -- Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de) Even if all the snow were burnt, ashes would remain.