From 2859878590497807911 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,e94695845965b249 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 1992-11-03 17:32:10 PST Newsgroups: comp.std.c++ Path: sparky!uunet!charon.amdahl.com!pacbell.com!decwrl!elroy.jpl.nasa.gov!usc!rpi!batcomputer!munnari.oz.au!metro!extro.ucc.su.OZ.AU!maxtal From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) Subject: Re: Zero-length structures and pointer comparisons Message-ID: <1992Nov4.071814.10880@ucc.su.OZ.AU> Sender: news@ucc.su.OZ.AU Nntp-Posting-Host: extro.ucc.su.oz.au Organization: MAXTAL P/L C/- University Computing Centre, Sydney References: <1992Oct26.170404.1904@microsoft.com> <1992Oct28.184135.25475@ucc.su.OZ.AU> <1992Oct30.003946.10484@microsoft.com> Date: Wed, 4 Nov 1992 07:18:14 GMT Lines: 68 In article <1992Oct30.003946.10484@microsoft.com> jimad@microsoft.com (Jim Adcock) writes: >In article <1992Oct28.184135.25475@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes: > >| I dont understand. For a start, there is NO requirement >|that I can see that < is a partial order. Have I missed something? > >What you have missed is the implication of this statement. *No requirement* >is equivalent to a *Permission* for compiler vendors and programmers to >write compilers and programs making use of that *Permission.* Such compilers >and programs are perfectly legal and valid C and C++ compilers/programs. >They are *conforming* -- they're just not *strictly conforming* programs. 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. > >| As I understand it the rules are: >| >| 1) pointers to the same object compare == >| 2) within an array, < is a total order >| 3) In other cases < is implementation defined. > > 4) Don't gratuitously change C++ from C so as to break existing > legal C programs. 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. > >|Any program relying on some implementation defined order (3) cannot >|be portable. > >*It doesn't have to be portable to be legal!* [] >|If a total ordering was required, programs utilising >|this requirement would be portable. > >Nope. They would only become portable if this was the last non-portability >in that program -- hardly likely. 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. > >On the converse side, tons of previously legal but not *strictly* portable >programs would now become illegal. >Besides, total ordering would require non-flat model programs to become >bigger and slower. But you guys already know that. Now how about cutting >out the game playing -- this issue has already been fought out in the >ANSI C committees. Why reopen old ground? > 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 :-) -- ;---------------------------------------------------------------------- JOHN (MAX) SKALLER, maxtal@extro.ucc.su.oz.au Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA ;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------