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

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.

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.

Ary Manzana wrote

> I 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