c语言中extern的作用6,[020]extern "C"的作用

前言

我们用Android Studio新建native的demo应用中，一般C++的代码如下，这是一个典型的静态注册JNI的例子，调用stringFromJNI的java方法会调用到Java_com_kobe_MainActivity_stringFromJNI这个方法，细心的朋友会发现有一行extern "C"，那这个有什么作用呢，能不能删除？

C++代码

#include

#include

extern "C"

JNIEXPORT jstring JNICALL Java_com_kobe_MainActivity_stringFromJNI(

JNIEnv *env,

jobject /* this */) {

std::string hello = "Hello from C++";

return env->NewStringUTF(hello.c_str());

}

删除extern "C"

实践是检验真理的最好手段，我们删除一下extern "C"试试，虽然编译通过了，但是程序运行出现了闪退，出现了如下的异常，好像是没有找到Java_com_kobe_MainActivity_stringFromJNI这个方法，为什么呢，我明明也写了这个方法。

Process: com.kobe, PID: 18796

java.lang.UnsatisfiedLinkError: No implementation found for java.lang.String com.kobe.MainActivity.stringFromJNI()

(tried Java_com_kobe_MainActivity_stringFromJNI and Java_com_kobe_MainActivity_stringFromJNI__)

at com.kobe.MainActivity.stringFromJNI(Native Method)

at com.kobe.MainActivity.onCreate(MainActivity.java:22)

at android.app.Activity.performCreate(Activity.java:7802)

at android.app.Activity.performCreate(Activity.java:7791)

at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1309)

at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:3344)

at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3508)

at android.app.servertransaction.LaunchActivityItem.execute(LaunchActivityItem.java:83)

at android.app.servertransaction.TransactionExecutor.executeCallbacks(TransactionExecutor.java:135)

at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:95)

at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2102)

at android.os.Handler.dispatchMessage(Handler.java:107)

at android.os.Looper.loop(Looper.java:214)

at android.app.ActivityThread.main(ActivityThread.java:7499)

at java.lang.reflect.Method.invoke(Native Method)

at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:492)

at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:935)

对比编译出来的so

我们通过nm的指令查看两次编译出来的so，发现Java_com_kobe_MainActivity_stringFromJNI变成_Z40Java_com_kobe_MainActivity_stringFromJNIP7_JNIEnvP8_jobject。

//保留extern "C"

19:15 Kobe-Wang:~/Desktop$ nm libnative-lib.so | grep stringFromJNI

000000000000ea98 T Java_com_kobe_MainActivity_stringFromJNI

//去掉extern "C"

19:16 Kobe-Wang:~/Desktop$ nm libnative-lib.so | grep stringFromJNI

000000000000eab8 T _Z40Java_com_kobe_MainActivity_stringFromJNIP7_JNIEnvP8_jobject

静态注册的JNI搜索native层的方法

void* FindNativeMethod(Thread* self, ArtMethod* m, std::string& detail)

REQUIRES(!Locks::jni_libraries_lock_)

REQUIRES_SHARED(Locks::mutator_lock_) {

...

//去找本地方法中有没有jni_short_name和jni_long_name的方法

void* native_code = FindNativeMethodInternal(self,

declaring_class_loader_allocator,

shorty,

jni_short_name,

jni_long_name);

//如果找到了就返回函数指针

if (native_code != nullptr) {

return native_code;

}

//没有找到了就返回异常，也就是前面出现的异常

detail += "No implementation found for ";

detail += m->PrettyMethod();

//jni_short_name就是Java_com_kobe_MainActivity_stringFromJNI

//jni_long_name就是Java_com_kobe_MainActivity_stringFromJNI__

detail += " (tried " + jni_short_name + " and " + jni_long_name + ")";

return nullptr;

}

extern "C"移除之后，so中的函数最后编译出来的方法名从Java_com_kobe_MainActivity_stringFromJNI变成了Z40Java_com_kobe_MainActivity_stringFromJNIP7_JNIEnvP8_jobject，而静态注册的JNI只会找Java_com_kobe_MainActivity_stringFromJNI和Java_com_kobe_MainActivity_stringFromJNI_，当然找不到。

extern "C"的作用到底是什么呢？

extern "C"的作用就是让被作用的代码块采用c语言的编译规则编译

为什么相同的方法名编译出不同的方法名

java的工程师应该都听说过函数的重载，java语言中函数的重载就是可以存在两个同名不同参数的函数。但是C语言是不支持函数重载的，C++为了实现函数的重载，会对我们自己写的函数在编译之后重新修饰，修饰的规则好像就是把原函数的名和参数组合成了新的一个函数_Z40Java_com_kobe_MainActivity_stringFromJNIP7_JNIEnvP8_jobject。

总结

1.C不支持函数的重载，编译之后函数名不变

2.C++支持函数的重载，编译之后函数名会变

3.静态注册的JNI接口，需要考虑C++编译之后函数名变化的问题，所以需要加上extern "C"的关键字。

4.动态注册的JNI接口，就不用担心这个问题，所以不用加extern "C"

进一步思考

很多时候我们会碰到一些头文件中声明了C语言的函数，但是这个头文件会被C语言或者C++语言使用。比如我们常见的C语言函数库中string.h的函数

void *memset(void *s, int c, size_t n);

如果不加任何处理，当C语言程序包含string.h的时候，C语言编译器会将memset正确引用处理。但是在C++语言中就会将memset函数修饰成_Z6memsetPvii, 这样子链接器就无法与C库中的memset的链接了，所以必须使用extern "C"，但是C语言又不支持extern "C"，如果为了兼容C和C++，定义两个头文件就过于麻烦了。幸好我们有一种很好的方法可以解决这个问题，那就是使用C++的宏"__cplusplus"，我们可以通过这个宏来判断当前的编译器是不是c++编译器。

#if defined(__cplusplus)

extern "C" {

#endif

void *memset(void *s, int c, size_t n);

#if defined(__cplusplus)

}

#endif

这种使用技巧，可以说在android源码中随处可见，下次看到了应该就知道为什么了吧。

参考文献

《程序员的自我修养》第三章 目标文件里有什么