Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!wuarchive!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim ADCOCK)
Newsgroups: comp.lang.c++
Subject: Re: extern "C"
Message-ID: <58046@microsoft.UUCP>
Date: 8 Oct 90 18:41:26 GMT
References: <1990Oct5.090712.7318@cs.nott.ac.uk>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Organization: Microsoft Corp., Redmond WA
Lines: 30

In article <1990Oct5.090712.7318@cs.nott.ac.uk> gas@cs.nott.ac.uk (Alan Shepherd) writes:
|Can someone explain the rational behind the fact that 
|
|	extern "C" foo();
|
|doesn't do what you'd expect (i.e. declare a function foo which has c
|linkage and as in pre-ANSI C, any number of arguments) but declares a C
|function with no arguments so that a call to foo("hello") for example
|results in an unexpected argument error ?  If the ansi option is
|specified to C++, this makes more sense, but it behaves exactly the same
|without the ansi option.  This makes it impossible to use old-style C
|header files without editting them which I thought the introduction of
|extern "C" was supposed to facilitate.

I'd expect the extern "C" directive to provide a mapping between the 
implementation of one C++ compiler and one C compiler.  Thus, the 
interpretation placed on declarations within a extern "C" directive 
depends on both the C++ implementation and the C implementation.  One
obvious problem is that a given C++ implementation probably only implements
one extern "C" directive -- but is the resulting "C" compiler being 
targeted a K&R C compiler, or an ANSI-C compiler?  Depending on your
K&R C compiler, and/or your ANSI-C compiler, the way pass parameters are
handled may be very different.  Like C++, an ANSI-C compiler may depend
on function prototypes to allow "Pascal"-style calling conventions be used,
which would not be applicable to K&R style compilers.  Bottom line to me
is: what goes on in an extern "C" directive is implementation dependent --
dependent on both a particular C++ compiler implementation and a particular
C compiler implementation [not to mention the linker the two implicitly have
in common]  Maybe if C++ compilers implemented both a "ANSI-C" and a 
"CLASSIC-C" directive things would make more sense.