🚀 go-pugleaf

In article <DCErIA.IJt@research.att.com> ark@research.att.com (Andrew  
Koenig) writes:
> In article <9520904.20645@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU  
(Fergus Henderson) writes:
> 
> > The ARM and the draft standard are certainly not clear on the issue,
> > and 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?  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?
> 
> 	2. Suppose the C compiler vendor changes linkage conventions
> 	incompatibly.  Does that invalidate the C++ compiler?
> 
> 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.  If the answer is `no,' it is hard to see how
> to write a requirement for compatibility.

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?

- Wil