[fpc-devel] Macro Processing
Florian Klaempfl
florian at freepascal.org
Fri May 13 14:05:43 CEST 2011
Am 13.05.2011 13:45, schrieb Joerg Schuelke:
> Am Fri, 13 May 2011 11:47:54 +0200
> schrieb Florian Klaempfl <florian at freepascal.org>:
>
>> procedure dp(const x : string;y : array of const);inline;
>> begin
>> dbgstr(x,y);
>> end;
>
> Nothing is wrong with that. Except:
> - the code will never vanish from the object file. I like it, to have
> my debugging code all the time present in the sources with no need
> for commenting it out, if I think it is ready done.
> With some small macros with parameters you can do that job, having
> debugging messages, which completely vanish by doing one
> simple {$undefine MYDEBUG}.
Ifdef the dbgstr line and the code should vanish when it's inlined. If
not, this should be fixed.
> - if I try for example to use the %LINE% and %FILE% info inside the
> debugging output, which I think is their means, I can not use a
> procedure without writing the FILE and LINE thing every time I call
> it. With a macro this would be done inside the macro.
> macro dp(x,y)
> dbgstr(whatever,{$I %FILE%},{$I %LINE%},something else)
> The macro expansion than gives the LINE and FILE info without that I
> am forced to write it again and again:
> dp(x,y) in the code gives
> dbgstr(...,{$I %FILE%},{$I %LINE%},...);
> which outputs:
> MSG: test-003.pas [102] : My debugging Message.
> And not only the debugging message vanishes from my programm, the
> debugging code too, if I switch it of.
>
> But thats a special use.
Extending dump_stack is imo a much better approach, it even doesn't
duplicated information already available in debugging info.
More information about the fpc-devel
mailing list