linking C with C++

[johny smith]

Can someone please explain to me why when linking a C with a C++ program
that there has to be some flag to check to see if it is compiled with C++.

For example. This is not exactly correct but hopefully gives the idea.

Thanks in advance.


#ifdef _cplusplus

extern c

{



}

#endif

 

[Gregg]

Can someone please explain to me why when linking a C with a C++
program that there has to be some flag to check to see if it is
compiled with C++.

Unlike C compilers, C++ compilers need, when generating an object file,
to "decorate" the symbols with type information in order to support
overloading (using the same symbol for two or more functions with
different parameter types). Since C does not support overloading like
this, C compilers do not generate this decoration.

The extern "C" tells the C++ compiler not to adorn symbol names with type
information, but insted to store the symbol the way a C compiler would.
Of course, functions declared this way will not support overloading, and
must be non-member or static member functions.

The #ifdef __cplusplus is required because only the C++ compiler
understands the extern "C" declaration. You would normally see something
like this:

#ifdef __cplusplus
extern "C" {
#endif

/* stuff to be used by both C and C++ here */

#ifdef __cplusplus
}
#endif

Hope this helps.

Gregg

 

[Gregg]

The #ifdef __cplusplus is required because only the C++ compiler
understands the extern "C" declaration. You would normally see
something like this:

#ifdef __cplusplus
extern "C" {
#endif

/* stuff to be used by both C and C++ here */

#ifdef __cplusplus
}
#endif

Let me clarify. The #ifdef __cplusplus allows the same header to be
included by both C and C++ source files. The #ifdef __cplusplus is not
required if the header is going to be included only by a C++ source file
and never by a C source file.

Gregg

 

[Denis Remezov]

Unlike C compilers, C++ compilers need, when generating an object file,
to "decorate" the symbols with type information in order to support
overloading (using the same symbol for two or more functions with
different parameter types). Since C does not support overloading like
this, C compilers do not generate this decoration.

The extern "C" tells the C++ compiler not to adorn symbol names with type
information, but insted to store the symbol the way a C compiler would.
Of course, functions declared this way will not support overloading, and
must be non-member or static member functions.

Member functions cannot have C linkage, even if static (the compiler will
ignore the extern "C" {...} applied to them).

Interestingly, the standard avoids specifying what a language linkage
(either C++ or C) must or should entail, leaving it to the implementation.
So I suppose that instead of C++ name mangling we could have had some other
mechanism. I also read it to mean that, in principle, C and C++ linkages
are allowed to use different calling conventions. At any rate, it is
undefined behaviour to call a function through an expression with a different
language linkage; e.g., to use a pointer to a static member function where
a "C" function is expected.
(I have a vague idea of the real world implications of the last rule, but
I don't see a reason not to follow it).

Denis

 

[Gregg]

Member functions cannot have C linkage, even if static (the compiler
will ignore the extern "C" {...} applied to them).

Yes, that is what the standard says. I'm not sure what I was thinking of
when I wrote that, but it may have been the idea of using a static member
function as the target of a callback from code expecting a C function.
That of course does not involve symbolic linkage, but does involve ABI
compatibility (stack frame layout, register usage, and other calling
conventions).

Interestingly, the standard avoids specifying what a language linkage
(either C++ or C) must or should entail, leaving it to the
implementation. So I suppose that instead of C++ name mangling we
could have had some other mechanism. I also read it to mean that, in
principle, C and C++ linkages are allowed to use different calling
conventions. At any rate, it is undefined behaviour to call a
function through an expression with a different language linkage;
e.g., to use a pointer to a static member function where a "C"
function is expected. (I have a vague idea of the real world
implications of the last rule, but I don't see a reason not to follow
it).

That is all technically true, but practically speaking, it is name-
mangling that is the significant difference when mixing C and C++ (at
least when using compilers from the same vendor).

Gregg

 

[Sergei]

That is all technically true, but practically speaking, it is name-
mangling that is the significant difference when mixing C and C++ (at
least when using compilers from the same vendor).

Not sure it is true even in a majority of cases. For instance, in my latest
project I had to access
a third party DLL exporting "C" functions from my C++ program using
GetProcAddress(). The function was resolved
by name just fine, but when trying to call it I was getting that MS runtime
( ESA (sp?)) error about calling convention until I typedef-ed
the type that I was using to store the pointer to resolved function with
"extern "C"" . Then it worked.

Sergei

 

[Jerry Coffin]

[ ... ]

That is all technically true, but practically speaking, it is name-
mangling that is the significant difference when mixing C and C++ (at
least when using compilers from the same vendor).

That's not really accurate -- quite a few compilers typically use
different calling conventions between the two languages. Since C can
be written without prototypes, C compilers often default to argument
passing that can withstand differences between the number of arguments
passed and number of arguments expected by the function.

In C++, function declarations are required. Since we know the
arguments in the call match those expected by the function, they can
use a more efficient calling convention.

In reality, the name mangling mostly just prevents you from making
calls that would just crash and burn anyway.

 

[Victor Bazarov]

[..] Since C can
be written without prototypes, [...]

Not since 1999 it can't.

V