Why is python not written in C++ ?
in [Python]
|
From: Roy Smith on 6 Aug 2010 07:39 In article <mailman.1666.1281075732.1673.python-list(a)python.org>, David Cournapeau <cournape(a)gmail.com> wrote: > > Yes, there are a few corner cases where valid C syntax has different > > semantics in C and C++. But, they are very few. Calling C++ a superset > > of C is essentially correct. > > This is only true if you limit yourself to C89 (as python seems to > do). If you start using C99 (and lot of people do, if only because > they don't realize it because gcc is quite relax about it), then > almost no non trivial C code is valid C++ in my experience. I'm not following you. If anything, C99 makes C closer to C++. Can you give me some examples of valid C99 which is not also valid C++?
From: David Cournapeau on 6 Aug 2010 09:55 On Fri, Aug 6, 2010 at 8:39 PM, Roy Smith <roy(a)panix.com> wrote: > In article <mailman.1666.1281075732.1673.python-list(a)python.org>, >  David Cournapeau <cournape(a)gmail.com> wrote: > >> > Yes, there are a few corner cases where valid C syntax has different >> > semantics in C and C++.  But, they are very few.  Calling C++ a superset >> > of C is essentially correct. >> >> This is only true if you limit yourself to C89 (as python seems to >> do). If  you start using C99 (and lot of people do, if only because >> they don't realize it because gcc is quite relax about it), then >> almost no non trivial C code is valid C++ in my experience. > > I'm not following you.  If anything, C99 makes C closer to C++.  Can you > give me some examples of valid C99 which is not also valid C++? variable size array, the meaning of inline, etc... In addition to int f(void) vs int f(), legality vs illegality of p = malloc(n);, type of enum, keyword incompatibility (new, delete, etc...) which are already there in C89. I have yet seen a project where you could build C code with a C++ compiler - the only ones I know are specifically designed that way and it is painful. David
From: Lawrence D'Oliveiro on 6 Aug 2010 22:05 In message <mailman.1681.1281102958.1673.python-list(a)python.org>, David Cournapeau wrote: > I have yet seen a project where you could build C code with a C++ > compiler - the only ones I know are specifically designed that way and > it is painful. I seem to recall a FAQ entry, might have been on kernelnewbies.org, asking why the Linux kernel wasn't written in C++. The answer explained that at one time there was an experiment to make the kernel compilable with a C++ compiler, without actually using any C++ features. The result: they lost about 10% in speed. That was enough to put the kernel developers off taking the experiment any further.
From: Gregory Ewing on 7 Aug 2010 03:33 Lawrence D'Oliveiro wrote: > at one > time there was an experiment to make the kernel compilable with a C++ > compiler, without actually using any C++ features. The result: they lost > about 10% in speed. That was enough to put the kernel developers off taking > the experiment any further. FWIW, certain parts of the Darwin kernel are written in a carefully-selected subset of C++. So Apple evidently think that it makes sense to use some C++ in a Unix kernel under some circumstances. -- Greg
From: Albert van der Horst on 7 Aug 2010 10:48
In article <roy-30C94B.20362001082010(a)news.panix.com>, Roy Smith <roy(a)panix.com> wrote: >In article <4c55fe82$0$9111$426a34cc(a)news.free.fr>, > candide <candide(a)free.invalid> wrote: > >> Python is an object oriented langage (OOL). The Python main >> implementation is written in pure and "old" C90. Is it for historical >> reasons? >> >> C is not an OOL and C++ strongly is. I wonder if it wouldn't be more >> suitable to implement an OOL with another one. > >One thing that comes to mind is that it's much easier to distribute C >libraries than C++ libraries. > >If I compile a main program with one C compiler and you compile a >dynamically loaded library with another C compiler on the same box, the >odds are pretty good they'll interoperate without any problems. > >Not at all so with C++ compilers. The linkage is *way* more >complicated. Not just how the two compilers do name mangling, but how >they handle exceptions, RVO, and a zillion other details. Pretty much >the only way to make it work is to compile everything with exactly the >same compiler. That would make it pretty close to impossible for people >to take a Python core distribution and add their own extension modules >to it. We had a similar discussion on comp.lang.forth. The bottom line is that to implement a programming language you want to use a simpler programming language, not a more complicated one. Then there is a secondary requirement, that language must allow sufficient access to low level features to allow decent performance. A third aspect is that Linux/Unices as well as Windows assume OS interaction in terms of c-libraries. Any intermediary is inconvenient at least. Or in one catch phrase: " To implement a programming language you need a high level assembler like C." (We went on whether Forth would be a suitable high level assembler for Haskell. It would beat C++ -- not C -- for implementing Python, that much I'm sure.) Undoubtedly C is the right choice to implement Python. Groetjes Albert -- -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert(a)spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst |