1. Slight Problem...

Hello,

There is a slight problem using 'define_c_func()' for use
with virtual functions, and that is...

YOU CANT *UNDEFINE* THEM !!!!!!

smile

Or did i miss something somewhere?

Take care for now,
Al

new topic     » topic index » view message » categorize

2. Re: Slight Problem...

Al Getz wrote:
> There is a slight problem using 'define_c_func()' for use
> with virtual functions, and that is...
> 
> YOU CANT *UNDEFINE* THEM !!!!!!
> 
> smile
> 
> Or did i miss something somewhere?

Why do you want to undefine a function?

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

new topic     » goto parent     » topic index » view message » categorize

3. Re: Slight Problem...

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

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu