From 87333309296492436 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,e94695845965b249 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 1992-12-10 10:22:14 PST Newsgroups: comp.std.c++ Path: sparky!uunet!mcsun!Germany.EU.net!ira.uka.de!slsvaat!josef!kanze From: kanze@us-es.sel.de (James Kanze) Subject: Re: Zero-length structures and pointer comparisons In-Reply-To: maxtal@extro.ucc.su.OZ.AU's message of Thu, 10 Dec 1992 12:19:35 GMT Message-ID: Sender: news@us-es.sel.de Organization: SEL References: <1992Dec07.222242.18703@microsoft.com> <1992Dec8.103218.27689@lth.se> <1992Dec8.173855.18153@meaddata.com> <1992Dec10.121935.19315@ucc.su.OZ.AU> Date: 10 Dec 92 17:11:14 Lines: 46 In article <1992Dec10.121935.19315@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes: |> In article <1992Dec8.173855.18153@meaddata.com> ralpht@meaddata.com (Ralph W. Trickey) writes: |> > |> >Attempting to require this for the general case becomes very |> >complicated. How is the null pointer handled? Is it less than all |> >other pointers, or is that implementation dependent, or what? How is |> >shared memory handled, if I have 2 pointers that are pointing to |> >different addresses, but are pointing to the same object, must they |> >compare equal? |> The answer to this particular question is YES, they must |> compare equal according to the ARM. And I think this is a problem |> for OS design for the 386, for example, where the memory management |> kernel will just have to ignore the ARM. As it should. The ARM (and the upcoming ANSI standard) can only address what happens in the context of C++, not what happens to the pointer once the OS gets its hands on it. In a similar vein, for example, the ANSI C standard states that the NULL pointer will not point to any object. But all 8086 programmers know that if you compile with 32 bit pointers, it actually points to the interrupt vector table! However, this is *not* an object defined in any C program, so this is perfectly legal. (If it wasn't, you couldn't have C on machines without protected memory.) In the same way, I would understand the ARM to be saying that all pointers generated by a correct program to point to any object defined (including a dynamic definition by new) in C++ will compare equal. If you give the pointer to the OS, and it gives it back to you, then any guarantees must be made by the OS, and not the C++ language. |> If we dropped this requirement, however, there would |> be no easy way to identify objects. Once you leave the safe and easy world of your program, there is no easy way to identify objects. C++ doesn't address such problems as persistance, transportability or shared memory. -- -- James Kanze email: kanze@us-es.sel.de GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France Conseils en informatique industrielle -- -- Beratung in industrieller Datenverarbeitung