Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
in [Python]
|
Prev: Python GUI for C program [was: ]
Next: Download Microsoft C/C++ compiler for use with Python 2.6/2.7ASAP
From: Thomas Jollans on 6 Jul 2010 18:26 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(a)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
From: Martin v. Loewis on 6 Jul 2010 18:38 >> - 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?? There are really three things of concern here: a) operating system file handles, of type HANDLE (which is an unsigned 32-bit value); they are not contiguous, and stdin/stdout/stderr may have arbitrary numbers b) C runtime file handles, of type int. They are contiguous, and stdin/stdout/stderr are 0/1/2. c) C FILE*. OS handles can be passed around freely within a process; across processes, they lose their meaning It's the data of types b) and c) that cause problems: the CRT handle 4 means different things depending on what copy of the CRT is interpreting it. It's worse with FILE*: passing a FILE* of one CRT to the fread() implementation of a different CRT will cause a segfault. > 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. Since when is CPython managed code? Regards, Martin
From: sturlamolden on 6 Jul 2010 18:41 On 6 Jul, 21:52, casevh <cas...(a)gmail.com> wrote: > The original version of the Windows 7 SDK includes the command line > version of the VS 2008 amd64 compiler. I've used it compile MPIR and > GMPY successfully. The GMPY source includes a text file describing the > build process using the SDK tools. It should also be mentioned that the Windows 7 SDK includes vcbuild.exe, so it can be used to compile Visual Studio 2008 projects (I'm going to try Python).
From: Martin P. Hellwig on 6 Jul 2010 18:41 On 07/06/10 21:19, sturlamolden wrote: > On 6 Jul, 21:49, Christian Heimes<li...(a)cheimes.de> wrote: > >> I agree, the situation isn't ideal. I see if I can get in contact with >> Microsoft's open source team. Perhaps they can keep the download link to >> VS 2008 EE working. > > It seems the MSDN subscription required to get VS 2008 costs one > dollar less than $1200. So it does not fit within everyone's budget. > > Take in the cost of your operating system, and the ones you want to test against, perhaps you also like to use office. Although I am not a windows developer per se, I do use windows XP, 2000 2003, 2008, Vista and 7 for testing. I also use office for all those clients who think that this is the only format. 1200 USD is actually quite cheap, but then again I didn't pay that because I am either always been in an academic license (about 70 EUR a year) or like now in a program for businesses who just start up (free with my bank as supporting agent). When this 3 year subscription is over I fall anyway in the cheaper renewals and if not I am sure that there is some other brand new scheme like they did for the last decade. Anyway, if you want to provide tools for platforms that are closed source that means that there are costs for the developer and the client. Although the cost for MS platforms are reasonable (as a developer and you know you way around, that means go a couple of times to those free MS events and it is quite likely you get an MSDN subscription for being such a good loyal puppy), there are always costs. If you don't like that better convince your target audience about an open source operating system, whichever that may be. -- mph
From: sturlamolden on 6 Jul 2010 18:57
On 7 Jul, 00:41, sturlamolden <sturlamol...(a)yahoo.no> wrote: > It should also be mentioned that the Windows 7 SDK includes > vcbuild.exe, so it can be used to compile Visual Studio 2008 projects > (I'm going to try Python). Not sure why I forgot to mention, but we can (or even should?) use CMake to generate these project files. We don't need Visual Studio for that. |