Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

[Thomas Jollans]

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+usenet at 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.

>  - 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??

Now Windows programming *really* scares me.

>  - the MS standard C library is clearly not a priority: win32 specific
> objects can be shared across runtimes, but standard C rarely can.

And, as has already been said in this thread, this does not concern the
.net developer, or any developer that sticks to managed code, be it
.net, CPython, or something-else based.

>  - the recent manifest concept (which can improve or worsen the
> issues)  is incredibly convoluted, and poorly documented (they expect
> you to use MS tool and not to try to understand how it works).


Cheers,

Thomas