C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Comparing pointers that point to objects that are not in the Goto page 1, 2  Next          C++Talk.NET Forum Index -> C++ Language (Moderated) View previous topic :: View next topic   Author Message Andre Heinen Guest Posted: Sat Feb 21, 2004 4:24 am    Post subject: Comparing pointers that point to objects that are not in the Hi all, I have two pointers of the same type. They are not null, and they point to valid objects. (By "object" I don't necessarily mean "object of class type". I mean anything that can be pointed to, including variables and constants, classes and integrated types, and functions.) I'd like to compare the pointers. As far as I know, comparison with ==, < or other usual operators is guaranteed to work if they point to objects stored in the same array, or to the fictitious object that is stored immediately after the end of the array. But I have no array. After searching Google, I also found out that if the two pointers (let's call them p1 and p2) point to the same object, p1==p2 is guaranteed to return true, and p1!=p2 is guaranteed to return false. My question is: if p1 and p2 do *not* point to the same object (nor even to objects stored in the same array), is p1==p2 guaranteed to return false? And is p1!=p2 guaranteed to return true? As an afterthought, if the answers are "yes", is p1==p2 guanranteed to return false if one (and only one) of the pointers is null, or should I check for null pointers beforehand? TIA -- Andre Heinen My address is "a dot heinen at europeanlink dot com" [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Jack Klein Guest Posted: Sat Feb 21, 2004 1:50 pm    Post subject: Re: Comparing pointers that point to objects that are not in On 20 Feb 2004 23:24:13 -0500, Andre Heinen <nospam (AT) nospam (DOT) invalid> wrote in comp.lang.c++.moderated: Quote: Hi all, I have two pointers of the same type. They are not null, and they point to valid objects. (By "object" I don't necessarily mean "object of class type". I mean anything that can be pointed to, including variables and constants, classes and integrated types, and functions.) Your definition of object happens to match the C++ definition of object, which in turn is inherited from the C definition of object. It has nothing at all to do with "object-oriented programming", and an int is just as much a C++ object as any class. Quote: I'd like to compare the pointers. As far as I know, comparison with ==, < or other usual operators is guaranteed to work if they point to objects stored in the same array, or to the fictitious object that is stored immediately after the end of the array. But I have no array. After searching Google, I also found out that if the two pointers (let's call them p1 and p2) point to the same object, p1==p2 is guaranteed to return true, and p1!=p2 is guaranteed to return false. My question is: if p1 and p2 do *not* point to the same object (nor even to objects stored in the same array), is p1==p2 guaranteed to return false? And is p1!=p2 guaranteed to return true? As an afterthought, if the answers are "yes", is p1==p2 guanranteed to return false if one (and only one) of the pointers is null, or should I check for null pointers beforehand? TIA Any pointers with valid values, as you correctly defined them above, and/or null pointers, can be compared for equality or inequality with == and !=. This is well defined. It is only for the following that you need pointers to the same object and/or array, <, >, <=, >=, or doing pointer subtraction. -- Jack Klein Home: http://JK-Technology.Com FAQs for comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html comp.lang.c++ http://www.parashift.com/c++-faq-lite/ alt.comp.lang.learn.c-c++ http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Francis Glassborow Guest Posted: Sat Feb 21, 2004 4:16 pm    Post subject: Re: Comparing pointers that point to objects that are not in In message <bldc30pkc1edkqiod357h6paqggc2v2obp (AT) 4ax (DOT) com>, Andre Heinen <nospam (AT) nospam (DOT) invalid> writes Quote: My question is: if p1 and p2 do *not* point to the same object (nor even to objects stored in the same array), is p1==p2 guaranteed to return false? And is p1!=p2 guaranteed to return true? No, the C Standard originally seemed to require this but over the years we realised that it was not enforceable without a substantial waste of memory (providing a buffer between objects -- and that would not work for 2D arrays) Consider: int array[10], a; And assume we are using a compiler that does not allocate memory off the stack for arrays (I know of at least one that used to separate out arrays and individual objects). Unless we place a buffer zone between array and a, then array+10 (or. if you prefer, &array[10]) will be indistinguishable from &a. However any program that relies on such being true is non-portable. Quote: As an afterthought, if the answers are "yes", is p1==p2 guanranteed to return false if one (and only one) of the pointers is null, or should I check for null pointers beforehand? if exactly one of p1 and p2 is a null pointer and the other is a valid address then p1==p2 evaluates as false. -- Francis Glassborow ACCU Author of 'You Can Do It!' see http://www.spellen.org/youcandoit For project ideas and contributions: http://www.spellen.org/youcandoit/projects [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Joost Kraaijeveld Guest Posted: Sat Feb 21, 2004 4:21 pm    Post subject: Re: Comparing pointers that point to objects that are not in 5.10 Equality operators: .....Pointers or objects or functions of the same type (after pointer conversion) can be compared for equality. Two pointers of the same type compare equal if and only if they are both null, both point to the same function, or both represent the same address.... Bye Joost Kraaijeveld Askesis B.V. Molukkenstraat 14 6524NB Nijmegen tel: 024-3888063 / 06-51855277 fax: 024-3608416 e-mail: [email]J.Kraaijeveld (AT) Askesis (DOT) nl[/email] web: www.askesis.nl [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Steve Dewhurst Guest Posted: Sat Feb 21, 2004 6:13 pm    Post subject: Re: Comparing pointers that point to objects that are not in Andre Heinen <nospam (AT) nospam (DOT) invalid> wrote Quote: My question is: if p1 and p2 do *not* point to the same object (nor even to objects stored in the same array), is p1==p2 guaranteed to return false? And is p1!=p2 guaranteed to return true? Yes. Quote: As an afterthought, if the answers are "yes", is p1==p2 guanranteed to return false if one (and only one) of the pointers is null, or should I check for null pointers beforehand? Yes, null == non-null will be false. If you're planning to get "creative" with addresses of objects, remember that pointers to objects can compare equal even if they contain different addresses. This can happen, for instance, if you compare a derived class pointer (dp) with a public base class pointer (bp) that refer to the same object. In that case, the expression dp == bp will be true, whereas the expression (void *)dp == (void *)bp may not. Steve Steve Dewhurst www.semantics.org [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Alf P. Steinbach Guest Posted: Sat Feb 21, 2004 6:17 pm    Post subject: Re: Comparing pointers that point to objects that are not in * Jack Klein <jackklein (AT) spamcop (DOT) net> schriebt: Quote: It is only for the following that you need pointers to the same object and/or array, <, >, <=, >=, or doing pointer subtraction. And if you're not afraid to drag in the standard library (the library! the library! hurray!) you can even compare pointers wrt. less than and greated than without special care, using e.g. std::greater_equal and friends. At least, if memory serves me right. Which it might not, but I seem to remember this from some earlier time this little fine point -- std. lib more powerful than language -- was discussed. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Ben Hutchings Guest Posted: Sun Feb 22, 2004 10:55 am    Post subject: Re: Comparing pointers that point to objects that are not in Francis Glassborow wrote: Quote: In message <bldc30pkc1edkqiod357h6paqggc2v2obp (AT) 4ax (DOT) com>, Andre Heinen [email]nospam (AT) nospam (DOT) inva[/email]lid> writes My question is: if p1 and p2 do *not* point to the same object (nor even to objects stored in the same array), is p1==p2 guaranteed to return false? And is p1!=p2 guaranteed to return true? No, the C Standard originally seemed to require this but over the years we realised that it was not enforceable without a substantial waste of memory (providing a buffer between objects -- and that would not work for 2D arrays) snip Surely the answer to Andre's question is yes, so long as p1 and p2 really do point to objects and have the same type: pointers of the same type to different objects do always compare unequal. What you've pointed out is that there is a caveat to this: a pointer to just beyond the end of an array may or may not point to an object outside the array. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top David Abrahams Guest Posted: Sun Feb 22, 2004 5:27 pm    Post subject: Re: Comparing pointers that point to objects that are not in Francis Glassborow <francis (AT) robinton (DOT) demon.co.uk> writes: Quote: In message <bldc30pkc1edkqiod357h6paqggc2v2obp (AT) 4ax (DOT) com>, Andre Heinen [email]nospam (AT) nospam (DOT) inva[/email]lid> writes My question is: if p1 and p2 do *not* point to the same object (nor even to objects stored in the same array), is p1==p2 guaranteed to return false? And is p1!=p2 guaranteed to return true? No, the C Standard originally seemed to require this but over the years we realised that it was not enforceable without a substantial waste of memory (providing a buffer between objects -- and that would not work for 2D arrays) Consider: int array[10], a; And assume we are using a compiler that does not allocate memory off the stack for arrays (I know of at least one that used to separate out arrays and individual objects). Unless we place a buffer zone between array and a, then array+10 (or. if you prefer, &array[10]) will be indistinguishable from &a. However any program that relies on such being true is non-portable. As an afterthought, if the answers are "yes", is p1==p2 guanranteed to return false if one (and only one) of the pointers is null, or should I check for null pointers beforehand? if exactly one of p1 and p2 is a null pointer and the other is a valid address then p1==p2 evaluates as false. And otherwise, if they're not part of the same array, the behavior is undefined. -- Dave Abrahams Boost Consulting www.boost-consulting.com [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Dietmar Kuehl Guest Posted: Mon Feb 23, 2004 11:16 am    Post subject: Re: Comparing pointers that point to objects that are not in David Abrahams wrote: Quote: Francis Glassborow <francis (AT) robinton (DOT) demon.co.uk> writes: if exactly one of p1 and p2 is a null pointer and the other is a valid address then p1==p2 evaluates as false. And otherwise, if they're not part of the same array, the behavior is undefined. Can you point me to the restriction stating that the pointers have to be of the same array? I found 5.10 (expr.eq) paragraph 1 but I cannot see any restriction about pointers having to be from the same array. I know that such a restriction applies to the relational pointer comparisons (<, <=, >, >=) but I'm unaware of such a restriction for the equivalence functions (== and !=). -- <mailto:dietmar_kuehl (AT) yahoo (DOT) com> <http://www.dietmar-kuehl.de/> Phaidros eaSE - Easy Software Engineering: <http://www.phaidros.com/> [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Thomas Richter Guest Posted: Mon Feb 23, 2004 6:57 pm    Post subject: Re: Comparing pointers that point to objects that are not in Hi Dietmar, Quote: Can you point me to the restriction stating that the pointers have to be of the same array? I found 5.10 (expr.eq) paragraph 1 but I cannot see any restriction about pointers having to be from the same array. I know that such a restriction applies to the relational pointer comparisons (<, <=, >, >=) but I'm unaware of such a restriction for the equivalence functions (== and !=). Well, instead of an answer, another question: Consider an implementation on an architecture using a segmented memory model (urgh) and pointers being (say) 16 bit sized, relative to a base segment. Consider two objects, a and b, where a is on the heap and b is on the stack. Would an implementation standard conforming if the 16 bit pointer to a equals to the 16 bit pointer to b, even though a and b are different objects? Or, to put it differently, would an implementation be required to consider the segment base (base pointer) if comparing pointers for equality? So long, Thomas [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top kanze@gabi-soft.fr Guest Posted: Mon Feb 23, 2004 7:30 pm    Post subject: Re: Comparing pointers that point to objects that are not in Andre Heinen <nospam (AT) nospam (DOT) invalid> wrote Quote: I have two pointers of the same type. They are not null, and they point to valid objects. (By "object" I don't necessarily mean "object of class type". I mean anything that can be pointed to, including variables and constants, classes and integrated types, and functions.) I'd like to compare the pointers. As far as I know, comparison with ==, < or other usual operators is guaranteed to work if they point to objects stored in the same array, or to the fictitious object that is stored immediately after the end of the array. But I have no array. No problem for == and !=. Quote: After searching Google, I also found out that if the two pointers (let's call them p1 and p2) point to the same object, p1==p2 is guaranteed to return true, and p1!=p2 is guaranteed to return false. My question is: if p1 and p2 do *not* point to the same object (nor even to objects stored in the same array), is p1==p2 guaranteed to return false? And is p1!=p2 guaranteed to return true? If (and only if) the two pointers actually point to an object. It is possible for a pointer one past the end of an array to compare equal to a pointer to an object outside of the array. Quote: As an afterthought, if the answers are "yes", is p1==p2 guanranteed to return false if one (and only one) of the pointers is null, or should I check for null pointers beforehand? A null pointer is guaranteed to compare unequal to a pointer to an object, or to a pointer one past the end of an array. The only ambiguity is a pointer to one past the end of an array, compared with a pointer to an object. -- James Kanze GABI Software mailto:kanze (AT) gabi-soft (DOT) fr Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Kurt Stege Guest Posted: Tue Feb 24, 2004 1:48 pm    Post subject: Re: Comparing pointers that point to objects that are not in On 23 Feb 2004 13:57:01 -0500, Thomas Richter <thor (AT) cleopatra (DOT) math.tu-berlin.de> wrote: Quote: Consider an implementation on an architecture using a segmented memory model (urgh) and pointers being (say) 16 bit sized, relative to a base segment. Consider two objects, a and b, where a is on the heap and b is on the stack. Would an implementation standard conforming if the 16 bit pointer to a equals to the 16 bit pointer to b, even though a and b are different objects? Or, to put it differently, would an implementation be required to consider the segment base (base pointer) if comparing pointers for equality? An example: void foo (void) { int data; int *a = &data; int *b = new int(); assert (a != b); *a = 1; *b = 2; assert (*a != *b); } Both a and b have the same type, namely int *, and the same size. When this size is 16 bit, this is a decision of the compiler. But when the compiler decides to let the expression a == b to be true, then I ask, how the compiler could find the adequate memory to store the values 1 and 2, and to ensure that *a != *b. My point is, since a and b points to different objects, there is no reason for the compiler to treat the pointers as equal. It is OK for the compiler, to use some code optimization, and to store indeed only the offset within the memory, and store in the code flow, that a points to data on the stack, and b points to memory in the heap. Alas, these optimization would not work every time; it breaks when calling a function with different "internal types of" pointer. Joost already cited the standard: :5.10 Equality operators: : :....Pointers or objects or functions of the same type (after pointer :conversion) can be compared for equality. Two pointers of the same type :compare equal if and only if they are both null, both point to the same :function, or both represent the same address.... That is, in this case, a != b. By the way, Thomas, you are thinking about the old 16-Bit-DOS-compilers? They often had different memory models. The smallest one indeed used 16-Bit-pointers, but the cost has been, that the whole address room (data and stack and heap) have been restricted to 64 KB. You are adressing a memory model, where pointers have been stored in 32 bit, but handling of pointers has been somewhat "simplified". But I guess, this is not only of no interrest anymore, but even far out of topic... Regards, Kurt. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Francis Glassborow Guest Posted: Tue Feb 24, 2004 7:12 pm    Post subject: Re: Comparing pointers that point to objects that are not in In message <slrnc3g8ep.p3b.do-not-spam-benh (AT) shadbolt (DOT) i.decadentplace.org.uk>, Ben Hutchings <do-not-spam-benh (AT) bwsint (DOT) com> writes Quote: Francis Glassborow wrote: In message <bldc30pkc1edkqiod357h6paqggc2v2obp (AT) 4ax (DOT) com>, Andre Heinen [email]nospam (AT) nospam (DOT) inva[/email]lid> writes My question is: if p1 and p2 do *not* point to the same object (nor even to objects stored in the same array), is p1==p2 guaranteed to return false? And is p1!=p2 guaranteed to return true? No, the C Standard originally seemed to require this but over the years we realised that it was not enforceable without a substantial waste of memory (providing a buffer between objects -- and that would not work for 2D arrays) snip Surely the answer to Andre's question is yes, so long as p1 and p2 really do point to objects and have the same type: pointers of the same type to different objects do always compare unequal. What you've pointed out is that there is a caveat to this: a pointer to just beyond the end of an array may or may not point to an object outside the array. Read his question: if p1 and p2 do *not* point to the same object ... is p1 == p2 guaranteed to return false. Where does he say that either p1 or p2 point to objects or even into objects? And exactly what is the status of the 'one beyond the end' pointer? The answer to his question as asked is clearly 'no, it is not guaranteed because...' -- Francis Glassborow ACCU Author of 'You Can Do It!' see http://www.spellen.org/youcandoit For project ideas and contributions: http://www.spellen.org/youcandoit/projects [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Kurt Stege Guest Posted: Tue Feb 24, 2004 7:17 pm    Post subject: Re: Comparing pointers that point to objects that are not in Hi Francis. On 21 Feb 2004 11:16:24 -0500, Francis Glassborow <francis (AT) robinton (DOT) demon.co.uk> wrote: Quote: In message <bldc30pkc1edkqiod357h6paqggc2v2obp (AT) 4ax (DOT) com>, Andre Heinen [email]nospam (AT) nospam (DOT) inva[/email]lid> writes My question is: if p1 and p2 do *not* point to the same object (nor even to objects stored in the same array), is p1==p2 guaranteed to return false? And is p1!=p2 guaranteed to return true? No, the C Standard originally seemed to require this but over the years we realised that it was not enforceable without a substantial waste of memory (providing a buffer between objects -- and that would not work for 2D arrays) I just reread the standard Joost already quoted :5.10 Equality operators: : :....Pointers or objects or functions of the same type (after pointer :conversion) can be compared for equality. Two pointers of the same type :compare equal if and only if they are both null, both point to the same :function, or both represent the same address.... Alas, my copy of the standard says: "Two pointers of the same type compare equal if and only if they are both null, both point to the same object or function, or both point one past the end of the same array." That is slightly different from Joost citation. Are there different ISO 14882:1998 in the world? When the definition of "point to" does not have some semantic surprises, this formulation requires the "substantial waste of memory" that Francis mentiones. Or is it OK for a pointer to "point to" different objects simultaneously? That would be what I call "semantic surprise". Quote: Consider: int array[10], a; And assume we are using a compiler that does not allocate memory off the stack for arrays (I know of at least one that used to separate out arrays and individual objects). Unless we place a buffer zone between array and a, then array+10 (or. if you prefer, &array[10]) will be indistinguishable from &a. However any program that relies on such being true is non-portable. Of course, from a technical point of view, array+10 points both to the end of the array and to "a". But this technical view results from the implementation of the compiler. The standard suggests using the word "point to" in a way, that this is not meant. Otherwise, the implementation could argument, that each pointer is either null or points to every object in the world simultaneously. Using this interpretation, a compiler would be conforming to the standard, when every two pointers are told to be equal (at least, when both or none of them are null). A very uncomfortable world. Quote: ... but over the years we realised that it was not enforceable without a substantial waste of memory (providing a buffer between objects -- and that would not work for 2D arrays) What does this mean exactly? That the standard is broken in this point and the compiler vendors are encouraged to deliver compilers breaking the standard in this point? That would be OK for me, I can live with this state. Best regards, Kurt. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Andre Heinen Guest Posted: Tue Feb 24, 2004 7:22 pm    Post subject: Re: Comparing pointers that point to objects that are not in On 24 Feb 2004 08:48:03 -0500, Kurt Stege <kstege (AT) innovative-systems (DOT) de> wrote: Quote: An example: void foo (void) { int data; int *a = &data; int *b = new int(); assert (a != b); *a = 1; *b = 2; assert (*a != *b); } Both a and b have the same type, namely int *, and the same size. By the way, is this always true? The pointers have the same type, and this means that comparison must work. Does it mean that the pointers must be implemented the same way? As an example, let's imagine what could be produced by an MS-DOS compiler, in a situation where we need a little stack (stack segment, SS) but a big heap (DS, if I recall): int *a = &data; // 16-bit pointer, plus SS assumed. As // the stack is assumed to be less than // 64K we'll never need to change the // value of SS during execution. int *b = new int(); // 32-bit pointer, because we need more // than 64K of heap. assert (a != b); // SS:a != b : 32-bit comparison that // is guaranteed to work. *a = 1; // SS:a : A bit faster than the line // below, because we don't need to set // SS, which keeps its default value. *b = 2; // b : A bit slower because we have to // set both DS and offset. assert (*a != *b); // dereference SS:a and b Quote: snip By the way, Thomas, you are thinking about the old 16-Bit-DOS-compilers? snip> But I guess, this is not only of no interrest anymore, but even far out of topic... Well, although I haven't programmed any more for MS-DOS since a long time, it still interests me as an example. It's the only segmented model I've known. And as far as it remains an example I suppose it isn't off-topic? -- Andre Heinen My address is "a dot heinen at europeanlink dot com" [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ Language (Moderated) All times are GMT Goto page 1, 2  Next Page 1 of 2   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.