digitalmars.D.learn - Strange error with templates and inheritance.
- Frank Fischer <frank.fischer s2001.tu-chemnitz.de> Aug 04 2007
- Robert Fraser <fraserofthenight gmail.com> Aug 04 2007
- Ary Manzana <ary esperanto.org.ar> Aug 04 2007
- Manfred Nowak <svv1999 hotmail.com> Aug 04 2007
Hi,
i'm currently developing a library and I heavily use templates and multiple
inheritance (of interfaces, of course). The following inheritance structure
is used (I removed all methods that are not important to show the error):
---
module mytest;
import std.stdio;
interface A(T) {
C!(T) func();
size_t f();
}
abstract class B(T): A!(T) {
}
interface C(T): A!(T) {
}
class D: B!(int), C!(int) {
size_t f() { return 42; }
C!(int) func() { return this; }
}
void main() {
A!(int) x = new D();
writefln("%d", x.f());
}
---
When I compile this snippet with dmd 2.003 on my linux-box, I get a
segmentation fault on the call "x.f()" in the last line. Furthermore, if I
use an interface instead of an abstract class for B, everything is fine.
Even if I just change the order of definition of 'func' and 'f' in A, i.e.
interface A(T) {
size_t f();
C!(T) func();
}
everything works.
Can anyone reproduce this error and/or explain it? In my library I
can't/want to change B into an interface, because the class should contain
some methods.
Thanks,
Frank
Aug 04 2007
Frank Fischer Wrote:Hi, i'm currently developing a library and I heavily use templates and multiple inheritance (of interfaces, of course). The following inheritance structure is used (I removed all methods that are not important to show the error): --- module mytest; import std.stdio; interface A(T) { C!(T) func(); size_t f(); } abstract class B(T): A!(T) { } interface C(T): A!(T) { } class D: B!(int), C!(int) { size_t f() { return 42; } C!(int) func() { return this; } } void main() { A!(int) x = new D(); writefln("%d", x.f()); } --- When I compile this snippet with dmd 2.003 on my linux-box, I get a segmentation fault on the call "x.f()" in the last line. Furthermore, if I use an interface instead of an abstract class for B, everything is fine. Even if I just change the order of definition of 'func' and 'f' in A, i.e. interface A(T) { size_t f(); C!(T) func(); } everything works. Can anyone reproduce this error and/or explain it? In my library I can't/want to change B into an interface, because the class should contain some methods. Thanks, Frank
Sounds like a bug. You have your minimal code sample there, report it.
Aug 04 2007
Robert Fraser escribió:Frank Fischer Wrote:Hi, i'm currently developing a library and I heavily use templates and multiple inheritance (of interfaces, of course). The following inheritance structure is used (I removed all methods that are not important to show the error): --- module mytest; import std.stdio; interface A(T) { C!(T) func(); size_t f(); } abstract class B(T): A!(T) { } interface C(T): A!(T) { } class D: B!(int), C!(int) { size_t f() { return 42; } C!(int) func() { return this; } } void main() { A!(int) x = new D(); writefln("%d", x.f()); } --- When I compile this snippet with dmd 2.003 on my linux-box, I get a segmentation fault on the call "x.f()" in the last line. Furthermore, if I use an interface instead of an abstract class for B, everything is fine. Even if I just change the order of definition of 'func' and 'f' in A, i.e. interface A(T) { size_t f(); C!(T) func(); } everything works. Can anyone reproduce this error and/or explain it? In my library I can't/want to change B into an interface, because the class should contain some methods. Thanks, Frank
Sounds like a bug. You have your minimal code sample there, report it.
Yes, it sounds like a bug to me too. I tried to debug the code and x.f() leads to D.func(), and then it crashes. Further, in the access violation exception the function _d_invariant in module invariant.d (phobos/internal) is named.
Aug 04 2007
Ary Manzana wroteI tried to debug the code and x.f() leads to D.func(), and then it crashes.
This throws some light into the matter. In fact, I have reported an analogue "feature" before, but all I got was a remark that it has to be this way, because D is a system programming language. -manfred
Aug 04 2007








Manfred Nowak <svv1999 hotmail.com>