From -1493678795437347094 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,e94695845965b249 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 1992-12-08 09:23:19 PST Newsgroups: comp.std.c++ Path: sparky!uunet!mcsun!news.funet.fi!network.jyu.fi!sakkinen From: sakkinen@jyu.fi (Markku Sakkinen) Subject: Re: Zero-length structures and pointer comparisons Message-ID: <1992Dec8.143504.5590@jyu.fi> Organization: University of Jyvaskyla, Finland References: <1992Dec02.212336.26703@microsoft.com> <1992Dec4.093044.16823@jyu.fi> <1992Dec07.225634.19943@microsoft.com> Date: Tue, 8 Dec 1992 14:35:04 GMT Lines: 115 In article <1992Dec07.225634.19943@microsoft.com> jimad@microsoft.com (Jim Adcock) writes: >In article <1992Dec4.093044.16823@jyu.fi> sakkinen@jyu.fi (Markku Sakkinen) writes: >|-- In the last few years there _have_ been gratuitous changes in the language >|that have made fully standard code illegal (or perhaps worse still, legal but >|with changed behaviour). > >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! > ... >|So you say that most C++ compilers for the PC used to be more or less broken >|(could not implement the full language), and programmers were therefore forced >|to dirty tricks as work-arounds? > >No, on the contrary PC compilers implement the full language, its just that >the full language is something different that you desire it to be. Programmers >made use of that langauge in legal ways that you pretend to ignore, and now >you want to take their legal programs, declare those legal programs as "hacks" >and require that no PC compiler be allowed to support those legal programs >anymore. 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! > ... >On the contrary C++ pointers are NOT memory pointers. Two simple >counterexamples are null pointers and member pointers. You continue >to confuse language and implementation. 'Member pointer' is a confusing misnomer; I meant real pointers. A null pointer is a _very_ special case (not only in C and C++). My favourite interpretation is that every pointer type is actually an undiscriminated union of a true pointer type and null. > ... >|As long as we have C++ objects, i.e. in memory, their addresses (or at least the >|valid pointer values to access them) _must_ stay constant, because C++ has no >|means to automatically track down and modify all pointers to an object. > >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. >|If the contents of some object are copied to or from the DB, that does not >|change or complicate the situation. On the other hand, if some C++ object is deleted >|after having been copied to the DB, and the DB object is later restored into memory, >|it will be a _new_ C++ object. > >What you suggest violates the fundamental tenents of OODBMSs -- namely that >an object maintains its identity no matter in what medium it is stored. -- as long as it is _in_ the database. BTW, actually total order is a simple thing within an OODB _because_ the identity of each object is assured not to change. >| ... >|No, we don't require that the ordering should directly map into physical order, >|it's just as fine if a pointer consists of base and segment and relocation and index >|or whatever. Punning would do, i.e. treating the pointer as if it were an integer value. >|However, the ARM does not require implementations to provide an integral type >|that is sufficient to store an arbitrary pointer. > >Fine, then what you ask for is what PC compilers already provide. Its just >that what you are asking for then is insufficient to accomplish what you >want to do. Because PCs already allow pointers to be "punned" to ints, >its just that those ints are insufficient to store a pointer, and as >such you only get a partial ordering [over the offset part] rather than a >total ordering [over both segment:offset]. Oh dear! I am asking to treat _a pointer_ as an integer, not a _slice_ of a pointer; thus those compilers don't provide what I asked for. Any implementation that allows the conversion between pointers and some integral type and v.v., without loss of information, is fine. However, depending on such conversions 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. > Thus, again, as I've said >all along, your proposed implementation is a "hack" -- that is to say, it'll >only work on some conforming implementations, and not others. I was not proposing an _implementation_ but an additional rule to the language. Of course, any new rule is inconvenient to any existing implementation that does not already happen to obey it. > ... >"Pointers" have well established meaning in C/C++ -- they are not the >same thing as memory addresses. If you want to implement your program >in terms of memory addresses then implement it in terms of memory addresses. >Don't insist that pointers BE memory addresses. I already explained that the issue was not to program in terms of memory addresses! ---------------------------------------------------------------------- Markku Sakkinen (sakkinen@jytko.jyu.fi) SAKKINEN@FINJYU.bitnet (alternative network address) Department of Computer Science and Information Systems University of Jyvaskyla (a's with umlauts) PL 35 SF-40351 Jyvaskyla (umlauts again) Finland ----------------------------------------------------------------------