From -6290812550073303139
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f78e5,e94695845965b249
X-Google-Attributes: gidf78e5,public
X-Google-ArrivalTime: 1992-11-07 02:57:09 PST
Newsgroups: comp.std.c++
Path: sparky!uunet!news.tek.com!uw-beaver!uw-coco!nwnexus!ole!ssc!eskimo!seanews!jimad
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: Zero-length structures and pointer comparisons
Message-ID: <1992Nov05.182917.14657@microsoft.com>
Date: 05 Nov 92 18:29:17 GMT
Organization: Microsoft Corporation
References: <1992Oct28.184135.25475@ucc.su.OZ.AU> <1992Oct30.003946.10484@microsoft.com> <1992Nov4.071814.10880@ucc.su.OZ.AU>
Lines: 54

In article <1992Nov4.071814.10880@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
|	Yes, I see. You are saying that by upgrading the requirements
|to a total order existing confrming programs which are not strictly
|conforming suddenly become non-conforming and are thus broken.

Yes, exactly.

|	Yes, I understand now I think. Leaving things 'implementation
|defined' is then a complete barrier to ever upgrading those things
|to be defined by the language without possibly breaking existing programs.

Yes, except the word is not "possibly" but rather "probably" because
the vast majority of programs written are written in non-portable manner
by programmers who neither understand nor care about portability.  Unfortunate,
but true.

I'm not saying that you can't ever change an "implementation defined" to
a "language defined" -- it just that you need to understand that such changes
are *major* changes to the language -- not *minor* changes, and you better
be darned sure that everyone buys into the associated cost.  Because a
lot of programs are going to be suddenly busted, and a lot of compiler
vendors are going to be solidly cursed by 100s or 1000s of customers for
"gratuitously" changing their compilers in ways that suddenly "bust" programs
that use to be "correct."  And such customers are right --  their programs
were "correct" -- just not strictly conforming.

|	It might be the case if the class used < for the purpose
|Andrew mentioned, and was otherwise a general purpose class.
|This makes the class (rather than the program) the thing that we want
|to make portable, i.e. the unit of reusability.

Agreed.  But note that requiring strict ordering would also make this
class non-portable non-reusable on systems using C++ OODBMSs -- because
you can't reasonably maintain a total ordering over a DB over a series of
complete or partial passivations/activations.  Also merging/splitting DBs
accross several computer systems becomes problematic if one assumes a total
ordering.

|	I have not had access to these proceedings so know nothing
|about previous battles. This sort of thing happens all the time here,
|it would be good if there were better access to the proceedings,
|as I'm sure you'll agree :-)

I agree, but the battles I was referring to happened even more moons ago
in the ANSI-C committee.  The ANSI-C committee was pretty smart.  Things
left implementation-defined were hard-won compromises between two or more
groups that couldn't agree and so agreed to not agree.  Unfortunately, such
has also got to be true of the ANSI/ISO-C++ effort.  You can only standardize
what people widely agree to.  Everything else has to remain implementation
defined.  If one faction or the other was truly "correct" in their strongly
held position, then one can only assume their compilers will ultimately win
in the marketplace -- and maybe could be agreed upon at the C+n standardization
effort ;-)