Hi Przemek,
bBlock := hb_macroCompile( "{||" + cExpr + "}" )
Nothing. Though, we've been talking about this expression: :)
bBlock := hb_macroCompile( cExpr )
other than that you have to type more characters. I don't know if
there is
a speed concern but the first expression is idiomatic for a
Clipper-head.
For me the hack-less function format looks much
cleaner. It's probably also a bit quicker and
Yes, hb_macroBlock() is faster. The difference depends on
macro body. For very simplt macros, f.e. ".T." it's:
empty loop overhead: 0.09
macro compilation: 2.44
hb_macroblock: 1.43
For more complex macros the difference is smaller of course
because the cost of macro compilation is the most significant
one.
Great!
generates slightly smaller code, and this way
This is not true. The final codeblock will contain
exactly the same PCODE in both cases.
By smaller I've only meant the caller side. It
will be smaller because "{||}" string will not
have to be used each time. Admittedly this is
quite marginal.
you can very easily identify where your code
uses macro compilation.
But you loose PROCNAME() information about the place where
macro was compiled. It will be attached to hb_macroBlock()
function. For some people it can be important information.
Good to know. Here I meant that I can much easily
grep for hb_macroBlock() than for '&', it's also
visually clearer/cleaner.
Maybe this won't qualify my as a Clipper-head,
but I always had a dislike for the '&' operator.
I'm currently hiding it with an STRCOMPILE()
macro, which does the same as hb_macroCompile().
So for you hb_macroBlock() will be only faster version of your
own function STRCOMPILE(). You will not lost any additional
information attached to compiled macro because you do not have
it now when you use STRCOMPILE().
OK, I'll commit this function ASAP.
Very nice, thanks a lot :)
[ Just some food for thought: I have one place where
I had to write my own little macro compiler, because
I'm compiling macros coming from external files (namely
printing templates). It would be much better to use
the Harbour macro compiling facilities instead of my
bad attempt, but my concern is security and app integrity.
Meaning, if I'd just use simple Harbour macro evaluation,
some uncontrolled scripts could just as well call any
functions in my app, read any PUBLICs, or even fiddle
with the open tables, use file IO. What would be needed
here is probably some kind of sandboxing facility, where
given macro would only be able to call a given set of
functions, or some other ways to set its boundaries.
Pretty far reaching I guess, but the problem is there. ]
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
