www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Should I compare pointers with is of == ?

reply #ponce <aliloko gmail.com> writes:
It's a bit unclear to me. 

I know I must compare references with is but pointers ?
Oct 14 2009
next sibling parent #ponce <aliloko gmail.com> writes:
#ponce Wrote:

 It's a bit unclear to me. 
 
 I know I must compare references with is but pointers ?
 
 
There is a typo in the title. "Should I compare pointers with is oR == ?"
Oct 14 2009
prev sibling next sibling parent Moritz Warning <moritzwarning web.de> writes:
On Wed, 14 Oct 2009 08:15:01 -0400, #ponce wrote:

 It's a bit unclear to me.
 
 I know I must compare references with is but pointers ?
There is no difference because you can't overload the == operator etc. for pointers.
Oct 14 2009
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 14 Oct 2009 08:15:01 -0400, #ponce <aliloko gmail.com> wrote:

 It's a bit unclear to me.

 I know I must compare references with is but pointers ?
Like Moritz said, there is no semantic difference with pointers, but you may consider comparing with is if you are looking for equivalence. It cannot ever be overridden, so if for some reason you decided to change your pointer to a class reference, it doesn't accidentally morph into a virtual call (possibly to a null object causing a segfault). -Steve
Oct 14 2009
next sibling parent #ponce <aliloko gmail.com> writes:
Thanks for the answers.
Oct 14 2009
prev sibling parent Jeremie Pelletier <jeremiep gmail.com> writes:
Steven Schveighoffer wrote:
 On Wed, 14 Oct 2009 08:15:01 -0400, #ponce <aliloko gmail.com> wrote:
 
 It's a bit unclear to me.

 I know I must compare references with is but pointers ?
Like Moritz said, there is no semantic difference with pointers, but you may consider comparing with is if you are looking for equivalence. It cannot ever be overridden, so if for some reason you decided to change your pointer to a class reference, it doesn't accidentally morph into a virtual call (possibly to a null object causing a segfault). -Steve
I agree, I only learned recently that == is not a direct pointer comparison for classes, I had to scramble all around my code to replace them with is and !is, so for good habit I'd go with using is for pointer equality too. Jeremie
Oct 14 2009
prev sibling next sibling parent BCS <none anon.com> writes:
Hello #ponce,

 It's a bit unclear to me.
 
 I know I must compare references with is but pointers ?
 
Because it's always safe, I tend to use 'is' in any cases where one side could be null.
Oct 14 2009
prev sibling parent reply Justin Johansson <no spam.com> writes:
#ponce Wrote:

 It's a bit unclear to me. 
 
 I know I must compare references with is but pointers ?
Thanks for asking this question ponce; I've been getting into the habit of using 'is' for both pointers and classes, so in similar vein to ponce's question, I'd like to ask if the following (where foo is eother a pointer of class ref) is being overly pendantic in the case of null if tests: if (foo !is null) { // can do something with foo } as opposed to the shorter form, but possibly incorrect or less safe if (foo) { // can do somthing with foo } I think I would prefer the shorter form if its 100% good. Thanks all.
Oct 14 2009
parent reply Max Samukha <spambox d-coding.com> writes:
On Wed, 14 Oct 2009 14:20:24 -0400, Justin Johansson <no spam.com>
wrote:

#ponce Wrote:

 It's a bit unclear to me. 
 
 I know I must compare references with is but pointers ?
Thanks for asking this question ponce; I've been getting into the habit of using 'is' for both pointers and classes, so in similar vein to ponce's question, I'd like to ask if the following (where foo is eother a pointer of class ref) is being overly pendantic in the case of null if tests: if (foo !is null) { // can do something with foo } as opposed to the shorter form, but possibly incorrect or less safe if (foo) { // can do somthing with foo } I think I would prefer the shorter form if its 100% good.
If you compare pointers or class references, it is 100% good to use the shorter form. It is only 87% good if you compare arrays because the shorter form means "if (arr.ptr)". So, if you are in the camp of those who do not make a distinction between empty and null arrays you should always use "if (arr.length)".
Thanks all.
Oct 14 2009
parent Justin Johansson <no spam.com> writes:
Max Samukha Wrote:

 On Wed, 14 Oct 2009 14:20:24 -0400, Justin Johansson <no spam.com>
 wrote:
 
#ponce Wrote:

 It's a bit unclear to me. 
 
 I know I must compare references with is but pointers ?
Thanks for asking this question ponce; I've been getting into the habit of using 'is' for both pointers and classes, so in similar vein to ponce's question, I'd like to ask if the following (where foo is eother a pointer of class ref) is being overly pendantic in the case of null if tests: if (foo !is null) { // can do something with foo } as opposed to the shorter form, but possibly incorrect or less safe if (foo) { // can do somthing with foo } I think I would prefer the shorter form if its 100% good.
If you compare pointers or class references, it is 100% good to use the shorter form. It is only 87% good if you compare arrays because the shorter form means "if (arr.ptr)". So, if you are in the camp of those who do not make a distinction between empty and null arrays you should always use "if (arr.length)".
Thanks Max for clear and concise answer. Now I can sleep again. :-) Justin.
Oct 14 2009