🚀 go-pugleaf

matt@godzilla.EECS.Berkeley.EDU (Matt Austern) writes:

>wil@ittpub.nl (Wil Evers) writes:
>
>> I know it's late, but with hindsight, allowing a C++ compiler to use
>> different calling conventions from the underlying C compiler was probably
>> a mistake.
>
>I don't think there's any choice about that decision:

I respectfully disagree.

>there's no
>guarantee that any particular C++ implementation has an underlying C
>compiler at all. In fact, most C++ implementations that I'm aware of
>compile C++ directly to machine code without ever passing though C.

There's no guarantee that the C implementation has an _underlying_ C
compiler, but the ARM [7.4] and the draft working paper [7.5] do state that

"Linkage to a function written in the C programming language ...
must be provided by every implementation".

While others have interpreted that differently, to me it seems pretty
clear, and existing practice seems to back it up 100%.

>It's likely that most programmers out there have one or more C
>compilers on their machines, but what good is that from the point of
>view of the C++ standard?  How could we conceivably word a requirement
>about interoperability between a C++ implementation and some other
>random C implementation?

There are several ways.

1.  Require each conforming C++ implementation to include a
conforming C implementation, and support interfacing between
the two.

This option would be not be too hard to state in the standard.
Whether or not it is a good idea is another question -
some parties might find this requirement too onerous.

2.  Define in the standard a notion of a "conforming combined C/C++
implementation", comprising of a conforming C implementation
and a conforming C++ implementation with an implementation-defined
mechanism for linking programs comprising translation units
written in C with translation units written in C++.
"Conforming C++ implementations" would not be required to support
interfacing to C, but "Conforming combined C/C++ implementations"
would.

This option would also not be too hard to state in the standard.
(The first sentence of the above paragraph would be nearly enough,
IMHO.)

3.  Don't bother to specify interoperability of C and C++.
Just specify that C++ programs can define functions with
extern "C" linkage, and specify that the addresses of
functions with extern "C" linkage and extern "C++" linkage
can be freely intermingled.  This side-steps the question,
but nevertheless gives an answer.

>That's totally outside the scope of a language standard.

No, it is not.  The Ada 95 standard defines requirements for Ada
implementations to interface to C, FORTRAN, and COBOL.  These
requirements are defined in one of the optional "Special Needs"
Annexes, so Ada implementations are not required to support interfacing
to any or all of these languages, but the requirements *are*
normative.  A conforming Ada implementation that does not support a
Special Needs Annex or part thereof must identify programs that use
unsupported features, either at compile time or by raising an exception
at run-time.  A conforming Ada implementation that claims to fully
support Annex B must allow interfacing with C, FORTRAN, and COBOL and
must abide by the semantics specified in that Annex.

--
Fergus Henderson              | Designing grand concepts is fun;
fjh@cs.mu.oz.au               | finding nitty little bugs is just work.
http://www.cs.mu.oz.au/~fjh   | -- Brooks, in "The Mythical Man-Month".
PGP key fingerprint: 00 D7 A2 27 65 09 B6 AC  8B 3E 0F 01 E7 5D C4 3F
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]