🚀 go-pugleaf

ark@research.att.com (Andrew Koenig) writes:

>fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:
>
>> [...] requiring C++ compilers to use the same calling convention as the
>> underlying C compiler is still an option that is very much open to
>> the committee.
>
>The committee has discussed this issue on and off for years,
>and no one has yet proposed a satisfactory solution.
>
>Here are a few questions that should help point out why this is a
>hard problem:
>
>	1. Suppose you have two mutually incompatible C compilers on
>	your machine?  Is every C++ compiler required to be compatible
>	with both of them? 

No, it clear that simply loading a new C compiler onto your hard disk
should not suddenly make your C++ compiler non-conforming.

>	If not, suppose your C++ compiler is compatible
>	with only one of them and you remove that C compiler.  Does that
>	invalidate the C++ compiler?

Suppose your hard disk crashes.  Does that invalidate the C++ compiler?

(I think I've got the hang of a questions arms-race now ;-)

Let me answer my question first, and then yours.  If I have Foobar C++
on my hard disk, and it crashes, that does not mean that Foobar C++ is
not a conforming C++ implementation.  To be pedantic, talking about
whether or not Foobar C++ is a conforming implementation is a
convenient simplification which breaks down in this situation.  Really
we ought to only talk about the conformance of a particular computer
system ("processor", to use the draft standard's terminology) --
comprising of not just software, but also hardware and documentation.
If my hard disk crashes, then the computer system sitting on my desk is
not conforming, but of course Foobar C++ may still be part of some
other conforming computer system whose hard drive has not crashed, and
Foobar Inc. are certainly still justified in claiming that their
product conforms to the standard.

Now, suppose the C++ standard were to require that C++ implementations
support interfacing to C.  Pedantically, you still can't talk about
whether Foobar C++ is conforming; you have to talk about the
conformance of a whole computer system.  If the C++ standard were to
require implementations to support interfacing to C, then said computer
system must clearly include a C compiler (or interpreter, etc.).
Foobar C++ can still certainly claim conformance to the standard, even
if it does not come packaged with a C compiler.  After all, it doesn't
come packaged with a machine to run it on either!  Instead, there is
usually a little note on the box - "requires an IBM compatible with a
386 or better and at least 8M of RAM and 100M of disk space, running
Microsoft Windows" or something similar.  If Foobar C++ also requires
Quux C to support the requirements in the C++ standard about
interfacing to C, then they should document that too - but they can
certainly still claim conformance to the standard.

As before, if I remove the C compiler from my hard drive, or if my hard
drive crashes, or if the power supply suddenly dies with a loud bang
and a big cloud of black smoke (this has happened to me! ;-), then the
computer system on my desk no longer comprises a "conforming
processor", according to the definition in the C++ standard.  But that
doesn't affect the right of Foobar Inc. to claim conformance with the
C++ standard.

>	2. Suppose the C compiler vendor changes linkage conventions
>	incompatibly.  Does that invalidate the C++ compiler?

Supposing the OS vendor changes linkage conventions incompatibly [*].
Does that invalidate the C++ compiler?

	[*] This is not just hypothetical.  SGI changed the linkage
	conventions incompatibly between Irix 4.x and 5.0.  When our
	site upgraded, it broke the compiler (for Mercury, not C++)
	that I and my colleagues have been writing.  Fixing it was
	a decidedly non-trivial undertaking.

The answer to these questions is the same as before.
The Foobar C++ documentation should state which version(s) of the
the Quux C compiler and which version(s) of the linker, program loader,
extended/expanded/ex-whatever memory manager, shell, and OS (and
any other software with which it must interact) it supports.
Obviously if you change any of the software in the computer system,
it may cause the resulting system to fail to be compliant.
But that is not Foobar Inc.'s fault.

>In both these cases, the question `Does that invalidate the C++ compiler'
>means `Does the vendor of this C++ compiler lose the right to claim that
>that compiler conforms to the standard?'
>
>If the answer is `yes,' that means that in effect one can produce a
>standard-conforming C++ compiler only by permission of the C compiler
>vendors for that machine. 

I don't agree.  Even if a standard-conforming C++ "processor" must
include a C compiler, that does not implies that the vendor of a
stand-alone C++ compiler cannot claim conformance with the standard.
Clearly a C++ compiler does not on its own constitute a
standard-conforming C++ "processor".  For that, you need at the very
least an OS and a machine to run it on.  I don't think it would be
unreasonable for the standard to require such a processor to also
include a C compiler.

>If the answer is `no,' it is hard to see how
>to write a requirement for compatibility.

The way it is done in the Ada 95 standard seems satisfactory to me -
perhaps not ideal, but certainly much better than throwing up our hands in
defeat in the belief that such a requirement cannot be phrased.

-- 
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