www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Object reference comparisons.

reply Adrian Ratnapala <Adrian_member pathlink.com> writes:
As far as I can tell, code like:

SomeClass objA = new SomeClass("hello");
SomeClass objB = new SomeClass("hello");

if( objA == objB )
return true;
else 
return false;


Will return return false because the "==" compares
the references. This is exactly what I want in my code,
but my first question is whether D does in implicit
dereference of one or both operands, and if so, whether 
that is a bug. 

I beleive it does do such a dereference, because my
programs keep segfaulting when one of the operands
happens to be "null".  valgrind told me that this
was happning in the invariant check of Object.  

My present workaround is to define a function

bit ptrEqual(void* a, void* b)
{
return a==b;
}

Objects seem to implicilty cast themselves into "void*"
pretty easily, so this is easy enough to use.  Ideally
I would like to check that "a" and "b" have the same
type, but the only way of doing that involved the user
writing something like

ptrEqual!(SomeClass)(objA, objB)

each time, and I don't think the extra verbage is worth
it.

So my second question is whether there is a better 
workaround.


Thanks.
Mar 27 2005
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Sun, 27 Mar 2005 21:12:22 +0000 (UTC), Adrian Ratnapala wrote:


 As far as I can tell, code like:
 
 SomeClass objA = new SomeClass("hello");
 SomeClass objB = new SomeClass("hello");
 
 if( objA == objB )
 return true;
 else 
 return false;
 
 
 Will return return false because the "==" compares
 the references. This is exactly what I want in my code,
 but my first question is whether D does in implicit
 dereference of one or both operands, and if so, whether 
 that is a bug. 
 
 I beleive it does do such a dereference, because my
 programs keep segfaulting when one of the operands
 happens to be "null".  valgrind told me that this
 was happning in the invariant check of Object.  
 
 My present workaround is to define a function
 
 bit ptrEqual(void* a, void* b)
 {
 return a==b;
 }
 
 Objects seem to implicilty cast themselves into "void*"
 pretty easily, so this is easy enough to use.  Ideally
 I would like to check that "a" and "b" have the same
 type, but the only way of doing that involved the user
 writing something like
 
 ptrEqual!(SomeClass)(objA, objB)
 
 each time, and I don't think the extra verbage is worth
 it.
 
 So my second question is whether there is a better 
 workaround.


Better? I'm not sure, but one more 'complete' method is ...

  if (objA is null)
    if (objB is null)
      return true;
    else
      return false;
  else  if (objB is null)
      return false;
    else
      return (objA == objB);


I think the access violation can come about because (objA == objB) gets to
be a call to objA.opEquals(objB) which requires that objA not be a null.

-- 
Derek Parnell
Melbourne, Australia
28/03/2005 7:27:53 AM
Mar 27 2005
parent reply Adrian Ratnapala <Adrian_member pathlink.com> writes:
 workaround.


Better? I'm not sure, but one more 'complete' method is ...

  if (objA is null)
    if (objB is null)
      return true;
    else
      return false;
  else  if (objB is null)
      return false;
    else
      return (objA == objB);


Hmm, I think I might have done it this way, except
the function would have to take references to "Object"s,
which looses me most of my type safety anyway.


I think the access violation can come about because (objA == objB) gets to
be a call to objA.opEquals(objB) which requires that objA not be a null.


I think that is true.  In which case I would class it as a (subtle)
bug in D.  Not because the compiler does not implement the specification,
but because the specfication has an unintendend, and quite nasty,
consequence.  Does anyone concurr?


Melbourne, Australia
28/03/2005 7:27:53 AM


Are Aussies the only people awake right now?
Mar 27 2005
parent Adrian Ratnapala <Adrian_member pathlink.com> writes:
I think that is true.  In which case I would class it as a (subtle)
bug in D.  Not because the compiler does not implement the specification,
but because the specfication has an unintendend, and quite nasty,
consequence.  Does anyone concurr?


Come to think of it, could I not simply use the "is" operator
for this test?
Mar 27 2005
prev sibling parent "Ben Hinkle" <ben.hinkle gmail.com> writes:
"Adrian Ratnapala" <Adrian_member pathlink.com> wrote in message 
news:d277jl$2sk$1 digitaldaemon.com...

 As far as I can tell, code like:

 SomeClass objA = new SomeClass("hello");
 SomeClass objB = new SomeClass("hello");

 if( objA == objB )
 return true;
 else
 return false;


 Will return return false because the "==" compares
 the references.


Technically == calls Object.opEquals


 bit ptrEqual(void* a, void* b)
 {
 return a==b;
 }


This is exactly what "is" does. See 
http://www.digitalmars.com/d/expression.html#EqualExpression and the section 
following that called "Identity Expression".
Mar 27 2005