[IronPython] My takes on C Extensions for IronPython
lupus at ximian.com
Thu Oct 18 12:24:49 CEST 2007
I'll just reply here and try to summarize some things.
On 10/18/07 Seo Sanghyeon wrote:
> It's certainly more than 200 lines, and it's not completely trivial
> because some parts of Python/C API are C macros, not C functions.
> (Reference counting is the most important, but also getting
> type(=vtable) of Python objects and like.)
> The good news is that this part is already developed, debugged, and
> pretty much finished -- for Python 2.3 to 2.6, and for wide and narrow
> unicode builds of Python. Get it here (~ 1600 lines):
That code has each dllimport method spanning 5 lines of code.
I don't consider a cut and pasted [DllImport()] attribute as
something that is hard to write:)
So this complete work that covers 4 major versions of python
is less than 200 p/invokes. It's missing a few structure definitions.
Nothing an intern can't write in an afternoon.
My point still stands: interoperating with the C code is not an issue.
> I understand MC++ or Managed C++ is used to refer related
> technologies, but in the narrow sense it is a compiler that shipped
> with .NET 1.x which produced mix of managed and x86 code. I
> believe .NET 2.x compiler, i.e. C++/CLI is what is currently
Yes, Managed C++ referes to the old broken and already abandoned
technology, but it's sometimes used also to refer to the new C++/CLI
lanaguage, likely because C++/CLI is not a really good name:)
> It would be nice to be able to compile without Microsoft tools, but I
> don't think it's essential. If assembly compiled with C++/CLI /
> clr:pure can be made to run on Mono that's fine.
First, someone should investigate if clr:pure actually provides seamless
integration with C code. I doubt it works, but I'll wait for someone
using windows to confirm this.
The issue then is that, even if the above would work, the MS C++/CLI compiler
will emit code that depends on the windows ABI (specifically always
considering long to be 32 bits, they even put this in the standard, sigh).
What this means for people not familiar with low-level details, is that
such code is not portable and hence won't work on Linux 64 bit systems
(this is always assuming the interoperability with C code works at all
even on 32 bit systems). So, while it's not essential that this code be
built with non-Microsoft tools, only the MS tools are able to compile
that code and they compile it incorrectly (and as the C++/CLI standard
requires, sadly, so there is no chance this will be ever fixed).
> Also Mono page doesn't mention this, but GCC backend to emit CLI code
> *is* complete and working. It's available right now from GCC SVN. But
> it's yet another project, not Google Summer of Code attempts. This
> project is backed by STMicroelectronics, a big corporation, probably
> for its own use.
> Remember, Mono doesn't need to be the sole provider of non-Microsoft
> CLI tools. :) I believe GCC/CLI can be made to help this project.
See above for the portability issues: they'd have to either not follow
the standard or to produce non-working code. Also the gcc CLI backend
is not really complete and even if it were it doesn't mean that C++/CLI
would be any easier to implement on top of it.
My estimate is that C++/CLI on top of gcc will require at least 4-5
years, if someone implements it at all (there is not much demand for it,
there are the portability and standard issues I mentioned above and by
that time Mono will have an extension to semalessly dllimport C++ code,
lowering demand for C++/CLI even more).
In 4-5 years Microsoft itself will pull the plug on C++/CLI, so I think
basing a new design on it is a mistake.
Anyway, I'm not the one who's going to write the code, so more power to
people that will, I just wanted to make people aware that using
managed C++ or C++/CLI will prevent the sw to work on anything but
windows with the .net runtime.
lupus at debian.org debian/rules
lupus at ximian.com Monkeys do it better
More information about the Ironpython-users