home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.std.c++
- Path: sparky!uunet!stanford.edu!lucid.com!lucid.com!jss
- From: jss@lucid.com (Jerry Schwarz)
- Subject: Re: Pointer comparisons
- Message-ID: <1992Dec29.042828.27808@lucid.com>
- Sender: usenet@lucid.com
- Reply-To: jss@lucid.com (Jerry Schwarz)
- Organization: Lucid, Inc.
- References: <1992Dec19.001851.22116@microsoft.com> <1992Dec23.182456.17185@lucid.com> <1992Dec24.200201.25709@microsoft.com> <1992Dec28.175218.15539@microsoft.com>
- Date: Tue, 29 Dec 92 04:28:28 GMT
- Lines: 62
-
- jss:
- |> ||Does anything go for A's. E.g.
- |> ||
- |> || void f() {
- |> || A a1, a2 ; // can &a1==&a2
- |> || ... ;
- |> || }
- |> |
-
- jimad:
- |> Let me restate the question as an answer.
- |>
- |> Does the ARM anywhere say that two pointers of the same type to two different
- |> objects of the same type not in the same array must compare not equal?
- |>
- |> If not then what does the ARM say of any such comparison?
-
- As far as I can tell, except for the special cases enumerated in
- 5.9 and some hints about the behavior of new, the ARM
- never requires two pointers to compare unequal. I believe this is
- an oversight and should be corrected in the standard when it emerges.
- I believe the intention has always been that distinct objects have
- distinct addresses and I belive that the final standard should say so.
-
- What should x3j16/wg21 do? One alternative would be to leave
- the words unchanged. (I think this is Jim's position,
- but I'm not sure.) This apparently allows &a1==&a2 in the above,
- and in other cases as well. If the committee does this, it
- should do it explicitly after due consideration and not simply
- allow the status quo to remain by default.
-
- Another possibility which has been proposed here recently (sorry
- I don't remember by whom) is to add something like "two pointers to
- T (where T is an object type) compare equal if and only if they point
- to the same object". This seems a useful rule to me. Note that
- it makes no distinctions between "empty" and "non-empty" classes.
- An alternative might be to apply this rule except for "empty"
- classes.
-
- So there really several related questions about this example.
-
- A: Does the ARM currently require a1!=a2? Apparently
- not, but I may have overlooked something.
-
- B: What do existing compilers do. How common is the
- code that might be affected if the compiler was
- changed to do something else. How much existing
- code currently assumes that a1!=a2.
-
- D: Should the standard when it emerges require a1!=a2.
- I think yes, and am concerned with exactly how to
- word this requirement. There are many potential
- examples and I would greatly prefer a general rule
- to an enumeration of cases.
-
- Knowing the answers to A and B for this and similar cases
- might influence my opinion on C, but I am not prepared in advance
- to state a rule that would allow you to derive my opinion of C
- from the answers to A and B.
-
- -- Jerry Schwarz
-
-