Re: C/C++ calling convention
On Aug 25, 6:34 pm, "BGB / cr88192" <cr88...@hotmail.com> wrote:
"James Kanze" <james.ka...@gmail.com> wrote in message
news:76ae0f08-dec7-448d-9bde-33f616bdadfc@x25g2000yqj.googlegroups.com...
On Aug 25, 3:50 am, "BGB / cr88192" <cr88...@hotmail.com> wrote:
"Ian Collins" <ian-n...@hotmail.com> wrote in message
news:8dir1pF1saU13@mid.individual.net...
On 08/25/10 08:56 AM, Stanislaw Findeisen wrote:
Given an architecture and a language (C or C++), is there any standard
function calling convention? Or is it compiler dependent?
The two languages are different. With C, there will be a platform
standard, with C++ it is still (regrettably) compiler specific.
yep...
however, typically, C++ uses the same basic calling
convention as C, but usually differing only in that the C++
case tends to use a name-mangling scheme (often compiler
specific, but some "de-facto" conventions exist, for
example the use of MSVC-like conventions on Windows and the
IA-64 ABI name-mangling on Linux).
How can it? Things like the layout of the vtable are part
of the calling conventions, and C++ can't possibly use the
same ones as C here.
simply:
C doesn't have vtables (or, at least, compiler generated ones);
in the C++ case, they are structures.
effectively, then, vtables are part of the ABI, but are not part of the
calling convention.
The calling convention and the ABI are basically two words for
the same thing.
there does tend to be a difference in how compilers pass
'this', with some compilers using an additional register
(thiscall in MSVC), but more commonly it is passed as a hidden
first argument (although AFAIK usually after the hidden first
argument used for returning structs).
Except on Intel, the first argument *is* usually in a register.
(On rereading it, I find my phrase a bit ambiguous. The "Except
on Intel" should apply to what I've written. On architectures
other than Intel, the first argument (or the first n
arguments---5 on a Sparc) are passed in registers.
not in cdecl or stdcall...
cdecl and stdcall tend to pass *everything* on the stack.
What is cdecl or stdcall? They don't exist on most compilers
I've used. And as I said, except on Intel, the first
n arguments are normally passed in registers.
although, it is not really "safe" to rely on the specifics of
any of this...
similarly, it is not really "safe" to use C++-based APIs
across library boundaries, nor for that matter to pass memory
or file references between DLL's (this leads to "fun"
sometimes...).
That's not true, and I've done it on many platforms.
something can easily "work" in many cases, but still not be
"safe" in a portability sense.
For what definition of "safe"? You define the constraints of
your library (usually, by specifying what options must be used
when compiling code which links to it). If the user conforms to
those constraints, there's no problem.
if one can do it, they can declare that it "works on most
platforms of interest", which may exclude some edge cases (for
example, most PC or server targetted code will not work on
embedded systems, ...).
Well, obviously, you can't write a portable dll which will work
on a system which doesn't have dlls.
as for C++ ABI's, the main issue is that MSVC and MinGW on
Windows use different C++ ABI's, and so if one wants to
support use of either compiler (with pre-existing binary
code), it is best to avoid using C++ as a basis for API's.
VC++ and g++ both change the C++ ABI depending on compiler
options. So what else is new? Your client code must be
compiled with the same compiler (or one which guarantees binary
compatibility), using the same options.
other compilers tend to have other ABI's as well, and so this
leaves the C ABI as the "most portable" option.
I think we're talking at cross purposes. For binary
compatibility, yes, C is the only real solution. I was talking
about source code compatilibity.
using 'extern "C"' generally works without issue though, so
long as one fully adheres to C restrictions at the API level.
for example, MSVC likes giving each DLL its own local C library,
MSVC does what you tell it in this regard. If you tell it to
give each DLL its own local C library, when you don't want to,
it's nobody's fault but your own.
this is the default behavior. one has to tell it to do
otherwise, but then it uses 'msvcr80.dll', which has to be
supplied manually on WinXP.
I'm not aware of any "default" behavior. When I type in "cl
/help", it tells me to chose one of /MT, /MTd, /MD or /MDd
(indirectly, at least). And every Windows application I've
worked on uses /MD or /MDd, which doesn't cause any problems.
and hence, its own local memory heap and set of open files,
resulting in a few issues which may pop up occassionally...
(these issues don't tend to pop up with MinGW or Cygwin, as
these handle this situation differently...).
I don't know about MinGW or Cygwin, but under most Unix, it's
also possible to arrange things so that each shared object has
its own free space arena as well, if this is what you want.
yes, but this is not necessarily a desirable feature, and is
actually kind of annoying sometime...
It depends on what you're doing. If you're supporting third
party plugins, you'd like them to be as isolated as possible.
--
James Kanze