Am 13.05.2011 13:45, schrieb Joerg Schuelke:
> Am Fri, 13 May 2011 11:47:54 +0200
> schrieb Florian Klaempfl <flor...@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.
_______________________________________________
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply via email to