What is the different between c++ call convention and c callconvention?

[dolphin]

What is the different between c++ call convention and c call
convention?Can some give some examples?

 

[Jack Klein]

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.

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"

....in a C++ program, that is defined by the C++ standard although the
details are compiler specific.

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.

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.

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.

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.

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.

As to how the C++ compiler generates unique external names for the
linker from different functions with the same name in your source
code, the details are left up to the individual compiler. The common
mechanism is referred to as "name mangling".

Again, if you want to know how a particular compiler does "name
mangling", you need to ask in a group supporting that particular
compiler.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

 

[James Kanze]

On Thu, 6 Dec 2007 19:25:57 -0800 (PST), dolphin

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.

 

[terminator]

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).


Language linkage is the way you specify the calling convention
in a C++ program.


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


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++.)


That's a rule of C. It has nothing to do with the calling
conventions (or language linkage).


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.


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)()'.


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.

You are missing the fundamental difference between C and C+
+:incompleted structured programmimng style versus object oriented
programming style.In C you had no concept as construction and
destruction, therefore a function with C linkage(calling convention)
often does not call the destructor for its arguments(stack clean up is
more descriptive) and the chore is left to the caller,OTH a function
with C++ linkage is responsible for the destruction of its arguments
and leads to shorter overall code size.the difference is similar to
that of the 'exit' and 'throw'.

regards,
FM.

 

[Jack Klein]

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).

I was going to say that the C++ standard does not even mention the
term "calling convention", but I looked and it does, under the
description of linkage specifications.

It does not define the phrase, and only it once, in a parenthetical
note, speculating about the kind of implementation specific things
that a linkage specification might involve:

"[Note: Some of the properties associated with an entity with language
linkage are specific to each implementation and are not described
here. For example, a particular language linkage may be associated
with a particular form of representing names of objects and functions
with external linkage, or with a particular calling convention, etc.]"

Language linkage is the way you specify the calling convention
in a C++ program.


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

Are you sure that the actual platform API is actually a C API?

Through header and compiler magic, a platform API might actually be
quite different from even the native C API. Doesn't Windows have a
macro like "WINAPI" or "_WINAPI" or some such?

Consider a platform where system calls had to be made via a non-C
compatible interface. That used to be true of MS-DOS, and is true of
X86 Linux and parts of the Windows API today, where functions are
invoked via an x86 int instruction.

An implementer has several choices:

1. He can write wrapper functions that do have a C API, most likely
in assembly language, and in them do the specific magic required.

2. He can resort to compiler magic combined with non-standard
extended keywords in header files to generate the proper object code
sequence in line.

The second is more like what Windows does, I believe.

The point of all this is that if a system provides an API that is not
directly compatible with the C ABI, the implementer might well use
compiler/header magic to call such non-compatible functions, but
neither the C nor C++ standards require that an implementation be able
to generate a function with such an API.

I'm not trying to say that your post didn't amplify mine in some ways,
but mainly that this is really a complex ball of wax.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

 

[James Kanze]

On Dec 7, 5:56 pm, James Kanze <[email protected]> wrote:

[...]

You are missing the fundamental difference between C and C++:
incompleted structured programmimng style versus object
oriented programming style.

I don't think so. When I wrote C, it was completely structured
(and even a little OO). And my C++ style is very OO. (At least
my C++ at the application level.

In C you had no concept as construction and destruction,

And how is that relevant here? (Or to your previous phrase?)

therefore a function with C linkage (calling convention) often
does not call the destructor for its arguments(stack clean up
is more descriptive) and the chore is left to the caller, OTH
a function with C++ linkage is responsible for the destruction
of its arguments and leads to shorter overall code size.

You're confusing issues. We're talking here about the very low
level argument passing---the machine code level, in fact.
Obviously, C linkage or not, you can't pass a non-POD type by
value to C code. More generally, when passing between two
different languages, you have to map the types, and in some
cases, there will be no appropriate mapping.

The difference between C and C++, here, is that C++ has always
required a function prototype to be in scope, and doesn't allow
extra arguments (which are ignored). Officially, the rules in C
are not that different, and extra arguments are also forbidden.
But in C, this was an innovation by the C committee---most
earlier compiler would allow you to call e.g. printf without
having included <stdio.h>, and even today, most C compilers will
want to support this, even if the standard says it is undefined
behavior.

The difference is similar to that of the 'exit' and 'throw'.

You've lost me there? Exit and throw are two quite different
and unrelated mechanisms. What do either have to do with
function calling conventions, though?

 

[James Kanze]

@gmail.com> wrote in comp.lang.c++:

[...]

I was going to say that the C++ standard does not even mention the
term "calling convention", but I looked and it does, under the
description of linkage specifications.

It does not define the phrase,

It supposes the standard computer science definition.

[...]

Are you sure that the actual platform API is actually a C API?

If it's Posix, it is. Microsoft also defines calling
conventions for Windows.

Through header and compiler magic, a platform API might
actually be quite different from even the native C API.
Doesn't Windows have a macro like "WINAPI" or "_WINAPI" or
some such?

Who said anything about the low level platform API (which almost
certainly involves things which can't be expressed in C, since
it requires changing to privileged mode in a controlled manner).
All of the platforms I know do define a C level API, specifying
how a C program should pass its arguments, etc.

Consider a platform where system calls had to be made via a
non-C compatible interface. That used to be true of MS-DOS,
and is true of X86 Linux and parts of the Windows API today,
where functions are invoked via an x86 int instruction.

But that's irrelevant here.

[...]

The point of all this is that if a system provides an API that
is not directly compatible with the C ABI, the implementer
might well use compiler/header magic to call such
non-compatible functions, but neither the C nor C++ standards
require that an implementation be able to generate a function
with such an API.

The point is that every Posix platform, as well as Windows,
defines an API for C. Most don't (but there are
exceptions---including, I think, Linux on Intel) for C++. The
result is that you can freely mix object files compiled with
different C compilers in the same program, but you cannot for
C++.