CNI for C

[Richard Dale]

On Tuesday 13 April 2004 22:57, Tom Tromey wrote:
> >>>>> "Richard" == Richard Dale <Richard_Dale@tipitina.demon.co.uk> writes:
>
> Richard> Both java and C# use the language independent Smoke library.
>
> Richard> All 20000+ Qt/KDE method calls in the api are funneled to a
> Richard> single Invoke() call, in SmokeInvocation.cs:
>
> Richard> So the next thing to be done is to add code to look up the
> Richard> method to call in the Smoke runtime, then marshall the args
> Richard> in a Object[] array into the C++ types. Then call the C++
> Richard> method, and marshall the return value from C++ to C#.
>
> This is a cool approach, but I wonder about the performance of it.
Yes, I'm not expecting it to be fast - java gcj Proxies are always interpreted 
at present for instance. But AOP packages like Dynaop or Nanning do something 
similar with proxies, and I haven't read complaints about their performance. 

Perhaps using CNI instead of JNI would be the biggest speed up - JNI seems 
very slow. At least when everything goes through a single method you only 
have to optimise in one place. 

Dynamically looking up method selectors for a static language isn't obviously 
sensible either. The QtRuby and PerlQt bindings use method selector caches, 
so that once a method has been looked up it gets put in a hash where it can 
be retrieved quickly.

> One nice part of the "GDirect" approach is that some simple C calls
> will have no overhead at all, at least if we were to write a
> gcj-specific GDirect.  That is, the pointer in the method table would
> point directly at the C function.  (Of course whether this is an
> important optimization is unknown...)

On Thursday 08 April 2004 05:18, Tom Tromey wrote:
> Things get trickier if you want to wrap a C++ API, because then you
> need to understand name mangling, which is hard and non-portable.
> (You can always expose the mangled names, but that has other obvious
> problems.)

That's an advantage the Gnome guys have with a C api - I think the C++ name 
mangling problem would make this a non-starter for KDE C++. But then without 
some sort ofJNI or C++ style name mangling, I assume it's difficult to have 
overloaded methods in the java api.

-- Richard