[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