Re^3: Debug Macro

No this doesn't help. You're still paying the cost of a function call. And function calls are s-l-o-w in Perl.

actually with filtering you don't pay for it, it is there or not (a bit like when you use dynamic linking and you switch some instrumenting lib for a non-instrumenting one -- so you can use a wrapper)

then with code like this

foo() if $foo;

why do you pay for a function call?

anyway your comment reminds of that perl command line flag (-P) that calls the C preprocessor on your code... maybe it could be useful for this can of debugging?! (chess notation)

cheers --stephan p.s by the way for me true macros are lispish macros, the others do textual substitution (meaning not caring about syntax) and that can break easily like perl filters or cpp)

Comment on Re^3: Debug Macro Download Code

Replies are listed 'Best First'.

Re^4: Debug Macro
by grinder (Bishop) on Mar 28, 2007 at 06:58 UTC

actually with filtering you don't pay for it

Do you mean source filtering? I cannot, in all honesty, recommend this approach. It's fun to play with, but I consider that in general it's a glorious experiment that failed magnificently. I'd like to be proved wrong though, but I doubt big systems in production use filtering.

then with code like this foo() if $foo; why do you pay for a function call?

You don't, but I find that the added noise of the statement modifier is annoying. It's there to avoid paying the cost of the function call, but it extracts its own price on the overall readability of the program.

I also expressly declined to mention the -P switch. Are you aware of all the caveats that apply to its use? Check out perlrun. For me, having to jump through hoops to avoid $var =~ s/foo// would be a right hassle.

And yes, we're on the same wavelength: when I said "true macros", I meant true macros, not the toys that comes with a C compiler.

• another intruder with the mooring in the heart of the Perl

[reply]
[d/l]
[select]


Pathologically Eclectic Rubbish Lister
	PerlMonks