F*******i
发帖数: 190 | 1 Sorry can not input chinse.
Play with cython and looks like it can mix c/c++/python quite well.
For example, the xxx.so file generated by g++ could be import by python
flawlessly.
I am wondering whether it is because Cpython implementation always put
the extern "C" to its source, so that the name mangling could be correct
even if mixed with c++?
thanks! |
S*A
发帖数: 7142 | 2 I haven't look at it myself in that level of detail,
but it has to be using extern "C". Otherwise there is no way
to escape of the symbol renaming. Actually, python header file
use extern "C". So your C++ file has to export C like
function to match the function pointer prototype.
BTW, C++ is not a strictly super set of C. Some C99 code
can't can't compile in C++, even for some header file.
So C++ and C99 are kind of like two different language.
【在 F*******i 的大作中提到】
: Sorry can not input chinse.
: Play with cython and looks like it can mix c/c++/python quite well.
: For example, the xxx.so file generated by g++ could be import by python
: flawlessly.
: I am wondering whether it is because Cpython implementation always put
: the extern "C" to its source, so that the name mangling could be correct
: even if mixed with c++?
: thanks!
|
r****t
发帖数: 10904 | 3 non-question
【在 F*******i 的大作中提到】
: Sorry can not input chinse.
: Play with cython and looks like it can mix c/c++/python quite well.
: For example, the xxx.so file generated by g++ could be import by python
: flawlessly.
: I am wondering whether it is because Cpython implementation always put
: the extern "C" to its source, so that the name mangling could be correct
: even if mixed with c++?
: thanks!
|
r****t
发帖数: 10904 | 4 C99 基本没啥地方用吧。
【在 S*A 的大作中提到】
: I haven't look at it myself in that level of detail,
: but it has to be using extern "C". Otherwise there is no way
: to escape of the symbol renaming. Actually, python header file
: use extern "C". So your C++ file has to export C like
: function to match the function pointer prototype.
: BTW, C++ is not a strictly super set of C. Some C99 code
: can't can't compile in C++, even for some header file.
: So C++ and C99 are kind of like two different language.
|
S*A
发帖数: 7142 | 5 我 faint 到死。 kernel 就大量使用。
【在 r****t 的大作中提到】
: C99 基本没啥地方用吧。
|
F*******i
发帖数: 190 | 6 thanks!
【在 S*A 的大作中提到】
: I haven't look at it myself in that level of detail,
: but it has to be using extern "C". Otherwise there is no way
: to escape of the symbol renaming. Actually, python header file
: use extern "C". So your C++ file has to export C like
: function to match the function pointer prototype.
: BTW, C++ is not a strictly super set of C. Some C99 code
: can't can't compile in C++, even for some header file.
: So C++ and C99 are kind of like two different language.
|
F*******i
发帖数: 190 | 7 thanks
【在 r****t 的大作中提到】
: non-question
|
r*****z
发帖数: 906 | 8 C99在标准化的过程中规范了很多常见的编译器扩展，而kernel大量使用的是这些扩展。
标准化后的东西和这些扩展在想法上是一致的，但是在语法细节上并不相同。所以不能
说kernel大量使用C99特性
实际上，现在C99挺尴尬的。由于现在绝大多数C编译器其实是以C++编译器为核心任务，
C99特性的实现始终不是头等任务。
【在 S*A 的大作中提到】
: 我 faint 到死。 kernel 就大量使用。
|
N****w
发帖数: 21578 | 9 C++ 真是个垃圾语言
把那些乱糟糟的绕来绕去的东西去掉
会好很多
展。
务，
【在 r*****z 的大作中提到】
: C99在标准化的过程中规范了很多常见的编译器扩展，而kernel大量使用的是这些扩展。
: 标准化后的东西和这些扩展在想法上是一致的，但是在语法细节上并不相同。所以不能
: 说kernel大量使用C99特性
: 实际上，现在C99挺尴尬的。由于现在绝大多数C编译器其实是以C++编译器为核心任务，
: C99特性的实现始终不是头等任务。
|
S*A
发帖数: 7142 | 10
kernel 就是大量使用 C99 的特性和 GNU Extension，这两个都有用。
你看几乎所有的 structure initialization 都是 C99 的。当然不是
每一个 C99 feature 都用上了，C99 还是非常普遍的。我懒得一个一个数了。
务，
就是 VC 始终没有实现 C99 的东西，拖后腿。其他编译器都向 gcc 看齐，
有用的 C99 还是支持不少的。gcc 吧 c++ 和 c 分开两个编译器是对的。
我恰恰非常喜欢 C99 的特性，觉得不支持 C99 的不是好的 compiler.
【在 r*****z 的大作中提到】
: C99在标准化的过程中规范了很多常见的编译器扩展，而kernel大量使用的是这些扩展。
: 标准化后的东西和这些扩展在想法上是一致的，但是在语法细节上并不相同。所以不能
: 说kernel大量使用C99特性
: 实际上，现在C99挺尴尬的。由于现在绝大多数C编译器其实是以C++编译器为核心任务，
: C99特性的实现始终不是头等任务。
|
|
|
s****n
发帖数: 786 | 11 C++的初衷是为了提高程序员的门槛和收入，现在会C#的满大街都是，真是世事难料。
【在 N****w 的大作中提到】
: C++ 真是个垃圾语言
: 把那些乱糟糟的绕来绕去的东西去掉
: 会好很多
:
: 展。
: 务，
|
s****n
发帖数: 786 | 12 GNU Extension 并不是C99的一部分，kernel用没问题，应用程序应该有portable的长
远考虑。
C99是很好的方向，可惜gcc也没完全实现，其他的就更差，C现在真像进入老年了。
【在 S*A 的大作中提到】
:
: kernel 就是大量使用 C99 的特性和 GNU Extension，这两个都有用。
: 你看几乎所有的 structure initialization 都是 C99 的。当然不是
: 每一个 C99 feature 都用上了，C99 还是非常普遍的。我懒得一个一个数了。
: 务，
: 就是 VC 始终没有实现 C99 的东西，拖后腿。其他编译器都向 gcc 看齐，
: 有用的 C99 还是支持不少的。gcc 吧 c++ 和 c 分开两个编译器是对的。
: 我恰恰非常喜欢 C99 的特性，觉得不支持 C99 的不是好的 compiler.
|
s******c
发帖数: 1920 | 13 haha
想起来昨天看到的Linus骂C++的post
不能
【在 N****w 的大作中提到】
: C++ 真是个垃圾语言
: 把那些乱糟糟的绕来绕去的东西去掉
: 会好很多
:
: 展。
: 务，
|
s*******n
发帖数: 2828 | 14 可惜很多业界的标准语言
【在 s******c 的大作中提到】
: haha
: 想起来昨天看到的Linus骂C++的post
:
: 不能
|
S*A
发帖数: 7142 | 15
gcc 是最 portable 的 compiler 了。用 gcc 就是非常 portable 了。
只有一个例外就是 MS. C 没有 C++ 那些 crazy renaming. 用 ming
把 C code 编译好和 MS 的 UI 部分链接就是了。
这个是陈年老帐了，C compiler 部分该实现的都实现了。剩下一些就是
Library 的改动超出 gcc 的控制范围的。 gcc 部分已经没有什么剩下
来的了。
【在 s****n 的大作中提到】
: GNU Extension 并不是C99的一部分，kernel用没问题，应用程序应该有portable的长
: 远考虑。
: C99是很好的方向，可惜gcc也没完全实现，其他的就更差，C现在真像进入老年了。
|
r*****z
发帖数: 906 | 16
Flexible array member vs Zero-length array
【在 S*A 的大作中提到】
:
: gcc 是最 portable 的 compiler 了。用 gcc 就是非常 portable 了。
: 只有一个例外就是 MS. C 没有 C++ 那些 crazy renaming. 用 ming
: 把 C code 编译好和 MS 的 UI 部分链接就是了。
: 这个是陈年老帐了，C compiler 部分该实现的都实现了。剩下一些就是
: Library 的改动超出 gcc 的控制范围的。 gcc 部分已经没有什么剩下
: 来的了。
|
k*****r
发帖数: 21039 | 17 aglee
【在 N****w 的大作中提到】
: C++ 真是个垃圾语言
: 把那些乱糟糟的绕来绕去的东西去掉
: 会好很多
:
: 展。
: 务，
|
