C/C++ question (extern)

[IHateMyJob2004]

What on Earth does this do? It was found in a cpp file mixed in with method implementations.

Who on Earth writes code like this? Even if it is valid, it is convoluted.


Oh ... seriosuly ... what does this do?

CODE (Why didn't line wrap work in the "attach code" code box)?

extern "C" {
int foo
(
int bla
);
} /* End Extern C */

 

[Madwand1]

extern "C": To force C-style identifier generation to be compatible with other code generation which uses that convention.

dummy function: To force identifier reference / linkage with specific modules.

dumb code inside a dummy function: Perhaps to force code generation of dummy function. In other cases, an extern variable / function reference inside the function could be the target of a forced link in a library.

forced linkage: Sometimes programmers get mixed up in the build process and resort to silly brute force tricks. At other times, there can be subtle needs for forcing linkage of specific modules within a library, e.g. because the creation or inclusion of some other not-directly-referenced objects has a desired side-effect on the entire program.

Of course there may be other ways of doing the same thing. Maybe it didn't occur to the original programmer. Maybe it did, but there were other considerations for that.

Or maybe this code no longer serves any purpose and is a legacy artifact that someone forgot to clean up. A way to get to the answer of all such questions in terms of intent is to put in a change control process including reviews and documentation of changes, and to require internal documentation.

 

[Markbnj]

Well, sorta. All that represents is a C-callable function prototype with external linkage. The name of the argument isn't important, the type is. It does prevent name mangling, obviously, but it's primary purpose is to pull in a method written in C (or expecting the C calling convention) in another module. The extern definition gives the compiler something to work with until the linker gets involved and supplies an actual address.

 

[Cerebus451]

The typical usage for that construct is in a header file for a C library. You would usually see it as:
# ifdef __cplusplus
extern "C" {
# endif
<C function declarations>
# ifdef __cplusplus
}
# endif

This tells the C++ compiler that those functions are written in C and to not mangle the names for the purposes of looking up the functions at link time. In the case of the C++ source file, it is simply stating that function foo is written in C, so the compiler will look for _foo at link time instead of foo(int) (or whatever the compiler's name mangling looks like).

 

[exdeath]

Yeah it will be _foo in the object file instead of _foo@XYQWW or whatever the C++ vendor's convention is for encoding parameter type into the function name in the .obj/.lib/.dll is.

In C, a function name in the object file is the same as it is in the .c file with a _ prefixed to it. Note that having multiple functions using the same name (ie: operator overloading) is not possible, and C code will typically leave it up to the programmer to append parameter type to the function name by hand to avoid name collision (ie: look at OpenGL for example glVertex3f, glVertex2i, etc).

With operator overloading introduced in C++, multiple functions can have the same name, so C++ compilers will decorate or mangle a function name based on it's parameter list, ensuring that every function, even overloaded ones, have unique names for each permutation. Note that int foo(int) and int foo(float) are two functions that share one name. In the object file, one might be called _foo@XYZ while the other is _foo@WWYZ, in other words two unique functions.

If you referenced a C compiled function int foo(int) inside a .obj/.lib/.dll module from within a C++ compiler, it will look for _foo@XYZ and not be able to find it. By prototyping as extern "C" it will know to look for the legacy C _foo function signature in the external module. Note that you will not be able to overload a function declared as extern "C".

It's mostly used when using C libraries or legacy code or C compiled .dlls in C++ to ensure that compiled C++ code can find the undecorated C function names at link time. Much of the Windows DLLs for example are C so you'll see a lot of extern "C" in Windows headers so that they work in C++ compilers, otherwise you'd get a lot of "unresolved external reference" errors.