OpenEuphoria

Re: Slight Problem...

• Posted by Robert Craig <rds at RapidEuphoria.com> Aug 13, 2003
• 364 views

Andy Serpa wrote:
> In my personal wrapper for Berkeley DB, each virtual function pointer is 
> an offset of a handle to a database object.  These objects are created 
> and destroyed all the time.  In other words, you don't determine the 
> pointer until just before you call the function, and likely you'll never 
> use that particular pointer ever again.
> 
> With fptr.e, I just peek a certain offset from the handle to get the 
> pointer, and then call the function.  I could now do this in pure 
> Euphoria, but I'd have to define the function before each & every call, 
> which presumably uses up permanent memory somewhere.  Maybe you could 
> refine that enhancement so we can call functions by pointer without 
> defining them first -- just pass the pointer...

Al Getz wrote:
> Here's what i'm looking at: ...
 > [example where it might be useful
 > to undefine C/machine functions]

It's true that define_c_func/proc will allocate a bit
of space each time you call them. Basically just enough
for the routine name and the parameter type information.

(If you call the Euphoria routine_id() function
many times with the same identifier, you will get the
same routine id returned, with no extra space allocated.)

Thanks both of you for pointing this out.
I think you are both doing somewhat unusual things
and I hope Matt's fptr.e will help for now.

I'll consider what to do, if anything, about freeing the
information that define_c_func/proc collects.
Normally you'd have to link with tens of thousands of
different C/asm routines before it would eat up
a significant amount of memory. But both of you have
special cases that I'll have to consider. Even with
an undefine function, the time overhead of defining/undefining
might be too much for calling a small fast routine.

Regards,
    Rob Craig
    Rapid Deployment Software
    http://www.RapidEuphoria.com