Alf said:
I can repeat that quote again, though I don't know why you don't just
read it in my previous posting. So again, I said:
those things [calling convention, data types etc.] are all part
of the linkage.
And you said:
to which I agree, but not to:
I quoted the following sentence from the standard:
All function types, function names and variable names have a language
linkage. [Note: Some of the properties associated with an entity with
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. ]
It says that "a particular calling convetion, etc." is no less part of
the "language linkage" than "a particular form of representing names of
objects and functions with external linkage". That's what I said above
and you claimed to be "not correct".
Besides that, of course the code is not compatible with every C
compiler, but from what I read from the standard (Every implementation
shall provide for linkage to functions written in the C programming
language, "C", and linkage to C++ functions, "C++".), there must be at
least one C compiler that it's compatible with. How else would the
compiler be able to "provide linkage to functions written in the C
programming language"?
Keep in mind that the C++ standard stems from 1997, and that 1997 <
1999.
What does that have to do with each other?
As a concrete example, Visual C++ supports a number of different
calling conventions such as "__stdcall" (which oldtimers like me think
of as Pascal) and "__cdecl" (which we think of as "C", purely because
of typical usage). If you decorate a function with 'extern "C"',
then (with this widely used compiler) that does _not_ affect the
calling convention. It affects only the external name the linker sees
(wrt. to the standard there's not necessarily a linker involved, but
this scheme is, as far as I know, completely standard-conforming.)
The crux is that there's no such thing as "the" C compiler.
Yes, that seems to be a quality-of-implementation issue. But as I said,
I'd expect from a C++ compiler that is bundled with a C compiler that
by default both use the same C "language linkage", including calling
conventions.
There are a number of different C compilers, and even using just one
compiler you can compile functions that look the same to the linker
(and so, no amount of fiddling in C++ can guarantee compatibility) but
which have different calling conventions, different sizes of int, or
whatever.
Yes. What's your point?
Ok, so what would be more portable then?