From:	Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
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
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" <r_maj AT poczta DOT onet DOT pl> 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= "<<i<<", time= " << time <<  ",  chunk is in : " <<
> (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.

- Raw text -