C and C + + mixed compilation

about Extern_c

Typically, a code similar to the following is often seen in the header file of the C language:

[Plain]View Plaincopyprint?

1. #ifdef __cplusplus
2. extern "C" {
3. #endif
6. /**** some declaration or so *****/
9. #ifdef __cplusplus
10. }
11. #endif/* End of __cplusplus */

So what's the use of this notation? In fact, this is a form of syntax used to enable CPP to interface with C. This approach is due to some differences between the two languages. Because CPP supports polymorphism, that is, functions with the same function name can accomplish different functions, CPP is usually a parameter to distinguish which function is called specifically. At compile time, the CPP compiler joins the parameter types and function names, so after the program is compiled into a target file, the CPP compiler can directly connect multiple target files to a target file or executable file based on the symbol in the target file. In C, however, because there is no concept of polymorphism at all, the C compiler does nothing (at least many compilers do so) at compile time except to add an underscore before the function name. For this reason, there may be problems when using CPP and C mixed programming. Suppose that a function is defined in a header file:

[Plain]View Plaincopyprint?

1. int foo (int a, int b);

The implementation of this function is in a. c file, and this function is called in the. cpp file. Then, when the CPP compiler compiles this function, it is possible to change the function name to _fooii, where the II is the first and second parameters of the function are integer. The C compiler is likely to compile this function name into _foo. That is, in the target file that the CPP compiler obtains, the Foo () function is referenced by the _FOOII symbol, whereas in the target file generated by the C compiler, the Foo () function is referred to by _foo. But when the connector works, it does not matter what language is used in the upper layer, it only recognize the symbols in the target file. As a result, the connector will find that the Foo () function is called in the. cpp, but the _FOOII symbol is not found in the other target files, so the connection process is faulted. The syntactic form of extern "C" {} is used to solve this problem. This article shows an example of this issue.

Let's first assume that there are three of these files:

[Plain]View Plaincopyprint?

2. /* file:test_extern_c.h */
6. #ifndef __test_extern_c_h__
10. #define __test_extern_c_h__
14. #ifdef __cplusplus
16. extern "C" {
18. #endif
22. /*
24. * This is a test function, which calculate
26. * The multiply of A and B.
28. */
32. extern int thisistest (int a, int b);
36. #ifdef __cplusplus
38. }
40. #endif/* End of __cplusplus */
44. #endif

Only one function is defined in this header file, Thisistest (). This function is defined as an external function that can be included in other program files. Assume that the implementation of the Thisistest () function is in the TEST_EXTERN_C.C file:

[Plain]View Plaincopyprint?

1. /* TEST_EXTERN_C.C */
3. #include "test_extern_c.h"
5. int thisistest (int a, int b)
6. {
7. return (A + B);
8. }

As you can see, the implementation of the Thisistest () function is very simple, which is to return the result of adding two parameters. Now, suppose you want to call the Thisistest () function from the CPP:

[Plain]View Plaincopyprint?

2. /* Main.cpp */
4. #include "test_extern_c.h"
6. #include <stdio.h>
8. #include <stdlib.h>
12. Class FOO {
14. Public
18. int bar (int a, int b)
20. {
22. printf ("result=%i\n", Thisistest (A, b));
24. }
26. };
30. int main (int argc, char **argv)
32. {
34. int a = Atoi (argv[1]);
36. int b = atoi (argv[2]);
40. Foo *foo = new Foo ();
44. Foo->bar (A, b);
48. return (0);
50. }

In this CPP source file, a simple class foo is defined, and the Thisistest () function is called in its member function bar (). Here's a look at what happens if you compile test_extern_c.c with GCC and use g++ to compile main.cpp and connect to TEST_EXTERN_C.O:

[Plain]View Plaincopyprint?

1. [Email protected] src]$ gcc-c TEST_EXTERN_C.C
3. [Email protected] src]$ g++ main.cpp TEST_EXTERN_C.O
5. [Email protected] src]$./a.out 4 5
7. Result=9

As you can see, the program does not have any exceptions and works exactly the way you expect. So what happens if you comment out the lines that are in the test_extern_c.h of extern "C" {}? The contents of the test_extern_c.h file after the comment are as follows: [Plain]View Plaincopyprint?

2. /* test_extern_c.h */
4. #ifndef __test_extern_c_h__
6. #define __test_extern_c_h__
10. #ifdef __cplusplus
12. extern "C" {
14. #endif
18. /*
20. * This is a test function, which calculate
22. * The multiply of A and B.
24. */
28. extern int thisistest (int a, int b);
34. #ifdef __cplusplus
36. //  }
38. #endif/* End of __cplusplus */
42. #endif

In addition, other files do not make any changes and still compile the test_extern_c.c and main.cpp files in the same way:

[Plain]View Plaincopyprint?

1. [Email protected] src]$ gcc-c TEST_EXTERN_C.C
3. [Email protected] src]$ g++ main.cpp TEST_EXTERN_C.O
5. /TMP/CCA4ETJJ.O (. gnu.linkonce.t._zn3foo3bareii+0x10): In function ' Foo::bar (int, int) ':
7. : Undefined reference to ' thisistest (int, int) '
9. Collect2:ld returned 1 exit status

Error while compiling main.cpp, the connector LD hint could not find a reference to function Thisistest ().

To better illustrate the cause of the problem, we use the following method to compile the target file, and then see what is in the target file:

[Plain]View Plaincopyprint?

2. [Email protected] src]$ gcc-c TEST_EXTERN_C.C
6. [Email protected] src]$ objdump-t TEST_EXTERN_C.O
10. Test_extern_c.o:file format elf32-i386
14. SYMBOL TABLE:
18. 00000000 L DF *abs* 00000000 TEST_EXTERN_C.C
22. 00000000 L D. Text 00000000
26. 00000000 L D. Data 00000000
30. 00000000 L D. BSS 00000000
34. 00000000 L D. Comment 00000000
38. 00000000 G F. Text 0000000b thisistest
44. [Email protected] src]$ g++-C main.cpp
48. [Email protected] src]$ objdump-t MAIN.O
54. Main.o:file format elf32-i386
58. SYMBOL TABLE:
62. 00000000 L DF *abs* 00000000 Main.cpp
66. 00000000 L D. Text 00000000
70. 00000000 L D. Data 00000000
74. 00000000 L D. BSS 00000000
78. 00000000 L D. Rodata 00000000
82. 00000000 L D. Gnu.linkonce.t._zn3foo3bareii 00000000
86. 00000000 L D. Eh_frame 00000000
90. 00000000 L D. Comment 00000000
94. 00000000 G F. Text 00000081 Main
98. 00000000 *und* 00000000 Atoi
102. 00000000 *und* 00000000 _ZNWJ
106. 00000000 *und* 00000000 _ZDLPV
110. 00000000 W F. Gnu.linkonce.t._zn3foo3bareii 00000027 _zn3foo3bareii
114. 00000000 *und* 00000000 _z10thisistestii
118. 00000000 *und* 00000000 printf
122. 00000000 *und* 00000000 __gxx_personality_v0

As you can see, after TEST_EXTERN_C.C has been compiled with GCC, there is a thisistest symbol in its target file test_extern_c.o, which is the thisistest () function defined in the source file. After compiling the main.cpp with g++, there is a _z10thisistestii symbol in the target file main.o, which is the function name after the g++ compiler "Smash". The last two characters I represent the first parameter and the second parameter are integral types. And why add a prefix _z10 I'm not sure, but it doesn't affect our discussion, so don't worry about it. Obviously, this is where the reason is, and its principle is explained at the beginning of this article.

[Plain]View Plaincopyprint?

2. [Email protected] src]$ gcc-c TEST_EXTERN_C.C
6. [Email protected] src]$ objdump-t TEST_EXTERN_C.O
10. Test_extern_c.o:file format elf32-i386
14. SYMBOL TABLE:
18. 00000000 L DF *abs* 00000000 TEST_EXTERN_C.C
22. 00000000 L D. Text 00000000
26. 00000000 L D. Data 00000000
30. 00000000 L D. BSS 00000000
34. 00000000 L D. Comment 00000000
38. 00000000 G F. Text 0000000b thisistest

So why does the extern "C" {} form not have this problem, and let's take a look at what symbols in the target file are compiled when test_extern_c.h takes the form of extern "C" {}:

[Plain]View Plaincopyprint?

2. [Email protected] src]$ g++-C main.cpp
6. [Email protected] src]$ objdump-t MAIN.O
10. Main.o:file format elf32-i386
14. SYMBOL TABLE:
18. 00000000 L DF *abs* 00000000 Main.cpp
22. 00000000 L D. Text 00000000
26. 00000000 L D. Data 00000000
30. 00000000 L D. BSS 00000000
34. 00000000 L D. Rodata 00000000
38. 00000000 L D. Gnu.linkonce.t._zn3foo3bareii 00000000
42. 00000000 L D. Eh_frame 00000000
46. 00000000 L D. Comment 00000000
50. 00000000 G F. Text 00000081 Main
54. 00000000 *und* 00000000 Atoi
58. 00000000 *und* 00000000 _ZNWJ
62. 00000000 *und* 00000000 _ZDLPV
66. 00000000 W F. Gnu.linkonce.t._zn3foo3bareii 00000027 _zn3foo3bareii
70. 00000000 *und* 00000000 Thisistest
74. 00000000 *und* 00000000 printf
78. 00000000 *und* 00000000 __gxx_personality_v0

Notice what's different here and before, you can see, in two target files, there is a symbol thisistest, this symbol refers to the thisistest () function. Obviously, at this point in the two target files have the same thisistest symbol, so that they refer to the actual function of the same, so the two target files are concatenated together, where there is a program code snippet has thisistest symbol in the place are used Thisistest () Replace the actual address of the function. In addition, it can be seen that only the function surrounded by extern "C" {} takes the form of a target symbol, and for the member functions of the Foo class in Main.cpp, the symbolic names after the two compilations are "crushed".

Therefore, based on the above analysis, we can draw the following conclusion: the use of the extern "C" {} This form of declaration, can make the interface between CPP and C interoperability, not due to the internal mechanism of the language caused by the connection of the target file error. It should be explained that the above is just the conclusion based on the results of my experiment. Since the use of CPP is not very much, the knowledge is very small, so the internal processing mechanism is not very clear, if you need to understand the details of this issue, please refer to the relevant information.

Note:

1. For function func () that is written in the C file to be used in CPP, simply add the extern "C" declaration to the header file of the C file. For example: extern "C" func () {...}

Of course, you can use

#ifdef __cplusplus

extern "C" {

#endif

And

#ifdef __cplusplus

}

#endif

enclose the functions of the entire C file.

C and C + + mixed compilation