I asked about this issue on stackoverflow, thinking I had made a mistake. The url is http://stackoverflow.com/questions/9752414/why-do-i-need-opcmp-for-an-anonymous-class and includes details on how and why I discovered the problem.
Using DMD on Windows, if I return an anonymous class derived directly from an interface from an anonymous function, the results are erratic and unpredictable. I believe this is because the vtbl layout is not consistent between the anonymous function creating the object and any clients of the object. An example:
interface TestInterface {
string helloWorld();
}
class TestClass {
abstract string helloWorld();
}
void invokeFn(TestInterface function() f) {
auto t = f();
auto s = t.helloWorld();
writeln(s);
}
unittest {
auto f = function() {
return new class TestInterface {
string helloWorld() {
return "Hello World!";
}
};
};
// Invokes (f()).toString(), printing:
// "src.utilities.testopcmp.__unittest2.__funcliteral1.__anonclass10"
invokeFn(f);
}
void invokeFn(TestClass function() f) {
auto t = f();
auto s = t.helloWorld();
writeln(s);
}
unittest {
auto f = function() {
return new class TestClass {
string helloWorld() {
return "Goodbye World!";
}
};
};
// Invokes (f()).helloWorld(), printing:
// "Goodbye World!" as expected
invokeFn(f);
}
This may be a minor bug in the compiler or in object.d? If so, then a fix would be appreciated. However, as abstract classes work correctly under the same circumstances, if the issue is that interfaces *should not* be anonymously instantiated (actually seems pretty reasonable) then that could be documented and the above code could throw an error. In that case, even if the interface is fixed, the anonymous function could probably declare a static nested abstract class, and inherit that class. Thanks!
Comment #1 by robert.schadek — 2024-12-13T17:59:18Z