Of course it's a hack though it's safe in current implementation.
It's possible that if we change core code then this hack will have to
be updated so such tricks should not be used by 3-rd party code.
In fact we can also add to HB_EXECMSG()
hb_stackBaseItem()->item.asSymbol.paramcnt =
hb_stackBaseItem()->item.asSymbol.paramdeclcnt = 0;
to keep the HVM stack clean and not confuse any code which can be
written to analyze the HVM stack contents. We are using two different
stack frames but the second one is inside parameters which belongs
to the 1-st one.
Hi,
Oh, yes. I've confused myself. These frames are overlapping, but not the
same! I forgot about HB_EXECMSG symbol and NIL.
But this approach
hb_itemCopy( hb_stackBaseItem(), pValue )
HB_VM_EXECUTE( pValue ); // Well, it lacks EG_NOFUNC check
seems to hack for my without additional function redirection support
from HVM.
Speed test for HashObject() class variable access:
FOR nI := 1 TO 10000000
nS += oObj:nNumber
NEXT
PRG error handler: 25.907 s
C error handler: 10.703 s
C with hb_stackAllocItem(): 9.797 s
Native object variable: 5.366 s
Loop overhead (nS+=1 loop): 1.875 s
Regards,
Mindaugas
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
