views:

523

answers:

4

How this works in C or C++?

extern "C" {
#include <unistd.h>
#include <fd_config.h>
#include <ut_trace.h>
#include <sys/stat.h>
#include <sys/types.h>
}
+1  A: 

It will not work, you need to add the cplusplus preprocessor...

#ifdef __cplusplus
extern "C" {
#endif

// your code


#ifdef __cplusplus
}
#endif

EDIT:

In C++, the name will be treated like in C which mean that there will be no mangle name. It allows to make the difference between two C++ different function with different argument type/number or a different namespace in a library (for library purpose libname.so, libname.a). If the name is mangled, the C program will not be able to recognize it

eg:
int myfction()
void myfunction(int)
void myfunction(int, char)

C library:   myfction

C++ library: int_myction (it depend on your compiler)
C++ library: int_myction_int (it depend on your compiler)
C++ library: int_myction_int_char (it depend on your compiler)
// ... which is not allowed in C program
Phong
+3  A: 

The C++ standard does not specify how compilers should name the symbols in their object files (for instance, Foo::bar() might end up as __clsFoo_fncBar or some gobbledygook). The C standard does, and it is almost always different from how C++ compilers do it (C doesn't have to deal with classes, namespaces, overloading, etc.).

As a result, when you are linking against an object file that was output by a C compiler, you have to tell your C++ compiler to look for symbols with names that correspond to the C standard. You are essentially putting it in "C mode." This is what the "C" part of extern "C" does.

(Alternatively, you might also be declaring functions or variables that could be used by an external C object file. In this case, it means export those symbols the C way.)

Tim Yates
A: 

Every C++ Compiler needs to support the extern "C" linkage. The code in such block could be legacy code written in C for a certain functionality, which is required for the current program.

How this is implemented is mostly compiler dependent, However I heard that many Compilers disable the name mangling and change the calling convention.

Narendra N
A: 

If your Project has C and C++ source files and you need to build as a whole( C files calls some functions in C++ files) ,so we need to protect the C file function calls and symbols by declaring as in C++ files by

extern "C" { /symbols used in c files/ uint8 GetCurrentthreadState(HANDLE ThreadId)

}

Then the C++ complier generate compilation output which is same as that of C complier for the above declared functions and symbols.So on linking time , the compiler can easily link the C and C++ defined symbols with out any link error.

So my opinion is not needed to give the #ifdef __cplusplus check on compilation. Because we need to protect the symbols in c++ files right? Also C++ files can be compiled by C++ compiler only right?

/renjith g

Renjith G
The #ifdef __cplusplus guards are useful if you have the declarations in a header file that may be included by both C and C++ programs. This happens very often when you have a mixed C/C++ project or you are writing a library.
Tim Yates
no , it is not at all necessary to check #ifdef __cplusplus macro in header files , if you are using a native C++ compiler.The extern "C" {} usage is enough for the same./renjith g
Renjith G