On Wed, Jul 7, 2010 at 12:26 AM, Thomas Jollans <tho...@jollans.com> wrote: > On 07/07/2010 12:08 AM, David Cournapeau wrote: >> On Tue, Jul 6, 2010 at 6:00 PM, Alf P. Steinbach /Usenet >> <alf.p.steinbach+use...@gmail.com> wrote: >>> There is no *technical* problem creating a compiler-independent C/C++ >>> language binding. >> >> It is quite hard, though, or would require changes in the API to be >> entirely safe. When I asked the question a few months ago to see if we >> could fix those issues once and for all for numpy, the most common >> answer I got was to pass all the related functions in a structure: >> http://stackoverflow.com/questions/1052491/c-runtime-objects-dll-boundaries. >> >> The problem is not compiler, but really C runtimes. By itself, the >> issues are not windows specific (using malloc from one C library and >> one free from another one is trouble everywhere), but on windows: >> - multiple C runtimes are *very* common on windows > > I'm also rather sure that it's pretty much impossible to have multiple C > libraries in one process on UNIX, but it's obviously quite possible on > Windows.
I am not sure why you think it is not possible. It is rare, though. > >> - many things which are runtime independent on unix are not on >> windows (file descriptor: AFAIK, a file descriptor as returned from >> open can be dealt with in any C runtime on unix) > > Are you telling me that file descriptors (it's a flippin int!) can't be > passed around universally on Windows?? Yes. The reason why it does not work on windows is because file descriptor are not "native": in every unix I have heard of, file descriptor are indexes in a table of the process "structure", hence can be shared freely (no dependency on the C runtime structures). On windows, I have heard they are emulated (the native one is the win32 file handle). David -- http://mail.python.org/mailman/listinfo/python-list
