🚀 go-pugleaf

I could not agree more with Fergus in this count.

- Saroj

[ The rest of the article is quoted material.
I decided to err in favour of inclusion, since after all
it was me that Saroj was quoting ;-)  -moderator (fjh). ]

In article 7618@mulga.cs.mu.OZ.AU, fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:
> 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
---
[ 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. ]