On Mon, 08 Mar 2010 01:54:12 -0500, Walter Bright
<newshou...@digitalmars.com> wrote:
Lots of meat and potatoes here, and a cookie! (spelling checker for
error messages)
http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.057.zip
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.041.zip
Thanks to the many people who contributed to this update!
This might belong on d.learn, but it's so specific to this release, I'll
ask here:
The implementation of opEquals(Object, Object) contains the following
implementation (according to docs and source):
bool opEquals(Object a, Object b) {
if (a is b) return true;
if (a is null || b is null) return false;
if (typeid(a) == typeid(b)) return a.opEquals(b);
return a.opEquals(b) && b.opEquals(a);
}
The third line seems to be a recursive call into opEquals, since the
typeinfos are objects. But because the two typeid classes have the same
typeinfo (TypeInfo_Class with class name "TypeInfo_Class") it will only go
2 levels deep since the first if clause will be true. However, it seems a
bit redundant to verify that the typeids are not null (they will always be
non-null) and have the same typeinfo (they will).
Wouldn't it be more efficient and correct to just do:
if(typeid(a).opEquals(typeid(b)))
Also, there is a function inside object implementation to compare two
typeinfos (commented out in interface file), is that used? Does the
compiler allow overloading the global opEquals?
Also, const is not respected:
class C
{
int x;
bool opEquals(Object other){ ++x; return false;}
}
void main()
{
const c = new C;
const d = new D;
assert(c != d);
}
compiles without complaint. I would argue that opEquals should be const
in both Object and the global function, but I'm not sure of the
ramifications. At the very least, the above should not compile.
-Steve
