Re: [Libff-devel] Re: libff API

[Johann D. <de...@if...>]

Rodrigo Damazio wrote:
> Johann Deneux wrote:
> 
>> Rodrigo Damazio wrote:
>>
>>>
>>> Johann Deneux wrote:
>>>
>>>> On Sun, 17 Feb 2002, Rodrigo Damazio wrote:
>>>>
>>>>> interoperability, why couldn't other languages handle structs??
>>>>>
>>>>
>>>> I don't know if all languages have the notion of structures, and if 
>>>> they
>>>> do, their implementation may be binary-incompatible with C.
>>>> These are hypothetical issues, I don't know much about Perl, Python, 
>>>> Ruby
>>>> and other languages people like.
>>>> Another problem is that every time we touch a structure, every 
>>>> application using libff must be recompiled.
>>>> If we hide the structures, recompilation is only necessary when 
>>>> changing
>>>> the function prototypes.
>>>>
>>>   I get your point...how about using both ways?? Having the structs, 
>>> and if the calling language can't handle them directly, it can just 
>>> use the manipulation functions, whereas in C and similars which can 
>>> handle structs, it can be made a lot easier...or perhaps we even 
>>> should make this a C-only version and write wrappers for Perl and 
>>> other languages...I've seen a few libraries which do that...
>>>
>>
>> Ok. But then we have to design our structures very carefully, so that 
>> we hopefully do not need to change them later on. 
> 
> 
>    I was thinking...how much slower is it to use your method?? It

You have to put the parameters on the stack, make a function call, 
execute the body, store the result, return. That's several times slower 
than making a direct access to a structure.
But this is still ok. The second method would take a few nanoseconds, 
the first a few tens of nanoseconds. Unless you change these parameters 
very often (several millions of times per second), it's hardly going to 
be noticeable. Anyway, I don't think it's possible nor useful to update 
an effect more than 100 times a second.

> wouldn't imply a meaninful delay for a game, would it?? Perhaps we could 
> use that for changing parameters, and make some shortcut functions such 
> as to create an effect, already passing all the parameters in a single 
> function instead of making lots of individual calls...also functions for 
> copying blocks and the like...that should make it just as usable as 
> using structs...
> 

Yes, probably.
Should we have the notion of parameter blocks ? It looks a bit too 
hardware specific to me. But maybe I am exagerating.
I think we should not hesitate to experiment different approaches. We 
are only two to discuss these problems, and neither of us is very 
experienced in this area.
The best would be to start implementing something and try it out.



>        I see...ok, so we'll use the original way(returning the error 
> code)...I'll put all this in the header file and send it later tonight...

Yes, having some code at sight will help clarify and summarize what has 
been discussed.

-- 
Johann Deneux

 
______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif