By Litherum

2009-06-25 02:10:07 8 Comments

What exactly does putting extern "C" into C++ code do?

For example:

extern "C" {
   void foo();


@gnasher729 2020-03-04 17:53:48

A function void f() compiled by a C compiler and a function with the same name void f() compiled by a C++ compiler are not the same function. If you wrote that function in C, and then you tried to call it from C++, then the linker would look for the C++ function and not find the C function.

extern "C" tells the C++ compiler that you have a function which was compiled by the C compiler. Once you tell it that it was compiled by the C compiler, the C++ compiler will know how to call it correctly.

It also allows the C++ compiler to compile a C++ function in such a way that the C compiler can call it. That function would officially be a C function, but since it is compiled by the C++ compiler, it can use all the C++ features and has all the C++ keywords.

@Jonathan Leffler 2020-03-05 16:47:13

The C++ compiler can compile an extern "C" function — and (subject to some constraints) it will be callable by code compiled by a C compiler.

@Ciro Santilli 郝海东冠状病六四事件法轮功 2015-05-29 10:06:31

Decompile a g++ generated binary to see what is going on


void f() {}
void g();

extern "C" {
    void ef() {}
    void eg();

/* Prevent g and eg from being optimized away. */
void h() { g(); eg(); }

Compile and disassemble the generated ELF output:

g++ -c -std=c++11 -Wall -Wextra -pedantic -o main.o main.cpp
readelf -s main.o

The output contains:

     8: 0000000000000000     7 FUNC    GLOBAL DEFAULT    1 _Z1fv
     9: 0000000000000007     7 FUNC    GLOBAL DEFAULT    1 ef
    10: 000000000000000e    17 FUNC    GLOBAL DEFAULT    1 _Z1hv
    11: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND _GLOBAL_OFFSET_TABLE_
    12: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND _Z1gv
    13: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND eg


We see that:

  • ef and eg were stored in symbols with the same name as in the code

  • the other symbols were mangled. Let's unmangle them:

    $ c++filt _Z1fv
    $ c++filt _Z1hv
    $ c++filt _Z1gv

Conclusion: both of the following symbol types were not mangled:

  • defined
  • declared but undefined (Ndx = UND), to be provided at link or run time from another object file

So you will need extern "C" both when calling:

  • C from C++: tell g++ to expect unmangled symbols produced by gcc
  • C++ from C: tell g++ to generate unmangled symbols for gcc to use

Things that do not work in extern C

It becomes obvious that any C++ feature that requires name mangling will not work inside extern C:

extern "C" {
    // Overloading.
    // error: declaration of C function ‘void f(int)’ conflicts with
    void f();
    void f(int i);

    // Templates.
    // error: template with C linkage
    template <class C> void f(C i) { }

Minimal runnable C from C++ example

For the sake of completeness and for the newbs out there, see also: How to use C source files in a C++ project?

Calling C from C++ is pretty easy: each C function only has one possible non-mangled symbol, so no extra work is required.


#include <cassert>

#include "c.h"

int main() {
    assert(f() == 1);


#ifndef C_H
#define C_H

/* This ifdef allows the header to be used from both C and C++ 
 * because C does not know what this extern "C" thing is. */
#ifdef __cplusplus
extern "C" {
int f();
#ifdef __cplusplus



#include "c.h"

int f(void) { return 1; }


g++ -c -o main.o -std=c++98 main.cpp
gcc -c -o c.o -std=c89 c.c
g++ -o main.out main.o c.o

Without extern "C" the link fails with:

main.cpp:6: undefined reference to `f()'

because g++ expects to find a mangled f, which gcc did not produce.

Example on GitHub.

Minimal runnable C++ from C example

Calling C++ from C is a bit harder: we have to manually create non-mangled versions of each function we want to expose.

Here we illustrate how to expose C++ function overloads to C.


#include <assert.h>

#include "cpp.h"

int main(void) {
    assert(f_int(1) == 2);
    assert(f_float(1.0) == 3);
    return 0;


#ifndef CPP_H
#define CPP_H

#ifdef __cplusplus
// C cannot see these overloaded prototypes, or else it would get confused.
int f(int i);
int f(float i);
extern "C" {
int f_int(int i);
int f_float(float i);
#ifdef __cplusplus



#include "cpp.h"

int f(int i) {
    return i + 1;

int f(float i) {
    return i + 2;

int f_int(int i) {
    return f(i);

int f_float(float i) {
    return f(i);


gcc -c -o main.o -std=c89 -Wextra main.c
g++ -c -o cpp.o -std=c++98 cpp.cpp
g++ -o main.out main.o cpp.o

Without extern "C" it fails with:

main.c:6: undefined reference to `f_int'
main.c:7: undefined reference to `f_float'

because g++ generated mangled symbols which gcc cannot find.

Example on GitHub.

Tested in Ubuntu 18.04.

@Gabriel Staples 2018-10-25 17:51:21

Best answer since you 1) explicitly mention that extern "C" { helps you call unmangled C functions from within C++ programs, as well as unmangled C++ functions from within C programs, which other answers don't make so obvious, and 2) because you show distinct examples of each. Thanks!

@selfboot 2019-04-09 03:45:23

I like this answer very much

@Gaspa79 2019-07-24 13:30:01

Hands down the best answer since it shows how to call overloaded functions from c

@Ciro Santilli 郝海东冠状病六四事件法轮功 2019-11-01 08:39:49

@JaveneCPPMcGowan what makes you think that I had a C++ teacher? :-)

@Susobhan Das 2020-02-15 06:36:39

Without conflicting with other good answers, I will add a bit of my example.

What exactly C++ Compiler does: it mangles the names in the compilation process, hence we require telling the compiler to treat C implementation specially.

When we are making C++ classes and adding extern "C", we're telling our C++ compiler that we are using C calling convention.

Reason (we are calling C implementation from C++): either we want to call C function from C++ or calling C++ function from C (C++ classes ... etc do not work in C).

@Jonathan Leffler 2020-02-16 01:25:25

Welcome to Stack Overflow. If you decide to answer an older question that has well established and correct answers, adding a new answer late in the day may not get you any credit. If you have some distinctive new information, or you're convinced the other answers are all wrong, by all means add a new answer, but 'yet another answer' giving the same basic information a long time after the question was asked usually won't earn you much credit. Frankly, I don't think there's anything new in this answer.

@tfmontague 2017-02-12 01:50:27

C++ mangles function names to create an object-oriented language from a procedural language

Most programming languages aren't built on-top of existing programming languages. C++ is built on-top of C, and furthermore it's an object-oriented programming language built from a procedural programming language, and for that reason there are C++ expressions like extern "C" which provide backwards compatibility with C.

Let's look at the following example:

#include <stdio.h>

// Two functions are defined with the same name
// but have different parameters

void printMe(int a) {
  printf("int: %i\n", a);

void printMe(char a) {
  printf("char: %c\n", a);

int main() {
  return 0;

A C compiler will not compile the above example, because the same function printMe is defined twice (even though they have different parameters int a vs char a).

gcc -o printMe printMe.c && ./printMe;
1 error. PrintMe is defined more than once.

A C++ compiler will compile the above example. It does not care that printMe is defined twice.

g++ -o printMe printMe.c && ./printMe;

This is because a C++ compiler implicitly renames (mangles) functions based on their parameters. In C, this feature was not supported. However, when C++ was built over C, the language was designed to be object-oriented, and needed to support the ability to create different classes with methods (functions) of the same name, and to override methods (method overriding) based on different parameters.

extern "C" says "don't mangle C function names"

However, imagine we have a legacy C file named "parent.c" that includes function names from other legacy C files, "parent.h", "child.h", etc. If the legacy "parent.c" file is run through a C++ compiler, then the function names will be mangled, and they will no longer match the function names specified in "parent.h", "child.h", etc - so the function names in those external files would also need to be mangled. Mangling function names across a complex C program, those with lots of dependencies, can lead to broken code; so it might be convenient to provide a keyword which can tell the C++ compiler not to mangle a function name.

The extern "C" keyword tells a C++ compiler not to mangle (rename) C function names.

For example:

extern "C" void printMe(int a);

@BattleTested 2018-11-04 07:17:26

can we don't use of extern "C" if we have just a dll file? I mean if we have not a header file and just have a source file (just implementations) and use of its function via function pointer. in this state, we just used of functions (regardless of its name).

@Artanis Zeratul 2018-12-11 03:28:39

@tfmontague, for me you nailed it right! straight in the head.

@Faisal Vali 2009-06-25 02:12:50

extern "C" makes a function-name in C++ have 'C' linkage (compiler does not mangle the name) so that client C code can link to (i.e use) your function using a 'C' compatible header file that contains just the declaration of your function. Your function definition is contained in a binary format (that was compiled by your C++ compiler) that the client 'C' linker will then link to using the 'C' name.

Since C++ has overloading of function names and C does not, the C++ compiler cannot just use the function name as a unique id to link to, so it mangles the name by adding information about the arguments. A C compiler does not need to mangle the name since you can not overload function names in C. When you state that a function has extern "C" linkage in C++, the C++ compiler does not add argument/parameter type information to the name used for linkage.

Just so you know, you can specify "C" linkage to each individual declaration/definition explicitly or use a block to group a sequence of declarations/definitions to have a certain linkage:

extern "C" void foo(int);
extern "C"
   void g(char);
   int i;

If you care about the technicalities, they are listed in section 7.5 of the C++03 standard, here is a brief summary (with emphasis on extern "C"):

  • extern "C" is a linkage-specification
  • Every compiler is required to provide "C" linkage
  • a linkage specification shall occur only in namespace scope
  • all function types, function names and variable names have a language linkage See Richard's Comment: Only function names and variable names with external linkage have a language linkage
  • two function types with distinct language linkages are distinct types even if otherwise identical
  • linkage specs nest, inner one determines the final linkage
  • extern "C" is ignored for class members
  • at most one function with a particular name can have "C" linkage (regardless of namespace)
  • extern "C" forces a function to have external linkage (cannot make it static) See Richard's comment: 'static' inside 'extern "C"' is valid; an entity so declared has internal linkage, and so does not have a language linkage
  • Linkage from C++ to objects defined in other languages and to objects defined in C++ from other languages is implementation-defined and language-dependent. Only where the object layout strategies of two language implementations are similar enough can such linkage be achieved

@Litherum 2009-06-25 02:25:47

This appears to be under-the-hood ... is there any functional reason why I would put 'extern "C"' in front of a function (other than to call it from a separate C program)?

@Sam Liao 2009-06-25 02:28:55

C compiler does not use mangling which c++'s does. So if you want call a c interface from a c++ program, you have to clearly declared that the c interface as "extern c".

@Faisal Vali 2009-06-25 02:41:19

@Litherum - if you do not intend your code to be linked-to by a different C++ compiler or any C compiler or some dynamic language (ruby, python etc) for which you are developing an extension - you don't need extern "C". It buys you nothing.

@Jonathan Leffler 2009-06-25 03:24:42

@Faisal: do not try to link code built with different C++ compilers, even if the cross-references are all 'extern "C"'. There are often differences between the layouts of classes, or the mechanisms used to handle exceptions, or the mechanisms used to ensure variables are initialized before use, or other such differences, plus you might need two separate C++ run-time support libraries (one for each compiler).

@Faisal Vali 2009-06-25 03:57:18

@Leffler - thanks, you make good points. I did not mean to encourage using different C++ compilers by using extern "C". Rather, I was hoping to suggest that if you are not writing something that would need to be linked to by another C++ compiler, you probably don't need extern "C".

@Ben Voigt 2013-01-17 15:03:07

No mention of calling convention? No mention that the Standard requires using extern "C" modifiers on functions pointers in order to call C linkage functions (although in practice many implementations don't care)?

@Richard Smith 2013-02-14 04:06:43

'extern "C" forces a function to have external linkage (cannot make it static)' is incorrect. 'static' inside 'extern "C"' is valid; an entity so declared has internal linkage, and so does not have a language linkage.

@Richard Smith 2013-02-14 04:07:14

'all function types, function names and variable names have a language linkage' is also incorrect. Only function names and variable names with external linkage have a language linkage.

@Faisal Vali 2014-04-14 18:10:30

@Richard Thanks! Sorry it took so long to fix the post.

@Ben Voigt 2014-06-27 05:36:49

Richard's actually wrong. Language linkage affects calling convention, the Standard doesn't say whether it's possible to call an extern "C" function using a function pointer that isn't specifically declared as pointing to an extern "C" type. Function types DO have language linkage. That said, I've never seen an implementation which takes advantage of the flexibility with the Standard allows in this area.

@aschepler 2014-07-01 16:39:02

Note that extern "C" { int i; } is a definition. This may not be what you intended, next to the non-definition of void g(char);. To make it a non-definition, you would need extern "C" { extern int i; }. On the other hand, the one-declaration syntax without braces does make the declaration a non-definition: extern "C" int i; is the same as extern "C" { extern int i; }

@MarcusJ 2014-09-12 22:11:28

Do I have to do this for just the included header files, or around every function that uses the functions contained in those headers, or a mixture of both?

@M.M 2015-01-26 22:28:55

Another way to put this is that extern "C" tells the compiler that those symbols will be found in object files that conform to the C ABI (for that compiler, of course) , as opposed to the C++ ABI.

@fuz 2015-04-17 09:13:06

How can one specify C++ linkage?

@Jonathan Wakely 2016-01-19 20:39:52

@FUZxxl, extern "C++", unsurprisingly.

@godspeed1024 2017-10-25 10:03:51

What if I wrap a C++ class defination in extern "C" { ... } ? Especially when: 1. this class has functions with the same name; 2. this class has functions that return C++ class object ? If compiler does not mangle these function names, how would it be linked properly?

@mbrig 2017-11-30 20:46:27

@godspeed1024 Wrapping a class with extern "C" will get you a compiler error. But even if it didn't, this question points out that C language linkage is ignored for member functions.

@BattleTested 2018-08-18 08:35:39

if we use of extern "C" name mangling doesn't occur because c has not name mangling, so extern "C" cause keep declaration with definition names (because if not using of extern "C" it may change function or class declaration with name mangling)

@user9599745 2019-11-01 03:48:40

I am a bit late here but what Leffler said about not linking to different c++ compiler code makes no sense to me. I do this all the time. Linking to SFML lib, lib I made in Visual studio to Code Blocks mingw. mingw32 to mingw64. Sounds ridiculous to me.

@Sander Mertens 2013-01-09 22:16:05

Not any C-header can be made compatible with C++ by merely wrapping in extern "C". When identifiers in a C-header conflict with C++ keywords the C++ compiler will complain about this.

For example, I have seen the following code fail in a g++ :

extern "C" {
struct method {
    int virtual;

Kinda makes sense, but is something to keep in mind when porting C-code to C++.

@M.M 2015-01-26 22:26:05

extern "C" means to use C linkage, as described by other answers. It doesn't mean to "compile the contents as C" or anything. int virtual; is invalid in C++ and specifying different linkage doesn't change that.

@Valentin Heinitz 2017-11-01 10:33:51

... or mode generally, any code containing syntax error will not compile.

@Sander Mertens 2017-11-02 14:35:51

@ValentinHeinitz naturally, though using "virtual" as an identifier in C is not a syntax error. I just wanted to point that you cannot automatically use any C header in C++ by putting extern "C" around it.

@Manohar Reddy Poreddy 2018-07-24 13:41:42

This answer is for the impatient/ have deadlines to meet to, only a part/simple explanation is below:

  • in C++, you can have same name in class via overloading (for example, since they are all same name can't be exported as-is from dll, etc.) solution to these problems is they are converted to different strings (called symbols), symbols accounts the name of function, also the arguments, so each of these functions even with same name, can be uniquely identified (also called, name mangling)
  • in C, you don't have overloading, the function name is unique (so, a separate string for identifying the a function name uniquely is not required, so symbol is function name itself)

in C++, with name mangling uniquely identities each function
in C, even without name mangling uniquely identities each function

To change the behaviour of C++, that is, to specify that name mangling should not happen for a particular function, you can use extern "C" before the function name, for whatever reason, like exporting a function with a specific name from a dll, for use by its clients.

Read other answers, for more detailed/more correct answers.

@sud03r 2009-06-25 05:22:05

In every C++ program, all non-static functions are represented in the binary file as symbols. These symbols are special text strings that uniquely identify a function in the program.

In C, the symbol name is the same as the function name. This is possible because in C no two non-static functions can have the same name.

Because C++ allows overloading and has many features that C does not — like classes, member functions, exception specifications - it is not possible to simply use the function name as the symbol name. To solve that, C++ uses so-called name mangling, which transforms the function name and all the necessary information (like the number and size of the arguments) into some weird-looking string processed only by the compiler and linker.

So if you specify a function to be extern C, the compiler doesn't performs name mangling with it and it can be directly accessed using its symbol name as the function name.

This comes handy while using dlsym() and dlopen() for calling such functions.

@Error 2018-03-03 10:06:58

what do you mean by handy? is symbol name = function name would make symbol name passed to dlsym known, or other thing?

@Jonathan Tomer 2018-04-23 22:23:35

@Error: yes. It's essentially impossible in the general case to dlopen() a C++ shared library given only a header file and pick the right function to load. (On x86, there's a published name-mangling specification in the form of the Itanium ABI that all x86 compilers I know of use to mangle C++ function names, but nothing in the language requires this.)

@Trombe 2017-07-06 04:04:23

When mixing C and C++ (i.e., a. calling C function from C++; and b. calling C++ function from C), the C++ name mangling causes linking problems. Technically speaking, this issue happens only when the callee functions have been already compiled into binary (most likely, a *.a library file) using the corresponding compiler.

So we need to use extern "C" to disable the name mangling in C++.

@Yogeesh H T 2015-11-17 12:09:03

extern "C" is a linkage specification which is used to call C functions in the Cpp source files. We can call C functions, write Variables, & include headers. Function is declared in extern entity & it is defined outside. Syntax is

Type 1:

extern "language" function-prototype

Type 2:

extern "language"


using namespace std;

extern "C"
     #include<stdio.h>    // Include C Header
     int n;               // Declare a Variable
     void func(int,int);  // Declare a function (function prototype)

int main()
    func(int a, int b);   // Calling function . . .
    return 0;

// Function definition . . .
void func(int m, int n)

@SturmCoder 2014-07-01 15:43:34

I used 'extern "C"' before for dll(dynamic link library) files to make etc. main() function "exportable" so it can be used later in another executable from dll. Maybe an example of where I used to use it can be useful.


#include <string.h>
#include <windows.h>

using namespace std;

#define DLL extern "C" __declspec(dllexport)
//I defined DLL for dllexport function
DLL main ()
    MessageBox(NULL,"Hi from DLL","DLL",MB_OK);


#include <string.h>
#include <windows.h>

using namespace std;

typedef LPVOID (WINAPI*Function)();//make a placeholder for function from dll
Function mainDLLFunc;//make a variable for function placeholder

int main()
    char winDir[MAX_PATH];//will hold path of above dll
    GetCurrentDirectory(sizeof(winDir),winDir);//dll is in same dir as exe
    strcat(winDir,"\\exmple.dll");//concentrate dll name with path
    HINSTANCE DLL = LoadLibrary(winDir);//load example dll
        FreeLibrary((HMODULE)DLL);//if load fails exit
        return 0;
    mainDLLFunc=(Function)GetProcAddress((HMODULE)DLL, "main");
    //defined variable is used to assign a function from dll
    //GetProcAddress is used to locate function with pre defined extern name "DLL"
    //and matcing function name
        FreeLibrary((HMODULE)DLL);//if it fails exit
        return 0;
    mainDLLFunc();//run exported function 

@IInspectable 2016-09-07 08:28:26

Bogus. extern "C" and __declspec(dllexport) are unrelated. The former controls symbol decoration, the latter is responsible for creating an export entry. You can export a symbol using C++ name decoration just as well. Besides completely missing the point of this question, there are other mistakes in the code sample as well. For one, main exported from your DLL doesn't declare a return value. Or calling convention, for that matter. When importing, you attribute a random calling convention (WINAPI), and use the wrong symbol for 32-bit builds (should be _main or [email protected]). Sorry, -1.

@SturmCoder 2017-05-25 09:17:42

Actualy that is just an working example where I used it before to export function, and it should be used just to get idea how it can be used. I didn't said it is necessary to use it this way. Also, DLL main () declared in dll is of type DLL which is -> (extern "C" __declspec(dllexport)) type not int or string, defined above and it does not return anything like void, I named it "main", but it can be named whatever and it should be not confused with "main" of type int in executable itself. However this compiles and works great with many other functions in dll with parameters and return also.

@IInspectable 2017-05-25 09:26:38

That only repeated, that you don't know, what you are doing, but doing it this way appears to work for you, for some undisclosed list of target platforms. You didn't address the issues I raised in my previous comment. This is still a down-vote, due to being wildly wrong (there's more, that didn't fit in a single comment).

@SturmCoder 2017-05-25 10:28:29

I didn't said anywhere that I'm know what I am doing,I just said that I used extern "C" before in this way. Yes, it is works for me on windows only cause I tried it on that platform only,you can see "#include <windows.h>".WINAPI is just a macro that evaluates to stdcall to prevent corrupting the stack where caller and callee need to agree on a calling convention i learned that here too and it is used in placeholder for exported function "typedef LPVOID (WINAPI*Function)();" to prevent stack corruption on run. Maybe you are right but I actualy don't care at all about your down-vote,thrust me ;)

@IInspectable 2017-05-25 10:40:22

Posting an answer on Stack Overflow kind of implies, that you know what you are doing. This is expected. As for your attempt "to prevent stack corruption on run": Your function signature specifies a return value of type void*, but your implementation doesn't return anything. That'll fly really well...

@SturmCoder 2017-05-25 11:10:22

I implemented and posted an working example that I used before myself. If you implement something and it works, it kind of implies that you know what are you doing, so I decided to post. Actualy I specified, set type with typedef of exported function which is LPVOID: "typedef LPVOID (WINAPIFunction)();" and void and LPVOID is the same where LPVOID is windows api for void* so you can use void* to point any type. So this means when you implement functions inside dll it is an undefined type until you put it inside a predefined placeholder where you need to specify type to match function in exe.

@IInspectable 2017-05-25 11:23:06

If you implement something, that appears to work, by pure luck, then you clearly do not know what you are doing (your "working" sample falls into that category). It's undefined behavior, and appearing to work is a valid form of undefined behavior. It's still undefined. I would highly appreciate it, if you exercised more diligence in the future. Part of that could be deleting this proposed answer.

@SturmCoder 2017-05-25 11:57:21

By pure luck? You are trolling me man whole time, so this conversation is over.

@IInspectable 2017-05-25 12:36:39

You are reinterpreting a function that doesn't return anything as a function that returns a pointer. It is pure luck, that x86 is very forgiving with respect to mismatching function signatures, and in particular return values of integral type. Your code works by coincidence only. If you disagree, you need to explain, why your code works reliably.

@Adrian W 2018-06-21 21:01:30

This answer is completely unrelated to OP's question.extern "C" does not make a function exportable. That's simply nonsense.

@Manohar Reddy Poreddy 2018-07-26 03:02:15

Very good example of the topic discussed. Using this I have exported a VC++ function, then called it from C#, using

@UncaAlby 2012-10-21 01:08:32

Just wanted to add a bit of info, since I haven't seen it posted yet.

You'll very often see code in C headers like so:

#ifdef __cplusplus
extern "C" {

// all of your legacy C code here

#ifdef __cplusplus

What this accomplishes is that it allows you to use that C header file with your C++ code, because the macro "__cplusplus" will be defined. But you can also still use it with your legacy C code, where the macro is NOT defined, so it won't see the uniquely C++ construct.

Although, I have also seen C++ code such as:

extern "C" {
#include "legacy_C_header.h"

which I imagine accomplishes much the same thing.

Not sure which way is better, but I have seen both.

@Anne van Rossum 2013-04-12 14:00:17

There is a distinct difference. In case of the former, if you compile this file with normal gcc compiler it will generate an object where the function name is not mangled. If you then link C and C++ objects with the linker it will NOT find the functions. You will need to include those "legacy header" files with the extern keyword as in your second code block.

@Ben Voigt 2014-06-27 05:34:35

@Anne: The C++ compiler will look for unmangled names also, because it saw extern "C" in the header). It works great, used this technique many times.

@Anne van Rossum 2014-06-30 13:35:05

@Ben. I was referring to the sentence Not sure which way is better, but I have seen both.. There is a difference! If you compile the first file with gcc, it didn't encounter the extern "C" phrase... So, if you don't use the second phrase in your C++ code you're still in trouble. There is no difference if you use the same compiler for all files.

@Ben Voigt 2014-06-30 15:54:26

@Anne: That's not right, the first one is fine as well. It's ignored by the C compiler, and has the same effect as the second in C++. The compiler couldn't care less whether it encounters extern "C" before or after it includes the header. By the time it reaches the compiler, it's just one long stream of preprocessed text anyway.

@Anne van Rossum 2014-06-30 18:35:01

@Ben. Sure, as long the g++ compiler hits the statement somewhere, you're fine. Perhaps I've worked with crappier g++ cross-compilers that didn't always figure out the entire tree of header files for me. :-)

@Jonathan Wakely 2016-01-19 20:45:33

@Anne, no, I think you've been affected by some other error in the source, because what you are describing is wrong. No version of g++ got this wrong, for any target, at any time in the last 17 years at least. The whole point of the first example is that it doesn't matter whether you use a C or C++ compiler, no name mangling will be done for the names in the extern "C" block.

@ostrokach 2017-03-12 20:54:30

Good example of the first method are CPython header files:

@Aconcagua 2017-08-09 09:23:07

"which one is better" - for sure, the first variant is better: It allows including the header directly, whithout any further requirements, both in C and C++ code. The second approach is a workaround for C headers the author forgot the C++ guards (no problem, though, if these are added afterwards, nested extern "C" declarations are accepteded...).

@Valentin Heinitz 2017-11-01 10:30:59

The second version is very-very cool. I was not aware of it. No need to pollute C code with __cplucplus, if entire C-code is required in C++. I'm writing a simulator/tester in C++ for legacy C-code. Including the C-headers this way works perfectly and C-code remains untouched.

@S.S. Anne 2019-06-20 15:06:25

Why says C is "legacy"?

@UncaAlby 2019-06-21 00:07:49

@JL2210 should be obvious, C is the base language from which any number of modern languages were derived, including Java, C#, and of course, C++. It is the Grandfather of Programming Languages.

@S.S. Anne 2019-06-21 01:31:06

@UncaAlby "legacy" usually refers to "old and shouldn't be used anymore", not "the basis of many great programming languages".

@UncaAlby 2019-06-22 00:24:44

@JL2210 yah, say that when you get old!! "1. adjective: denoting or relating to software or hardware that has been superseded but is difficult to replace because of its wide use." It just happens to also be a fact that it is the basis of many modern programming languages (not necessarily great mind you) You can't be the basis for modern languages without also being old.

@S.S. Anne 2019-06-22 00:33:32

@UncaAlby You win.

@UncaAlby 2019-06-22 19:43:16

@JL2210 LOL !! Thanks, I've never heard that in a forum before! EVER! :-)

@Flami 2012-04-10 09:46:10

extern "C" is meant to be recognized by a C++ compiler and to notify the compiler that the noted function is (or to be) compiled in C style. So that while linking, it link to the correct version of function from C.

@Employed Russian 2009-06-25 02:12:21

It changes the linkage of a function in such a way that the function is callable from C. In practice that means that the function name is not mangled.

@Matthew Scharley 2009-06-25 02:17:51

Mangled is the term generally used... Don't believe I've ever seen 'decorated' used with this meaning.

@René Nyffenegger 2020-01-31 21:41:47

Microsoft (at least partially) uses decorated rather than mangled in their documentation. they even name their tool to undecorate (aka un-mangle) a name undname.

@Mark Rushakoff 2009-06-25 02:12:12

It informs the C++ compiler to look up the names of those functions in a C-style when linking, because the names of functions compiled in C and C++ are different during the linking stage.

Related Questions

Sponsored Content

1 Answered Questions

[SOLVED] The Definitive C++ Book Guide and List

  • 2008-12-23 05:23:56
  • grepsedawk
  • 2381393 View
  • 4243 Score
  • 1 Answer
  • Tags:   c++ c++-faq

26 Answered Questions

24 Answered Questions

[SOLVED] What is the "-->" operator in C++?

40 Answered Questions

4 Answered Questions

[SOLVED] What does the ??!??! operator do in C?

  • 2011-10-19 16:56:59
  • Peter Olson
  • 260956 View
  • 1997 Score
  • 4 Answer
  • Tags:   c operators trigraphs

10 Answered Questions

11 Answered Questions

[SOLVED] What does the explicit keyword mean?

5 Answered Questions

[SOLVED] What is the copy-and-swap idiom?

5 Answered Questions

[SOLVED] What is ":-!!" in C code?

Sponsored Content