From 7039121834171693444 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,e94695845965b249 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 1992-12-17 21:52:16 PST Newsgroups: comp.std.c++ Path: sparky!uunet!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: <1992Dec17.213129.7779@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: <1992Dec4.093044.16823@jyu.fi> <1992Dec07.225634.19943@microsoft.com> <1992Dec8.143504.5590@jyu.fi> Date: Thu, 17 Dec 1992 21:31:29 GMT Lines: 130 In article <1992Dec8.143504.5590@jyu.fi> sakkinen@jyu.fi (Markku Sakkinen) writes: >In article <1992Dec07.225634.19943@microsoft.com> jimad@microsoft.com (Jim Adcock) writes: >> >>Agreed, and in general those changes have been practical and well motivated. >>What you suggest is neither. On the contrary, you ask to legalize your >>favorite hacks. > >No, it's you who are crying for hacks: programs that happen to work >in a certain way because of the peculiarities of a certain compiler. >Now you think it has been OK to break many "strictly conforming" programs! BOTH hacks! OK? Jims is a 'hack' because it is machine and compiler and even memory model dependant. Fine. C was designed to handle that. It was designed for controlling hardware every bit as much, and maybe moreso, than general programming. Markku's is a hack because linear address machines, for which pointer comparison makes the most sense, are just one possible architecture. And one which went out of date many years ago I thought. Aren't von Neumann machines considered archaic? Isnt the segmented architecture (I mean real segments like the 386 not 8086 bank switching) just an extension of the Harvard architecture? Aren't BOTH of these going to become obsolete with the advent of distributed persistent object stores? > >You have been pleaded a dozen times to give an example. >Why don't you present one, so we can get this discussion on more >rational grounds! I presented one.. twice. If you want more, look at almost every C program ever written for the PC. Many use mixed pointer types. Here's an easy example from Microsoft's older libraries: memcpy(void*d, void*s, int n); Here d and s are only 16 bits. So they had better both reside in the Data Segment, or all hell breaks loose. This version of memcpy assumes this is the case. If you want 20 bit addresses, use far_memcpy(void _far * d, void _far * s, int n); (Or something similar, Borland's libraries never had this problem). While this isn't an example where total ordering matters, perhaps you might begin to see how bad things are for 8086 programmers. And perhaps you can understand that there are sure to be dependencies on pointers being ordered the 8086 way in 8086 code. On the 8086, they can be used just like 16 bit integers, and often are. A function ptrcmp(void*,void*); wouldnt work if the ptrs were 16 bits anyhow. The < version is bound to use that implementation for consistency. The true library function must be ptrcmp(void _far *, void _far *); >> >>Wrongo. Again you confuse language and implementation. On the contrary, >>I've written an internal implementation of C++ that does have the means to >>automatically track down and modify all pointers to an object. There >>are other systems that do this kind of thing too. Such as early versions of >>Windows. > >Maybe, but such a system must be terribly expensive in memory and >processor time; and your main motivation seemed to be to save >a couple of processor cycles. Windows was expensive on processor time in order to conserve memory. It had to run on the 8086, in 640K, and did. Pointers in Windows (real version) were not allowed, except for transient periods. It had automatic compaction, including chasing the stack for stack frames. It dumped read-only segments automatically, and reloaded them just as automatically when required. And the guys that wrote it are now the richest men in the US because of it. And more people us it than any other GUI. Dont laugh, Microsoft has NT running on MIPS, Unix beware! > >is not portable. Some people indeed want to write portable software, >and not only for a 1970s state-of-the-art Deci (one tenth) Operating System. Hey, others want to write for Unix, which is not much of an operating system compared to say OS/2 or NeXT either :-). > >I already explained that the issue was not to program in terms of >memory addresses! > How then does one write an operating system, device drivers, or any other code that MUST assume pointers are memory addresses? The problem is that pointers should be useful BOTH as memory addresses, and also as 'object accessors'. Really, operations like p++ should not be legal on pointers, but we're stuck with them. The real problem is that pointers have a meaning defined by prior C definitions, and so much code depends on those definition that its not possible to change them. Now if we could write proper object accessors efficiently and conveniently, we wouldn't need to use pointers .. except for machine level access. So perhaps we need operator.() and/or something else to be able to do this, because at the moment we cant emulate pointer behaviour in classes. Would it be more profitable to consider why this is, and what we can do about it? -- ;---------------------------------------------------------------------- JOHN (MAX) SKALLER, maxtal@extro.ucc.su.oz.au Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA ;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------