CNI for C

Thu Apr 8 11:58:00 GMT 2004

On Wednesday 07 April 2004 20:45, Tom Tromey wrote:
> Geert> What I do know is that the easy C integration is making Mono and C#
> Geert> gaining more and more momentum, while a perfectly functional
> Geert> free-from-patents technology exist with GCJ. As I see it, easy
> Geert> integration with C is a minor addition to what is already a very
> stable Geert> and comprehensive platform.
Personally I think creating a binding assuming a one-to-one correspondance 
between java or C# methods calls onto the method calls of the api being 
wrapped isn't the best way. I am using MarshallByRefObjects or 
ContextBoundObjects (they're much the same as java Dynamic proxies) for the 
Qt#/Kimono C# bindings, and the entire api is constructed in terms of those. 
Both java and C# use the language independent Smoke library.
I've attached a couple of sample C# files with the Proxy calls. Here is how 
the Proxy is created in QFont.cs:
 protected Object _interceptor = null;
 ...
 protected void CreateQFontProxy() {
 SmokeInvocation realProxy = new 
SmokeInvocation(typeof(QFont), this);
 _interceptor = (QFont) 
realProxy.GetTransparentProxy();
 }
 private QFont proxyQFont() {
 return (QFont) _interceptor;
 }
 ...
And a method call looks like this:
 public void SetPixelSize(int arg1) {
 proxyQFont().SetPixelSize(arg1);
 }
All 20000+ Qt/KDE method calls in the api are funneled to a single Invoke() 
call, in SmokeInvocation.cs:
 public override IMessage Invoke(IMessage myMessage) {
 Console.WriteLine("MyProxy 'Invoke method' 
Called...");
 if (myMessage is IMethodCallMessage) {
 Console.WriteLine("IMethodCallMessage");
 }
 if (myMessage is IMethodReturnMessage) {
 Console.WriteLine("IMethodReturnMessage");
 }
 if (myMessage is IConstructionCallMessage) { 
 } 
 }
So the next thing to be done is to add code to look up the method to call in 
the Smoke runtime, then marshall the args in a Object[] array into the C++ 
types. Then call the C++ method, and marshall the return value from C++ to 
C#.
I've attached the a version of QFont.cs which was part of the older Qt# 
bindings, and it used p/invoke. Finally, I've attached QFont.java which shows 
how the same technique looks using java. A few weeks ago I posted a similar 
description of the java ones on java@gcc.gnu.org.
It's my understanding of this link that MS intends you to construct components 
this way if you want to take advantage of Aspect Oriented features in you 
language binding:
http://msdn.microsoft.com/msdnmag/issues/03/03/ContextsinNET/
You can't do that fancy stuff with just straight calls to p/invoke. Maybe you 
could use libffi inside Proxy.invoke() to dynamically look up Gnome C 
methods.
> Yes, I think we've been quite bad at pushing our technology. Are gcj
> and Java perfect? No, of course not. But I think they are attractive
> along many axes: there is a lot of free Java code, including
> development environments and other "big" things; gcj is quite mature,
> has good performance, and is not only extremely portable but in fact
> very widely ported.
>> So, how can we get the word out more effectively? I don't know. I
> think we need some evangelists in the Gnome world (and other
> communities) to help out. And I think we need to listen to those
> folks when they talk about what it is they need.
>> Considerations like these are why I think java-gnome is such an
> important project. Other bindings would also be useful, to make it
> easier to write Gnome-ish applications.
>> Another complaint I hear sometimes is that our release cycle is too
> slow, since we're tied to gcc. We could probably start doing more
> frequent libgcj releases if that would help.
I'm very keen on using gcj with the KDE Koala java bindings. For me the FOSDEM 
talk about gcj was my favourite - I don't think people realise how impressive 
the gcj/gij environment is - and I learned a lot - thanks! We've just about 
finished getting the kde java bindings working as debian packages which 
should make them more widely available and easy to use.
-- Richard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: QFont.cs
Type: text/x-c++src
Size: 9482 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/java/attachments/20040408/68e00c51/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: QFont.java
Type: text/x-java
Size: 12847 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/java/attachments/20040408/68e00c51/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SmokeInvocation.cs
Type: text/x-c++src
Size: 746 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/java/attachments/20040408/68e00c51/attachment-0002.bin>