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