According to (c) ANSI ISO/IEC 14882:2003, page 127:
Linkage specifications nest. When linkage specifications nest, the innermost one determines the language. A linkage specification does not establish a scope. A linkage-specification shall occur only in namespace scope (3.3). In a linkage-specification, the specified language linkage applies to the function types of all function declarators, function names, and variable names introduced by the declaration(s).
extern "C" void f1(void(*pf)(int));
// the name f1 and its function type have C language
// linkage; pf is a pointer to a C function
extern "C" typedef void FUNC();
FUNC f2;
// the name f2 has C++ language linkage and the
// function's type has C language linkage
extern "C" FUNC f3;
// the name of function f3 and the function's type
// have C language linkage
void (*pf2)(FUNC*);
// the name of the variable pf2 has C++ linkage and
// the type of pf2 is pointer to C++ function that
// takes one parameter of type pointer to C function
What does all this mean? For example, what linkage does the f2()
function have, C or C++ language linkage?
As pointed out by @Johannes Schaub, there is no real explanation of what this means in the Standard so it can be interpreted differently in different compilers.
Please explain the differences in the object file:
- a function's name with C language linkage and C++ language linkage.
- a function's type with C language linkage and C++ language linkage.
Every function, function type, and object has a language linkage, which is specified as a simple character string. By default, the linkage is "C++". The only other standard language linkage is "C". All other language linkages and the properties associated with different language linkages are implementation-defined.
The name
FUNC
is declared with "C" linkage because it saysextern "C"
on the first line.The name
f2
has C++ linkage because that is the default, and no other linkage is given on line two.The fact that the name
f2
is used to refer to a function with C linkage doesn't change the linkage of the name.What you're calling the "f2() function" has two aspects to its linkage:
To call
f2()
you find its name aka symbol in the object file, which will be a mangled version of "function named f2 taking no arguments". You can verify this trivially by compiling the above code and inspecting the object (e.g. w/ GNU toolsnm --demangle
).But to call the function, the conventions for pre- and post-conditions re register usage, stack setup etc. are those of a C functions. It is legal for C and C++ functions to have different calling conventions, and might be done - for example - to facilitate C++ exception handling.
f2()
_Z2f2v
which demangles tof2()
)As discussed above, this is about the register/stack usage convention for calling the code at the function's address. This meta-information is not necessarily stored in the symbol table information of the object (and certainly isn't part of the symbol name key itself).
Further, because each function adopts one of the calling conventions, a compiler needs to know the calling convention to use when following a pointer to a function: with that insight, I think the remaining code in the question becomes clear.
There's an excellent discussion at http://developers.sun.com/solaris/articles/mixing.html - in particular I recommend the section Working with Pointers to Functions.
As we all know in C/C++ code translation is composed of two principal phases: compilation and linking. When compiler generates object files it passes information to linker specifying in which object files given function is called or referenced. In C it is just like that, function has a name and matching definition.
And after compilation file1.obj stores the code and information about the definition of the foo symbol.
But when C++ comes in the symbol names become more complicated. A function may be overloaded or be a member of a class. But the linker does not want to know it. To preserve simplicity and re-usability of older linkers it needs a single name whether foo is:
But it cannot be called just foo anymore so here comes name mangling. And we may get from the compiler some variations like foo_void, foo_int, foo_void_classa. And finally the linker is happy as all those look to it like simple symbols.
When we want to call the foo function compiled with the C compiler in C++ code we must tell the compiler that we want foo to be C style foo and not foo_void as C++ compiler might assume. It is done using:
Now the compiler knows that foo is compiled using C compiler and will pass information to the linker that this code calls foo. The linker will match it with the foo definition in file1.obj. So it's all I think.
Some other directives like cdecl or stdcall are Windows specific and tell how parameters in function calls are being passed. Yes, for C and C++ it is cdecl. But Windows API functions use stdcall - Pascal convention (simplicity and historically Microsoft once provided Windows dev environment in Pascal).
"the name f2 has C++ language linkage" In C++ language linkage not only the name of the function defines it but also the type of it arguments and the return value. in this case you have: void f2(void); but you can define with it: void f2(int a); without conflict because the linkage will see them as different types, a thing you wouldn't be able to do in C language.
"the function's type has C language linkage" I don't know the details but I know the high level of it. Basically it makes a C++ compiled function linkable from C. If I remember correctly In C and in C++ the way the parameters are passed to a function is different. In this case the function f2 will pass the parameters as C compiler does this. this way the function will be linkable both from C and C++.
It has to do with the ABI (Application Binary Interface) of the program.
As an API specifies the the external interface of the source code of a program, an ABI specifies the external interface of the binary code of the program (the compiled version).
Originally, C functions simply had a few different forms. Something like
would be prefixed by an underscore by the compiler, to form
_foo
, and then exported to be made available to other applications.However, that wasn't enough. If you look at the Windows API, for instance, you will see things like:
This is because there's no way to distinguish between the overloads of a function simply by looking at the name of the function, so people started changing them by adding an
Ex
suffix (or the like).This grew to be pretty ugly, and it still didn't allow for operator overloading, which was featured in C++. Because of this, C++ came up with name mangling, to put extra information in the name of the function, like the data types of its parameters, and making it something cryptic with lots of
@
symbols.It was all well, except that it wasn't completely standardized.
Of course, as new languages and compilers came about, each came up with its own scheme, some incompatible with others. So if you need to import or export an external function, you need to specify what kind of ABI the compiler should look for, hence the
extern "C++"
you have there.