From -2187395692257960466 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:11 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.222242.18703@microsoft.com> Date: 07 Dec 92 22:22:42 GMT Organization: Microsoft Corporation References: <1992Dec2.111003.23102@jyu.fi> <1992Dec2.205330.10372@meaddata.com> <1992Dec4.070720.13056@lth.se> Lines: 70 In article <1992Dec4.070720.13056@lth.se> dag@control.lth.se (Dag Bruck) writes: |In ralpht@meaddata.com (Ralph W. Trickey) writes: |>|> > |>|> > I don't think that requiring total ordering would break any existing |>|> >program, but it would break quite a few existing compilers. |> |>This language change that would slow down existing programs. Possibly |>to the point where they no longer meet specifications. I consider this |>breaking programs. | |Could someone do the net a great favour and check it? There's a lot |of speculation but nobody has measured how severe the slow-down would be. People who are experienced with PCs don't have to measure this problem because they are well aware of the issues and the code sizes involved. What you ask for is essentially the same thing as "Huge" model which PC compilers support but *which PC programmers don't use* -- because its too expensive. Note however, that if you insisted on using total ordering *you* could compile *your* program under Huge model and then *you* would be paying the penalty. Rather than insisting all PC programmers pay the penalty always. But, since *you* request the numbers, here's a simple example: Compaq Deskpro 386/20 C7 compiler all optimizations. Comparing an pointer inner loop, incrementing one pointer and comparing with another pointer within a loop. The "total ordering" approach loop executes approx 3X slower than the typical PC segment:offset approach. The "total ordering" approach loop takes 28 bytes more code for the pointer comparison than the typical PC segment:offset [large model] approach. ====== Again, PC compilers already support what you ask for. Its just that programmers can't afford to use it. Or perhaps more accurately stated its plenty expensive enough that PC programmers only want to pay for it when they're *really* using it! |A total ordering would make it easier to build some common data |structures. For example, a binary search tree needs some sort of |comparison function. If you are only interested in finding a |particular object in the tree (i.e., the actual ordering is |irrelevant), comparing the addresses would work nicely. If you want to compare addresses, then compare addresses. If you want to compare pointers, then compare pointers. A pointer is not an address. An address is one particular implementation of a pointer. If you want to compare addresses, the following works on all computers and compilers I've ever had to deal with: if (((long)ptr_a) > ((long)ptr_b)) blah(); |I think the absense of a total ordering is a much greater problem in |C++ than in C, because general purpose data structures are becoming |much more common in the shape of templates. The problem is no worse than in C because in practice in both languages a programmer can make a total ordering if and where the programmer nee ds it. Further, the problem is *less* in C++ because classes and overloaded operators allow class implementors to encapsulate their implementation of total ordering if and where needed. If the programmer can do it, then there is no need for the language definition to require it. On the contrary, the language definition should stick to things fundamental, and should leave the implementation to the compiler and operating system implementers.