昨晚有个朋友问我关于在C中调用C++库的问题,今天午餐后,因为脖子痛的厉害而没有加入到咱们组的“天天一战”的行列中去,因此正好将C和C++之间的库调用关系作个总结。ios
1.extern "C"的理解:
不少人认为"C"表示的C语言,实际并不是如此,"C"表示的是一种连接约定,只是因C和C++语言之间的密切关系而在它们之间更多的应用而已。实际上Fortran和汇编语言也经常使用,由于它们也正好符合C实现的约定。
extern "C"指令描述的是一种连接约定,它并不影响调用函数的定义,即时作了该声明,对函数类型的检查和参数转换仍要遵循C++的标准,而不是C。web
2.extern "C"的做用:
不一样的语言连接性是不一样的,那么也决定了它们编译后的连接符号的不一样,好比一个函数void fun(double d),C语言会把它编译成相似_fun这样的符号,C连接器只要找到该函数符号就能够连接成功,它假设参数类型信息是正确的。而C++会把这个函数编译成相似_fun_double或_xxx_funDxxx这样的符号,在符号上增长了类型信息,这也是C++能够实现重载的缘由。
那么,对于用C编译器编译成的库,用C++直接连接势必会出现不能识别符号的问题,是的,须要extern "C"的时刻来了,它就是干这个用的。extern "C" 的做用就是让编译器知道要以C语言的方式编译和链接封装函数。函数
3.在C++中调用C库的例子:
1).作一个C动态库:
spa
编译并copy到系统库目录下(也能够本身定义库目录,man ldconfig):
[root@coredump test]# gcc --shared -o libhello.so hello.c
[root@coredump test]# cp libhello.so /lib/
2).写个C++程序去调用它:
.net
编译并运行:
[root@coredump test]# g++ test.cpp -o test -lhello
[root@coredump test]# ./test
hello
[root@coredump test]#
3).__cplusplus宏的条件编译:
为何要加这个条件编译呢?小沈阳有话:小妹,这是为何呢?
由于这种技术也可能会用在由C头文件产生出的C++文件中,这样使用是为了创建起公共的C和C++文件,也就是保证当这个文件被用作C文件编译时,能够去掉C++结构,也就是说,extern "C"语法在C编译环境下是不容许的。
好比:将上面的test.cpp改名为test.c,将头文件改成stdio.h,将条件编译去掉,再用gcc编译就能够看到效果。而即便作了上面的修改,若是用g++编译就能够正常使用,这就是我上面说的“公共的C和C++文件”的意思。orm
4.C调用C++库:
C++调用C库看上去也不是那么困难,由于C++自己就有向前(向C)兼容的特性,再加上纯自然的extern "C"约定,使得一切都是那么天然。而让C调用C++的库彷佛就没那么容易,不过也不是不能够的。
说到这里我得休息一下,大中午的,出去抽根烟先,不过我也相信若是你不知道答案,看到这里的时候确定在处处找板砖,巴不得敲开个人脑袋子。我能理解,我也习惯了,我有个学姐一看到我第一反应就是扔出一块砖头先!
言归正传,仍是要借助这纯自然的extern "C"。对象
1)作一个C++库:
接口
编译并copy到系统库目录下:
[root@coredump test]# g++ --shared -o libworld.so world.cpp
[root@coredump test]# cp libworld.so /lib/
2)作一个中间接口库,对C++库进行二次封装:
ci
其中方法m_world即为libworld库中world方法的二次封装,编译并copy到系统库目录下:
[root@coredump test]# g++ --shared -o libmid.so mid.cpp -lworld
[root@coredump test]# cp libmid.so /lib/
3).C程序经过连接二次接口库去调用C++库:
get
编译并运行:[root@coredump test]# gcc test.c -l mid -o test[root@coredump test]# ./testworld[root@coredump test]#注:若是对于C++库中含有类的,能够在二次接口函数中生成临时对象来调用对应的功能函数,固然要根据实际状况来定了。