Re: Re: Bindings for .NET languages

David Abrahams wrote:
> Patrick Hartling <[email protected]> writes:
> 
> 
>>I have been trying to follow the discussions regarding the refactoring
>>of Boost.Python and Luabind because the issue of multi-language
>>interoperability ties in very heavily with my Ph.D. research.  
> 
> 
> Welcome!
> 
> 
>>A lot of the discussion is way over my head right now, but I hope
>>that with time I'll be able to garner more information from the list
>>archives and from future posts.  I have checked out the langbindings
>>branch of the Boost source tree with the intent of learning how all
>>the magic happens, and I am pretty sure I have a long way to go
>>before I'll understand the code.
>>
>>In any event, I am curious as to how the design of the new Boost
>>language bindings code is being generalized for languages besides
>>Python and Lua.  From some of the early discussions back in June, I
>>got the impression that interpreted languages were the focus of the
>>work, 
> 
> 
> Well, dynamically-typed languages, anyway.

Okay, well, that pretty much eliminates .NET languages since the 
underlying common language infrastructure (CLI) relies on static typing.

>>and I am wondering if that is in fact the case.  Does that have any
>>specific impact on the design
> 
> 
> Not that I know of; we're not generating any bytecode, for example.
> 
> 
>>or does it relate more to the fact that interpreted languages often
>>have C APIs for embedding the interpreter in natively compiled code?
> 
> 
> More likely that.  Of course, the two cases we're trying to handle,
> Python and Lua, have a lot in common, and we haven't been looking
> around for additional ways to complicate... er, generalize it.

I understand.  :)  That's probably a good plan.

>>All of this boils down to an interest I have in making
>>native/unmanaged C++ code (relatively?) easily accessible by C# and
>>other .NET languages and vice versa.  I really like what
>>Boost.Python offers in terms of exposing C++ for extension and use
>>by Python code, and I like what it offers in simplifying the
>>Python/C API.  It's something I want very much to see replicated for
>>.NET.
> 
> 
> Does .NET have a [nasty] C API too?

That's where my knowledge is a little fuzzy right now.  Of the three CLI 
implementations I have looked into (Microsoft's .NET CLR, Ximian's Mono, 
and GNU's Portable.NET), Mono and the CLR have different C APIs.  I 
haven't found documentation on Portable.NET's yet, though I assume there 
must be something in the works.  So, there is the strong possibility 
that there will be different C interfaces to the VM depending on which 
implementation is used.

The thing I have realized in the last few days is that a 
Boost.Python-esque technique may not be right at all for my needs 
because the CLI does not have built-in features for extension by native 
code.  That is, for the import of a module to work in C# or VB.NET or 
whatever, the module has to be a .NET assembly containing bytecode, not 
a natively compiled DLL.  There are no hooks in the runtime for 
extension by native code; programmers have to write it all themselves 
using the Platform Invocation Services.  It's a reasonbly nice interface 
(far cleaner than JNI, for example), but just like the Java VM, calls 
into native code require programmer intervention.

Because of this, I am now planning to write a Pyste-like code generator 
based on GCC-XML.  I am investigating what is repetitive about writing 
the bridge code between C# and C/C++ so that I can generate as much of 
it as possible.  Code has to be generated in both languages for 
everything to work.  While I haven't started writing any of the 
generator code yet, I have had pretty decent success these past few days 
with getting C# talking to C++ on Linux and Windows.  Certainly, the 
work I have done using Boost.Python to expose the same C++ code is much 
farther along and much nicer looking, but my hope is to hide the C# 
ugliness in the generated code.

>>For the last 8 or 9 months, I have been trying to keep track of
>>efforts to make C# talk to unmanaged C++ in roughly the same manner
>>that Python and C++ can talk via Boost.Python.  Unfortunately, the
>>projects that held the most promise at the beginning of the year
>>seemed to run out of steam after only a couple of months.  There is
>>SWIG's support for C#, but I am not sure that will meet my needs
>>correctly.  So, I am contemplating writing something similar to
>>Boost.Python for .NET, though I am not yet sure how--or even if--it
>>will work.  Has anyone here given any thought to this?
> 
> 
> Only in the most abstract sense.
> 
> 
>>There are no doubt dozens of issues, big and little, that I need to
>>investigate and evaluate before proceeding.  Before I go too far, I
>>want to be sure I don't duplicate anyone else's efforts, and I want
>>to be sure I start from the right foundation if I do write the code
>>myself.
> 
> 
> If you can evaluate how similar the prolems of binding C# and C++ are
> to those of binding Python and C++, I think you should be able to
> tell whether it's worth participating in the langbinding work (and
> trying to get us to accomodate C#) or going off on your own.

Considering all of the above, I think that a tool similar to 
Boost.Python would be best suited for abstracting the C API used to 
embed a .NET runtime in natively compiled code.  Boost.Python does a 
fantastic job of making the Python/C API easy to use (and largely 
invisible).  What I have seen so far of the Mono API reminds me of 
Python/C, so in the long run, I think what I will do is try to apply the 
design of Boost.Python to an abstraction layer for the various .NET C 
APIs.  Right now, however, the code generation tool is my near-term goal.

  -Patrick


-- 
Patrick L. Hartling                     | Research Assistant, VRAC
[email protected]                | 2624 Howe Hall: 1.515.294.4916
http://www.137.org/patrick/             | http://www.vrac.iastate.edu/



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf