• #ponce <aliloko gmail.com> Oct 14 2009
• #ponce <aliloko gmail.com> Oct 14 2009
• Moritz Warning <moritzwarning web.de> Oct 14 2009
• "Steven Schveighoffer" <schveiguy yahoo.com> Oct 14 2009
• #ponce <aliloko gmail.com> Oct 14 2009
• Jeremie Pelletier <jeremiep gmail.com> Oct 14 2009
• BCS <none anon.com> Oct 14 2009
• Justin Johansson <no spam.com> Oct 14 2009
• Max Samukha <spambox d-coding.com> Oct 14 2009
• Justin Johansson <no spam.com> Oct 14 2009

#ponce <aliloko gmail.com> writes:

It's a bit unclear to me. 

I know I must compare references with is but pointers ?

#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 == ?"

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.

"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

#ponce <aliloko gmail.com> writes:

Thanks for the answers.

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

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.

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.

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.

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.