Re: What is the different between c++ call convention and c call
convention?
On Dec 7, 6:22 am, Jack Klein <jackkl...@spamcop.net> wrote:
On Thu, 6 Dec 2007 19:25:57 -0800 (PST), dolphin
<jdxyw2...@gmail.com> wrote in comp.lang.c++:
What is the different between c++ call convention and c call
convention?Can some give some examples?
Neither C nor C++ define a "calling convention". Particular
compilers provide their own "calling conventions", generally
based on the underlying processor architecture and usually
also on the operating system that the code will run under.
And it may vary from one compiler to the next.
Most systems today have defined a system specific API for C, to
which all C compilers adhere. When you declare a function
`extern "C"', that is the calling convention the C++ compiler
uses. The C++ standard, however, cannot make any such
requirements---it only defines C++, not C. If the system
doesn't define a specific API for C, and C compilers differ,
then I would expect the C++ compiler to document which C
compiler it expects when you write `extern "C"' (or provide a
command line option to specify which one you want); if you use
another, it may not work. And if there is no C compiler
available for the platform, `extern "C"' won't work, regardless
of what the standard says (but in practice, I don't think there
will ever be a platform with C++ but without C).
If you are interested in the calling conventions for a
particular compiler on a particular, you need to ask in a
newsgroup for that particular compiler/platform combination.
On the other hand if you are talking about linkage, as when
use:
extern "C"
Language linkage is the way you specify the calling convention
in a C++ program.
...in a C++ program, that is defined by the C++ standard
although the details are compiler specific.
The syntax is defined by the standard. As is the intent. As
stated above, if the platform doesn't have a C compiler, it
still won't work. Formally, too, a C++ compiler of brand X
could specify that its `extern "C"' worked with the brand X C
compiler (and no other), which costs $1000000 and has a delay of
two years to deliver. (In other words, if you buy it and pay
for the development, we'll develop it, but until then...)
Realistically, of course, most of us work on a platform with a
standard C API already defined, and as a quality of
implementation issue (respected by all real compilers), `extern
"C"' will match that.qp
A C compiler can use a very simple linkage model, where the
compiled output from multiple source files is linked together
with libraries. That is because in C, any given external
symbol can be defined once and once only.
What does that have to do with the linkage model, per se? On
all of the platforms I currently work on, C and C++ actually use
an identical linkage model, differing only in the way they
encode function names. But this isn't necessarily always the
case; I've used systems where the calling conventions for C and
for C++ were different. (The original Zortech compiler for C++
on Intel, for example, used the Microsoft C conventions for C,
but used a more intelligent convention fo C++.)
If you have a function:
int some_func(int);
...in a C source file, there can't be any other object with
external linkage using the symbol "some_func" in a program.
That's a rule of C. It has nothing to do with the calling
conventions (or language linkage).
C++, on the other and, allows multiple functions to have the
same name, due to overloading:
int some_func(int);
double some_func(double);
long some_func(long);
...so it must somehow modify these names in the output files
so the linker can connect the right call to the right
function.
It has to make it work. Historically (before templates, etc.),
C++ used a linker designed for C, and incorportating the
complete signature into the name was the simplest solution. But
at least one linker I once used (before I knew C, even) handled
type information directly. If you declared a function as "int
f()" in one translation unit, and as "void f(int)" in another,
it complained.
If you define a function in a C++ program with extern "C", you
tell the C++ compiler to generate its linkage name the same
way a compatible C compiler would.
No. You tell the C++ compiler to generate whatever is necessary
to call the function from C, or to implement it in C. That
means using the calling conventions of whatever C compiler
you've documented that you support (or in the more frequent
case, the system defined C API).
You also tell the C++ compiler that the function has a different
type. You can't assign an `extern "C" void f()' to a `void
(*pf)()', and you can't assign an `extern "C++" void f()' to an
`extern "C" void (*pf)()'.
The intent, which is not actually guaranteed, that this allows
you to combine both C code (compiled with a C compiler) and
C++ code into a single program. Almost all C++ compilers also
provide C compilers and so this method works when the C++ and
C code are compiled with the same compiler.
It also works regardless of the C compiler, if the platform
defines a C API, and all of the C compilers respect it. I
regularly link code compiled with g++ with libraries written in
C and compiled with Sun cc. Under Windows, if you're not using
VC++, you almost certainly also link with libraries written in C
(or providing an interface defined with `extern "C"') compiled
with the Microsoft compiler.
On a Sparc, of course, the way the hardware supports function
calls really only leaves one possible convention, so there is no
practical difference between the calling conventions of C and of
C++, except name mangling. On an Intel, it depends; it depends.
I've seen several different conventions, and Microsoft seems to
use some non-standard extensions to support them. I don't know
the defaults, but it does work.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34