🚀 go-pugleaf

In article <3vo9lr$los@metro.ucc.su.OZ.AU>, maxtal@Physics.usyd.edu.au (John Max Skaller) writes:
-->In article <KANZE.95Jul25103036@slsvhdt.lts.sel.alcatel.de>,
-->James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de> wrote:
-->
-->>May I ask a question: why all these worries about qsort?  Why not just
-->>use sort (section 25.3.1.1)?  It is more flexible, and the benchmarks
-->>I've see suggest it is (as is to be expected) faster.

The point is: why are people only interested in qsort?  There are a million
and one third-party C libraries that I want to use plus quite a few
Fortran ones.
 
-->	It isn't clear it is POSSIBLE to use qsort.
-->Suppose extern "C" functions use a DIFFERENT calling convention.

So?  When I say a function is ``extern "C"'' I expect the compiler
to do what it takes to call that function.  If C functions use a
different calling convention to C++ functions I would expect the
compiler to deal with that just as it deals with different name-mangling
conventions.  A compiler that didn't would be pretty stupid!

Of course the problem with qsort is that it isn't possible to define
the calling convention of a pointer to a function.  This is a language
defect that ought to be rectified!  In fact, I was quite surprised
to find out that this wasn't the case.  A) It seemed such an obvious
requirement that I never imagined it wouldn't be supported.
B) I'm sure I have written

extern "C"
    {
    typedef int (*CFunction) (int);
    };

and had it compile successfully.

-->	Question 1: what is the calling convention of a function passed
-->to such a function -- C or C++? Answer: C because otherwise qsort
-->would not work.

Answer: it should depend on how the parameter is declared!

-->	Question 2: can you compile an extern "C" function in C++?
-->Answer: not necessarily. 

Answer: you should be able to.

...and I have written `` extern "C" { static int F (int i) { ...} }; ''!

-->	Question 3: can you call code compiled with a C compiler?
-->Answer: not necessarily.

Answer: you should be able to.  (Though obviously the C compilers supported
will depend on the C++ compiler being used.)

It's a pragmatic issue.  I want/need to be able to use libraries
written in a language other than C++.  I don't see that this
is asking too much.  (However, I can see that the Committee might
have a hard job translating such pragmatic considerations into
standardese.) 

As has been pointed out, ``extern "C"'' is a bit misleading in that it kind
of implies (and people often infer) that it means "implemented in the language C"
but it means "that follows the link-time/run-time function call convention
called `C'".  Those of us who have worked on the different Microsnot systems
with their various Pascal, syscall, fastcall, ... calling conventions are used
to the idea that a calling convention has nothing to do with the language of
implementation as almost none of the extern __pascal functions we called were
ever written in Pascal and there is no language called "syscall".

Thus, it is not always possible to give a unique definition ``extern "C"''
for any given platform.  (One might need several ``extern "C"''s, but that's not
a problem: one could easily have ``extern "C/Borland"'' and ``extern "C/Microsoft"''
as required.)  It's a compiler-dependent issue.  However, pragmatically speaking,
there's not really a problem as there is a generally accepted convention on
most platforms.

-- jP --