From 1941456173098958281 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,e94695845965b249 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 1992-12-08 00:07:12 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: <1992Dec07.225634.19943@microsoft.com> Date: 07 Dec 92 22:56:34 GMT Organization: Microsoft Corporation References: <1992Dec1.072440.824@jyu.fi> <1992Dec02.212336.26703@microsoft.com> <1992Dec4.093044.16823@jyu.fi> Lines: 107 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. |Please don't mix up C into this, C++ _is_ a separate language. On the contrary, C++ _is not_ a separate language. Eiffel is a separate language. If there was not a need for backwards compatibility we could just chuck C/C++ and its shortcomings and start with a clean slate. |(I don't know about the drafts of the ANSI committee, but at least the ARM does not |use any terminology like 'conforming' and 'strictly conforming'.) This is because the ARM is a reference manual and not a standard. Once the committee has taken the *two* C++ base documents -- namely the ARM *and* the ANSI-C standard -- and molded the two into something worthy of being called a "standard" then the C++ standard will have to use terminology such as conforming, strictly conforming, constrained error, unconstrained error, etc -- or equivalent terminology of their own invention -- in order to be something worthy of being called a "standard." Because a standard must be something that is "testable" -- something of which we can reasonably and honest ask: "does this compiler conform to the standard?" "does this program conform to the standard?" "does this program compile correctly on any conforming compiler?" "does this program compile correct on every conforming compiler" ?? etc none of which can be asked meaningfully unless the eventual C++ standard contains language allow us to distinguish these kinds of cases. |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. |Please calm down (your throat will get sore if you use so many exclamation signs) |and try not to confuse things. C++ as a language does not directly support |an OODBMS. C++ pointers are memory pointers, and object references within an OODBMS |are a different thing (you will need a stronger and cleaner concept of object |identity there anyway). 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. |I'll try to explain: First you must understand. |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. |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. |Sorry, but IMO it's you who have been furiously defending hacks, not I. |Perhaps there is this misunderstanding: you think that the requirement |of total ordering for pointers implies a linear address model. |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]. 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. |One obvious case where a total order of pointers would be nice to depend on |are (large) collections of pointers -- I think Andrew Koenig mentioned this |many submissions ago. With total order, you can organise such collections |e.g. so that binary search can be used, requiring O(log N) time; |otherwise you are stuck with linear search and O(N) time. Again, if you want to do this, then arrange to do so. Just don't ask all compilers to support the hacks you'd want to implement it in. "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.