John Bokma wrote:
Ethan Furman <et...@stoneleaf.us> writes:
John Bokma wrote:
Michael Torrie <torr...@gmail.com> writes:
On 08/01/2010 07:09 PM, John Bokma wrote:
One thing that comes to mind is that it's much easier to
distribute C libraries than C++ libraries.
In the beginning of C++ there were programs that just converted C++ to C
(frontends). At least that is how the C++ compiler Acorn sold worked.
So I don't think your argument was much true back then.
No, he is still right. Each C++ implementation did name mangling
differently leading to "C" libraries that had incompatible names and
signatures. Also each frontend could have generated incompatible
vtables and other C++ structures. So C code generated by one C++
frontend could not easily call C code generated by another C++ frontend.
So the same arguments that are made about C++ now were just as valid
back then when C++ was merely a fancy preprocessor.
See my other post: I understand that two C++ preprocessors can't call
each others generated code, but if one uses C++ and knows that one can
only use shared C libraries on target systems, and not C++ libraries
that might be present (or more likely not: C++ was new in those days).
So if Python were written in C++, and an extension was written in C++,
how could the two call each other?
Via C.
Huh? Presumably Python itself is not a library, and the extension may
not be a library, at some point they will have different name mangling
schemes... are you suggesting that after going through the effort if
writing all this in C++ you would then have to write a wrapper in C so
the two could talk to each other?
~Ethan~
--
http://mail.python.org/mailman/listinfo/python-list
