C++ vs C linkage (difference between the two)

[Nimmi Srivastav]

Once and for all can someone kindly tell me the difference between C
and C++ linkage. I thought I understood it till someone showed me the
other day that C functions, that would ordinarily require the
extern "C"

declaration, for correct linkage into a C++ program, don't need it if
the filename, in which they are defined, ends in .cc or .cpp! Can
anyone explain this in a rational manner?

For the record, this is what I have heard regarding the difference
between c and c++ linkage:

Function names with C++ linkage get "mangled" by a C++ compiler to
include the parameters, return type etc. Function names with C
linkage are not subjected to any such name mangling. By default the
linker will look for the "mangled name", rather than the actual name,
unless the we use extern "C". Is this explanation correct? Is there
anything else to it that I am missing?

Thanks,
Nimmi

[Alf P. Steinbach]

On 20 Sep 2003 05:53:34 -0700, ni*************@yahoo.com (Nimmi Srivastav) wrote:

Once and for all can someone kindly tell me the difference between C
and C++ linkage. I thought I understood it till someone showed me the
other day that C functions, that would ordinarily require the
extern "C"

declaration, for correct linkage into a C++ program, don't need it if
the filename, in which they are defined, ends in .cc or .cpp! Can
anyone explain this in a rational manner?
It's highly tool-dependent.

Neither the C nor the C++ standard define name mangling or machine code
level linkage.

The C++ standard, however, defines 'extern "C"' for use with C functions,
without quite defining things (iow., it's tool-dependent, but any
compiler _must_ offer a way to link with C functions via 'extern "C"').


For the record, this is what I have heard regarding the difference
between c and c++ linkage:

Function names with C++ linkage get "mangled" by a C++ compiler to
include the parameters, return type etc.
Often but not necessarily. It's one way (among many possible) to
achieve global static type-checking, required by the standard.

Function names with C linkage are not subjected to any such name
mangling.
They nearly always are, but a simpler form. Typically (but remember
this is tool-dependent) an underscore is added in front of the name.
With typical Windows compilers the mangling also depends on the calling
convention, which for such compilers is _independent_ of 'extern "C"'
(remember, the compiler only has to offer a way to call C functions
declared as 'extern "C"'; how it does that is up to the compiler), and
can include such things as a suffix '@n' where IIRC n is the amount with
which the function should adjust the stack when returning.

By default the
linker will look for the "mangled name", rather than the actual name,
unless the we use extern "C". Is this explanation correct? Is there
anything else to it that I am missing?

Yes, that it's all _very_ tool-dependent, not specified by the standard.

For specifics ask in a group related to the relevant compiler/system.

[Buster]

"Nimmi Srivastav" <ni*************@yahoo.com> wrote

Once and for all can someone kindly tell me the difference between C
and C++ linkage. I thought I understood it till someone showed me the
other day that C functions, that would ordinarily require the
extern "C"
declaration, for correct linkage into a C++ program, don't need it if
the filename, in which they are defined, ends in .cc or .cpp! Can
anyone explain this in a rational manner?
Example: you have files "function.c", "function.h", "main.cpp".

// function.c
#include "function.h"
int function (int x) { return x; }

//function.h
int function (int);

//main.cpp
extern "C" {
#include "function.h"
}
#include <iostream>
int main () { std::cout << f (0) << '\n'; }

Compiling "function.c" with a C compiler creates an object file
containing unmangled names. The extern "C" block around the
declaration of function () lets the C++ linker find the C names.

However, if "function.c" is renamed to "function.cc" (or .cpp) and
compiled with a C++ compiler, the extern "C" block is no longer
needed (in fact, leaving it in will cause linker errors), because
the names in the object file have mangled C++ names. Note that
this only works when the contents of the file is a well-formed
C program and also a well-formed C++ program, and that even
then it's possible for the code to mean different things in the two
languages.

It seems as though your system is set up so that files ending in .c
are automatically compiled with the C compiler and files ending
in .cpp or .cc with the C++ compiler. (Some compilers for both
languages will do this by themselves, or you can set it up with a
Makefile or in an IDE.)
For the record, this is what I have heard regarding the difference
between c and c++ linkage:

Function names with C++ linkage get "mangled" by a C++ compiler to
include the parameters, return type etc. Function names with C
linkage are not subjected to any such name mangling. By default the
linker will look for the "mangled name", rather than the actual name,
unless the we use extern "C". Is this explanation correct? Is there
anything else to it that I am missing?

(a) In the object file created by compiling a translation unit as C++,
all external symbols have C++ linkage unless you request a different
linkage.

(b) The filename extension sometimes determines which compiler
is used.

Hope that helped.
Buster

[Jack Klein]

On Sat, 20 Sep 2003 13:03:18 GMT, al***@start.no (Alf P. Steinbach)
wrote in comp.lang.c++:

On 20 Sep 2003 05:53:34 -0700, ni*************@yahoo.com (Nimmi Srivastav) wrote:

Once and for all can someone kindly tell me the difference between C
and C++ linkage. I thought I understood it till someone showed me the
other day that C functions, that would ordinarily require the
extern "C"

declaration, for correct linkage into a C++ program, don't need it if
the filename, in which they are defined, ends in .cc or .cpp! Can
anyone explain this in a rational manner?

It's highly tool-dependent.

Neither the C nor the C++ standard define name mangling or machine code
level linkage.

The C++ standard, however, defines 'extern "C"' for use with C functions,
without quite defining things (iow., it's tool-dependent, but any
compiler _must_ offer a way to link with C functions via 'extern "C"').

I would be very surprised if you could come up with anything in the
C++ standard that requires a C++ implementation to actually produce
output capable of linking with output produced by any C compiler.

extern "C" provides a mechanism for a programmer to express a concept
to the compiler, and allows the compiler to attempt to provide what
the programmer wants. It describes an intent, not a requirement in
the usual sense of the word.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

[Alf P. Steinbach]

On Sun, 21 Sep 2003 19:25:38 GMT, Jack Klein <ja*******@spamcop.net> wrote:

On Sat, 20 Sep 2003 13:03:18 GMT, al***@start.no (Alf P. Steinbach)
wrote in comp.lang.c++:

On 20 Sep 2003 05:53:34 -0700, ni*************@yahoo.com (Nimmi Srivastav) wrote:

>Once and for all can someone kindly tell me the difference between C
>and C++ linkage. I thought I understood it till someone showed me the
>other day that C functions, that would ordinarily require the
>extern "C"
>
>declaration, for correct linkage into a C++ program, don't need it if
>the filename, in which they are defined, ends in .cc or .cpp! Can
>anyone explain this in a rational manner?
It's highly tool-dependent.

Neither the C nor the C++ standard define name mangling or machine code
level linkage.

The C++ standard, however, defines 'extern "C"' for use with C functions,
without quite defining things (iow., it's tool-dependent, but any
compiler _must_ offer a way to link with C functions via 'extern "C"').

I would be very surprised if you could come up with anything in the
C++ standard that requires a C++ implementation to actually produce
output capable of linking with output produced by any C compiler.

Okay, just this once: §7.5/3: «Every implementation shall provide for
linkage to functions written in the C programming language, "C"»,
followed by an example (next time please look up things yourself).

You should not be surprised since that was a main design consideration
for C++.

So _why_ are you surprised?

extern "C" provides a mechanism for a programmer to express a concept
to the compiler, and allows the compiler to attempt to provide what
the programmer wants. It describes an intent, not a requirement in
the usual sense of the word.

That is incorrect. But the opposite extreme, that a function declared
with «extern "C"» is necessarily compatible with a C function, is also
incorrect. The requirements by the standard are as I described earlier.

Hth.,

- Alf