Pointers, casting, SetGetWindowLong problem...

Chris Warwick sp at m.me.not
Sat Mar 10 04:29:20 PST 2007


"Jarrett Billingsley" <kb3ctd2 at yahoo.com> wrote in message 
news:est9bb$1pac$1 at digitalmars.com...
> "Chris Warwick" <sp at m.me.not> wrote in message 
> news:est492$1igu$1 at digitalmars.com...
>>
>> Seems odd that it's even implemented at all, = is not overloadable if i 
>> understood the docs right,
>
> Nope, it's assignable with opAssign.  There are restrictions, but it can 
> be overloaded.

For objects? Wouldnt that make assigning to a null object imposible?

MyObj obj = obj2;

if opAssign is overloaded that will always be

null.opAssign(obj2);

wont it?


>> and I cant see add or sub being overloaded in Object.. So why implement 
>> opEquals? Especialy when it's basicly worse than (obj1 is obj2).
>
> It's implemented for associative arrays to work properly.
>
>> Unless it's a cunning ploy, using AV faults to cattle prod people into 
>> using 'is'.
>
> Well == and 'is' have two entirely different purposes.  == is only for 
> seeing if two things have the same _value_, while 'is' is used to see if 
> _two references point to the same instance_.  == is perfectly fine to use 
> on class instances -- as long as they're not null!  It's just like any 
> other method.

Just feels kinda wrong to me. Objects are referance types, passed by, and 
managed by referance, so imo == and = should test and assign referance not 
value.

Although i guess it does seem logical to make a clearer distinction between 
equality and identity, so maybe ill get used to it.

cheers,

cw 




More information about the Digitalmars-d-learn mailing list