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.

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

>> 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?

>
>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?

"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".