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 > discussed. 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. > http://gcc.gnu.org/projects/cli.html > > 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. Happy hacking! lupus -- ----------------------------------------------------------------- [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better _______________________________________________ Users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
