1. Slight Problem...
- Posted by Al Getz <Xaxo at aol.com> Aug 11, 2003
- 368 views
Hello, There is a slight problem using 'define_c_func()' for use with virtual functions, and that is... YOU CANT *UNDEFINE* THEM !!!!!! Or did i miss something somewhere? Take care for now, Al
2. Re: Slight Problem...
- Posted by Robert Craig <rds at RapidEuphoria.com> Aug 12, 2003
- 363 views
Al Getz wrote: > There is a slight problem using 'define_c_func()' for use > with virtual functions, and that is... > > YOU CANT *UNDEFINE* THEM !!!!!! > > > > Or did i miss something somewhere? Why do you want to undefine a function? Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
3. Re: Slight Problem...
- Posted by Robert Craig <rds at RapidEuphoria.com> Aug 13, 2003
- 363 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