🚀 go-pugleaf

In article <1995Aug1.105954.1403@ittpub> wil@ittpub.nl (Wil Evers) writes:
>> I can't understand why the committee is having such a hard time over this  
>> issue. Why not just require a C++ implementation to specify with which C  
>> compiler(s) (and versions) it is compatible on a given platform?

ark@research.att.com (Andrew Koenig) writes:
>Such a requirement is uninteresting, because
>a vendor can simply say `Our C++ implementation is not
>compatible with any C compilers' and meet the requirement
>that way.

So let them (that way, users will be warned away from such compilers).
For extern "C" to have any meaning at all, it must mean "this function is
assumed to obey the conventions of C functions provided by <some C
compiler>".  Remember that not all C compilers for a given platform
necessarily produce completely interoperable code.

In any case, many common compiler packages provide both C and C++
compilation in a compatible way (Borland, Microsoft, GNU, and about every
Unix C++ compiler I know of), or are by construction compatible with an
available C compiler (cfront).  This compatibility is generally strong
enough that the only difference between C and C++ is name mangling (so the
qsort problem is not a problem in practice).  One question to be addressed
is whether extern "C" could refer to a completely different convention for
argument-passing, in which case qsort is a problem, function pointers need
an extern "C" tag, etc.  But even if this convention can be different, it
still must correspond to a particular [set of] C compiler[s].

-- 
-- Joe Buck 	<jbuck@synopsys.com>	(not speaking for Synopsys, Inc)
Anagrams for "information superhighway":	Enormous hairy pig with fan
						A rough whimper of insanity