From -4863436134944750239
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f78e5,e94695845965b249
X-Google-Attributes: gidf78e5,public
X-Google-ArrivalTime: 1992-12-09 21:25:04 PST
Newsgroups: comp.std.c++
Path: sparky!uunet!microsoft!hexnut!jimad
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: Zero-length structures and pointer comparisons
Message-ID: <1992Dec09.215427.25661@microsoft.com>
Date: 09 Dec 92 21:54:27 GMT
Organization: Microsoft Corporation
References: <1992Dec02.212336.26703@microsoft.com> <1992Dec4.093044.16823@jyu.fi> <1992Dec8.193218.13165@ucc.su.OZ.AU>
Lines: 57

In article <1992Dec8.193218.13165@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
|	It doesnt have to. Jim explained what the implications are to
|me, and if I have it right a strictly conforming program should
|work on any compiler//machine, i.e. be portable, but a merely
|conforming one might be quite system specific.

To quote from the ANSI-C rationale:

EXITSTING CODE IS IMPORTANT, EXISTING IMPLEMENTATIONS ARE NOT.
A large body of C code exists of considerable commercial value...
...The Committee did not want most programmers to modify their
C programs just to have them accepted by a conforming translator...

[Note: an "existing implementation" is not just a C++ compiler, but
 also the OS the code runs on and the tools available.  The systems 
 that C++ needs to run on must be able to change too -- not just the
 C++ compilers]

C CODE CAN BE PORTABLE...The Committee has attempted to specify
the language and the library as widely implementable as possible....

[Note: specifying the language in a manner that helps make programs
 portable at the expense of making the language less widely implementable
 does nothing to improve portability -- on the contrary!  We want C++ to
 be implementable on almost all CPUs and systems of the 1990s and the 2000s
 Not only Un*x machine, not only PCs, but also mainframes, vector processors,
 Lisp machines, OOArchitectures, connectionist machines, embedded processors
 inside of toaster ovens, etc]

C CODE CAN BE NON-PORTABLE.  Although it strove to give programmers the
opportunity to write truly portable programs, the Committee did not want
to FORCE programmers into writing portably, to preclude the use of C
as a "high-level assembler": the ability to write machine-specific code
is one of the strengths of C.  It is this principle which largely 
motivates drawing the distinctions between STRICTLY CONFORMING PROGRAM
and CONFORMING PROGRAM.

[Note: In that C++ allows such "high level assembly" to be packaged inside
 the inner workings of a class, C++ even better supports such "high level
 assembly".  There is no reason why the inner mechanisms of one class can't
 be implemented in two different manners on two different machines.]

AVOID "QUIET CHANGES."....As much as seemed possible consistent with its
other goals, the Committee has avoided changes that quietly alter one
valid program to another with different semantics, that cause a working
program to work differently without notice....

A STANDARD IS A TREATY BETWEEN IMPLEMENTOR AND PROGRAMMER.....

KEEP THE SPIRIT OF C....
	* TRUST THE PROGRAMMMER
	* DON'T PREVENT THE PROGRAMMER FROM DOING WHAT NEEDS TO BE DONE.
	* KEEP THE LANGUAGE SMALL AND SIMPLE [okay, so we lost that one....]
	* PROVIDE ONLY ONE WAY TO DO AN OPERATION [shucks, lost that one too...]
  * MAKE IT FAST, EVEN IF IT IS NOT GUARANTEED TO BE PORTABLE.

[quotes extracted from the first couple pages of the ANSI-C RATIONALE]