www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - extern(C++) multiple inheritence

reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
I'm repeating this here from the depths of my prior whinge thread,
since this is kind of a new topic.

D's multiple inheritance solution is single-inheritance + interfaces.
Rightly so, it's a great solution, and this matches what all the C++
programmers I've ever worked with do anyway. Trouble is, it doesn't
seem to work with extern(C++) at the moment.

Note: this is my current hard-blocker. I can't progress without this.

Situation:

-------------------
In C++:

class Base
{
  virtual ~Base() {}
  size_t x;
};

class Interface
{
  virtual void A() = 0;
  virtual void B() = 0;
  virtual void C() = 0;
  virtual void Method() = 0;
};

class Derived : public Base, public Interface
{
  size_t y;
};

-------------------
D:

extern(C++) class Base
{
  ~this() {}
  size_t x;
}

extern(C++) interface Interface
{
  void A();
  void B();
  void C();
  void Method();
}

extern(C++) class Derived : Base, Interface
{
  size_t y;
}

-------------------

This code should work.


In C++, Derived is laid out:
{
  void *__Base_vtable;
  size_t x;
  void *__Interface_vtable;
  size_t y;
}

This is as I expect.

In D, according to the debuginfo output by DMD, Derived is reported as:
{
  void *__Base_vtable;
  size_t x;
  size_t y;
}

* The actual binary may not match the debuginfo; I didn't check, but
there is some evidence for this.

Surprisingly, this compiles, but calling Method generates wrong code:

00007FF72DB7381B  mov         rbx,qword ptr [this]
00007FF72DB7381F  mov         rcx,qword ptr [rbx+10h]  // rcx is now
__Interface_vtable!
00007FF72DB73823  mov         rcx,qword ptr [rcx]
00007FF72DB73826  sub         rsp,20h
00007FF72DB7382A  mov         rax,qword ptr [rcx]
00007FF72DB7382D  call        qword ptr [rax+18h]  // 18h is the
offset of Method, rax is wrong. [[rbx+10h]+18h] is the correct call.

We load rbx = [this], then we load rcx = [rbx+10h]. This looks good,
[rbx+10h] is the correct offset of __Interface_vtable in C++, even
though the debuginfo claims that's the offset of 'y'.
Then it gets weird; rcx = [rcx], this is effectively getting the first
function pointer in the vtable; A().
Then further compounding with rax = [rcx], loading the first 8 bytes
of program code from the function A()!
Finally it calls [rax+18h]. If rax were still __Interface_vtable, 18h
is the correct offset of the function I'm calling (Method), and it was
correct after the second opcode, but those 2 weird dereferences broke
it.

Hoping this can be supported, I can't move forward without this.
Jan 18 2016
parent reply Daniel Murphy <yebbliesnospam gmail.com> writes:
On 19/01/2016 4:10 PM, Manu via Digitalmars-d wrote:

 I'm repeating this here from the depths of my prior whinge thread,
 since this is kind of a new topic.

 D's multiple inheritance solution is single-inheritance + interfaces.
 Rightly so, it's a great solution, and this matches what all the C++
 programmers I've ever worked with do anyway. Trouble is, it doesn't
 seem to work with extern(C++) at the moment.


Yeah, it never has.  No attempt has ever been made to make it work.

If you want to take a look, it's probably not much more complicated than 
fixing the layout.  The code should mostly be somewhere in todt.c (when 
ClassDeclaration::cpp is non-zero).
Jan 19 2016
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/19/2016 12:34 AM, Daniel Murphy wrote:

 Yeah, it never has.  No attempt has ever been made to make it work.


Actually, as I recall it was made to match what DMC++ generates for Win32.
Jan 19 2016
parent reply Daniel Murphy <yebbliesnospam gmail.com> writes:
On 19/01/2016 8:04 PM, Walter Bright wrote:

 On 1/19/2016 12:34 AM, Daniel Murphy wrote:

 Yeah, it never has.  No attempt has ever been made to make it work.


 Actually, as I recall it was made to match what DMC++ generates for Win32.


Wasn't that from before we had extern(C++) classes?  I did the 
extern(C++) single inheritance class layout but didn't touch interfaces.
Jan 19 2016
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/19/2016 1:59 PM, Daniel Murphy wrote:

 On 19/01/2016 8:04 PM, Walter Bright wrote:

 On 1/19/2016 12:34 AM, Daniel Murphy wrote:

 Yeah, it never has.  No attempt has ever been made to make it work.


 Actually, as I recall it was made to match what DMC++ generates for Win32.


 Wasn't that from before we had extern(C++) classes?  I did the extern(C++)
 single inheritance class layout but didn't touch interfaces.


We had COM, which was an earlier form of C++ class support.
Jan 19 2016
parent IgorStepanov <wazar mail.ru> writes:
On Wednesday, 20 January 2016 at 00:45:34 UTC, Walter Bright 
wrote:

 On 1/19/2016 1:59 PM, Daniel Murphy wrote:

 On 19/01/2016 8:04 PM, Walter Bright wrote:

 On 1/19/2016 12:34 AM, Daniel Murphy wrote:

 Yeah, it never has.  No attempt has ever been made to make 
 it work.


 Actually, as I recall it was made to match what DMC++ 
 generates for Win32.


 Wasn't that from before we had extern(C++) classes?  I did the 
 extern(C++)
 single inheritance class layout but didn't touch interfaces.


 We had COM, which was an earlier form of C++ class support.


BTW, in docs I saw the following example:
Calling D Virtual Functions From C++

```
Given D code like:

extern (C++) int callE(E);

extern (C++) interface E
{
     int bar(int i, int j, int k);
}

class F : E
{
     extern (C++) int bar(int i, int j, int k)
     {
         writefln("i = %s", i);
         writefln("j = %s", j);
         writefln("k = %s", k);
         return 8;
     }
}

void main()
{
     F f = new F();
     callE(f);
}
```

```
The C++ code to access it looks like:

class E
{
   public:
     virtual int bar(int i, int j, int k);
};


int callE(E *e)
{
     return e->bar(11,12,13);
}
```


In this example C++ class E hasn't fields and another stuff. What 
happens if I change E?

class E
{
   std::string s;
   public:
     virtual int bar(int i, int j, int k);
     int strageHash()
     {
          return s.length() + bar(0, 0, 0);
     }
};

int callE(E *e)
{
     return e->strageHash();
}

AFAIK, D can't generate correct F layout. D doesn't know 
sizeof(E), D doesn't know E ctor (the second one is fixable).
As result, new F() object can be smaller that E and this code has 
an unexpected behaviour.
Ok, we aren't gods and we can't suggest something better 
(exclusive of moveing multiple inheritance and C++ layout to D :).
However we may and should alert user about this limitation and 
about another limitations like this.
And when we add a new C++-related feature, we should declare 
C++-side limitations, in the first place, because they can't be 
enforced by D compiler.

And have someone any ideas about C++ to D interface generator?
Jan 21 2016
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 01/19/2016 03:34 AM, Daniel Murphy wrote:

 On 19/01/2016 4:10 PM, Manu via Digitalmars-d wrote:

 I'm repeating this here from the depths of my prior whinge thread,
 since this is kind of a new topic.

 D's multiple inheritance solution is single-inheritance + interfaces.
 Rightly so, it's a great solution, and this matches what all the C++
 programmers I've ever worked with do anyway. Trouble is, it doesn't
 seem to work with extern(C++) at the moment.


 Yeah, it never has.  No attempt has ever been made to make it work.

 If you want to take a look, it's probably not much more complicated than
 fixing the layout.  The code should mostly be somewhere in todt.c (when
 ClassDeclaration::cpp is non-zero).


Is there an open issue? -- Andrei
Jan 19 2016
parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 19 January 2016 at 22:36, Andrei Alexandrescu via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 Is there an open issue? -- Andrei


There is: https://issues.dlang.org/show_bug.cgi?id=15579
Jan 19 2016
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 01/19/2016 09:02 AM, Manu via Digitalmars-d wrote:

 On 19 January 2016 at 22:36, Andrei Alexandrescu via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 Is there an open issue? -- Andrei


 There is: https://issues.dlang.org/show_bug.cgi?id=15579


Thanks, awesome. I've noticed this a while ago, but slipped off my mind 
before I reported it. -- Andrei
Jan 19 2016
parent deadalnix <deadalnix gmail.com> writes:
On Tuesday, 19 January 2016 at 15:25:53 UTC, Andrei Alexandrescu 
wrote:

 On 01/19/2016 09:02 AM, Manu via Digitalmars-d wrote:

 On 19 January 2016 at 22:36, Andrei Alexandrescu via 
 Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 Is there an open issue? -- Andrei


 There is: https://issues.dlang.org/show_bug.cgi?id=15579


 Thanks, awesome. I've noticed this a while ago, but slipped off 
 my mind before I reported it. -- Andrei


For reference: 
https://mentorembedded.github.io/cxx-abi/abi.html#vtable
Jan 19 2016
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/19/2016 6:02 AM, Manu via Digitalmars-d wrote:

 On 19 January 2016 at 22:36, Andrei Alexandrescu via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 Is there an open issue? -- Andrei


 There is: https://issues.dlang.org/show_bug.cgi?id=15579


https://github.com/D-Programming-Language/dmd/pull/5361

Unfortunately, that doesn't completely fix Win64, I'll follow up with one that
does.
Jan 22 2016
parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 23 January 2016 at 06:25, Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 1/19/2016 6:02 AM, Manu via Digitalmars-d wrote:

 On 19 January 2016 at 22:36, Andrei Alexandrescu via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 Is there an open issue? -- Andrei



 There is: https://issues.dlang.org/show_bug.cgi?id=15579


 https://github.com/D-Programming-Language/dmd/pull/5361

 Unfortunately, that doesn't completely fix Win64, I'll follow up with one
 that does.


I brought a work laptop home this weekend in anticipation ;)
Jan 22 2016
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/22/2016 5:46 PM, Manu via Digitalmars-d wrote:

 I brought a work laptop home this weekend in anticipation ;)


Here ya go:

   https://github.com/D-Programming-Language/dmd/pull/5364

Be wary of:

   https://issues.dlang.org/show_bug.cgi?id=15589

and use the workaround as necessary. This is lower priority, so I won't be 
dealing with it for a bit.
Jan 24 2016
next sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 24 January 2016 at 20:40, Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 1/22/2016 5:46 PM, Manu via Digitalmars-d wrote:

 I brought a work laptop home this weekend in anticipation ;)



 Here ya go:

   https://github.com/D-Programming-Language/dmd/pull/5364

 Be wary of:

   https://issues.dlang.org/show_bug.cgi?id=15589

 and use the workaround as necessary. This is lower priority, so I won't be
 dealing with it for a bit.


Next blocker: https://issues.dlang.org/show_bug.cgi?id=15610

C++ methods with multiple-inheritence expect that 'this' is a pointer
to the base class that introduced the function.
When using C++ 'interface's, which C++ just treats like normal
multiple-inheritence, C++ expects that the 'this' pointer is adjusted
to the offset of the interface's vtable.

If I have:
extern(C++) interface Interface { voif f(); }
extern(C++) class C : Base, Interface
{
  void f();
}

Calling c.f(), D is passing 'this' unaltered, but C++ expects 'this'
is a pointer to 'Interface', and then it crashes accessing members at
incorrect offsets.
Jan 25 2016
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/25/2016 9:02 PM, Manu via Digitalmars-d wrote:

 On 24 January 2016 at 20:40, Walter Bright via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On 1/22/2016 5:46 PM, Manu via Digitalmars-d wrote:

 I brought a work laptop home this weekend in anticipation ;)



 Here ya go:

    https://github.com/D-Programming-Language/dmd/pull/5364

 Be wary of:

    https://issues.dlang.org/show_bug.cgi?id=15589

 and use the workaround as necessary. This is lower priority, so I won't be
 dealing with it for a bit.


 Next blocker: https://issues.dlang.org/show_bug.cgi?id=15610

 C++ methods with multiple-inheritence expect that 'this' is a pointer
 to the base class that introduced the function.
 When using C++ 'interface's, which C++ just treats like normal
 multiple-inheritence, C++ expects that the 'this' pointer is adjusted
 to the offset of the interface's vtable.

 If I have:
 extern(C++) interface Interface { voif f(); }
 extern(C++) class C : Base, Interface
 {
    void f();
 }

 Calling c.f(), D is passing 'this' unaltered, but C++ expects 'this'
 is a pointer to 'Interface', and then it crashes accessing members at
 incorrect offsets.


The PR 5364 does this. (And only Microsoft Win64 has this effect.)
Jan 25 2016
next sibling parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 26 January 2016 at 15:11, Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 1/25/2016 9:02 PM, Manu via Digitalmars-d wrote:

 On 24 January 2016 at 20:40, Walter Bright via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On 1/22/2016 5:46 PM, Manu via Digitalmars-d wrote:

 I brought a work laptop home this weekend in anticipation ;)




 Here ya go:

    https://github.com/D-Programming-Language/dmd/pull/5364

 Be wary of:

    https://issues.dlang.org/show_bug.cgi?id=15589

 and use the workaround as necessary. This is lower priority, so I won't
 be
 dealing with it for a bit.



 Next blocker: https://issues.dlang.org/show_bug.cgi?id=15610

 C++ methods with multiple-inheritence expect that 'this' is a pointer
 to the base class that introduced the function.
 When using C++ 'interface's, which C++ just treats like normal
 multiple-inheritence, C++ expects that the 'this' pointer is adjusted
 to the offset of the interface's vtable.

 If I have:
 extern(C++) interface Interface { voif f(); }
 extern(C++) class C : Base, Interface
 {
    void f();
 }

 Calling c.f(), D is passing 'this' unaltered, but C++ expects 'this'
 is a pointer to 'Interface', and then it crashes accessing members at
 incorrect offsets.


 The PR 5364 does this. (And only Microsoft Win64 has this effect.)


Oh okay. I thought that PR was about correctly locating the vtable and
function offsets. I'll wait till that's merged.
Jan 25 2016
prev sibling next sibling parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 26 January 2016 at 15:20, Manu <turkeyman gmail.com> wrote:

 On 26 January 2016 at 15:11, Walter Bright via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On 1/25/2016 9:02 PM, Manu via Digitalmars-d wrote:

 On 24 January 2016 at 20:40, Walter Bright via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On 1/22/2016 5:46 PM, Manu via Digitalmars-d wrote:

 I brought a work laptop home this weekend in anticipation ;)




 Here ya go:

    https://github.com/D-Programming-Language/dmd/pull/5364

 Be wary of:

    https://issues.dlang.org/show_bug.cgi?id=15589

 and use the workaround as necessary. This is lower priority, so I won't
 be
 dealing with it for a bit.



 Next blocker: https://issues.dlang.org/show_bug.cgi?id=15610

 C++ methods with multiple-inheritence expect that 'this' is a pointer
 to the base class that introduced the function.
 When using C++ 'interface's, which C++ just treats like normal
 multiple-inheritence, C++ expects that the 'this' pointer is adjusted
 to the offset of the interface's vtable.

 If I have:
 extern(C++) interface Interface { voif f(); }
 extern(C++) class C : Base, Interface
 {
    void f();
 }

 Calling c.f(), D is passing 'this' unaltered, but C++ expects 'this'
 is a pointer to 'Interface', and then it crashes accessing members at
 incorrect offsets.


 The PR 5364 does this. (And only Microsoft Win64 has this effect.)


 Oh okay. I thought that PR was about correctly locating the vtable and
 function offsets. I'll wait till that's merged.
Jan 25 2016
prev sibling next sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 26 January 2016 at 15:20, Manu <turkeyman gmail.com> wrote:

 On 26 January 2016 at 15:11, Walter Bright via Digitalmars-d

 The PR 5364 does this. (And only Microsoft Win64 has this effect.)


 Oh okay. I thought that PR was about correctly locating the vtable and
 function offsets. I'll wait till that's merged.


I tried to build DMD myself, doesn't build with vs2015:
https://issues.dlang.org/show_bug.cgi?id=15611

*sigh* .. everything's always so hard! It's exhausting.
Jan 25 2016
parent reply Daniel Murphy <yebbliesnospam gmail.com> writes:
On 26/01/2016 5:29 PM, Manu via Digitalmars-d wrote:

 I tried to build DMD myself, doesn't build with vs2015:
 https://issues.dlang.org/show_bug.cgi?id=15611

 *sigh* .. everything's always so hard! It's exhausting.


Get with the times, vs2015 is so last year.
Jan 25 2016
parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 26 January 2016 at 16:33, Daniel Murphy via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 26/01/2016 5:29 PM, Manu via Digitalmars-d wrote:

 I tried to build DMD myself, doesn't build with vs2015:
 https://issues.dlang.org/show_bug.cgi?id=15611

 *sigh* .. everything's always so hard! It's exhausting.


 Get with the times, vs2015 is so last year.


Why doesn't the CI matrix build with all common compilers?
Jan 25 2016
prev sibling next sibling parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 26 January 2016 at 15:20, Manu <turkeyman gmail.com> wrote:

 On 26 January 2016 at 15:11, Walter Bright via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On 1/25/2016 9:02 PM, Manu via Digitalmars-d wrote:

 On 24 January 2016 at 20:40, Walter Bright via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On 1/22/2016 5:46 PM, Manu via Digitalmars-d wrote:

 I brought a work laptop home this weekend in anticipation ;)




 Here ya go:

    https://github.com/D-Programming-Language/dmd/pull/5364

 Be wary of:

    https://issues.dlang.org/show_bug.cgi?id=15589

 and use the workaround as necessary. This is lower priority, so I won't
 be
 dealing with it for a bit.



 Next blocker: https://issues.dlang.org/show_bug.cgi?id=15610

 C++ methods with multiple-inheritence expect that 'this' is a pointer
 to the base class that introduced the function.
 When using C++ 'interface's, which C++ just treats like normal
 multiple-inheritence, C++ expects that the 'this' pointer is adjusted
 to the offset of the interface's vtable.

 If I have:
 extern(C++) interface Interface { voif f(); }
 extern(C++) class C : Base, Interface
 {
    void f();
 }

 Calling c.f(), D is passing 'this' unaltered, but C++ expects 'this'
 is a pointer to 'Interface', and then it crashes accessing members at
 incorrect offsets.


 The PR 5364 does this. (And only Microsoft Win64 has this effect.)


 Oh okay. I thought that PR was about correctly locating the vtable and
 function offsets. I'll wait till that's merged.


Okay, tried today's nightly [1]; built 27-Jan-2016 05:22
Jan 27 2016
prev sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 26 January 2016 at 15:20, Manu <turkeyman gmail.com> wrote:

 On 26 January 2016 at 15:11, Walter Bright via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On 1/25/2016 9:02 PM, Manu via Digitalmars-d wrote:

 On 24 January 2016 at 20:40, Walter Bright via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On 1/22/2016 5:46 PM, Manu via Digitalmars-d wrote:

 I brought a work laptop home this weekend in anticipation ;)




 Here ya go:

    https://github.com/D-Programming-Language/dmd/pull/5364

 Be wary of:

    https://issues.dlang.org/show_bug.cgi?id=15589

 and use the workaround as necessary. This is lower priority, so I won't
 be
 dealing with it for a bit.



 Next blocker: https://issues.dlang.org/show_bug.cgi?id=15610

 C++ methods with multiple-inheritence expect that 'this' is a pointer
 to the base class that introduced the function.
 When using C++ 'interface's, which C++ just treats like normal
 multiple-inheritence, C++ expects that the 'this' pointer is adjusted
 to the offset of the interface's vtable.

 If I have:
 extern(C++) interface Interface { voif f(); }
 extern(C++) class C : Base, Interface
 {
    void f();
 }

 Calling c.f(), D is passing 'this' unaltered, but C++ expects 'this'
 is a pointer to 'Interface', and then it crashes accessing members at
 incorrect offsets.


 The PR 5364 does this. (And only Microsoft Win64 has this effect.)


 Oh okay. I thought that PR was about correctly locating the vtable and
 function offsets. I'll wait till that's merged.


Tried today's nightly (https://builds.dawg.eu/dmd-nightly/)
Built 27-Jan-2016 05:22, which is definitely after 5364 was merged
("committed 21 hours ago", which was during the 26th)
Still crashes. Setup looks similar; leading to the call, RAX is the
vtable and RCX is 'this', there is a moment prior to the call where
they are both correct for the call, and then there are few extra
opcodes which dereferences each of them until they are rubbish values,
then tries to make the call, which jumps to a bad address.

Bit of this: https://img42.com/oqN6y ;)

I am off work for 3 weeks from Friday, I don't think I have any more
time for this sadly.
Jan 27 2016
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/27/2016 2:50 AM, Manu via Digitalmars-d wrote:

 On 26 January 2016 at 15:20, Manu <turkeyman gmail.com> wrote:

 On 26 January 2016 at 15:11, Walter Bright via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On 1/25/2016 9:02 PM, Manu via Digitalmars-d wrote:

 Next blocker: https://issues.dlang.org/show_bug.cgi?id=15610






 Tried today's nightly (https://builds.dawg.eu/dmd-nightly/)
 Built 27-Jan-2016 05:22, which is definitely after 5364 was merged
 ("committed 21 hours ago", which was during the 26th)
 Still crashes. Setup looks similar; leading to the call, RAX is the
 vtable and RCX is 'this', there is a moment prior to the call where
 they are both correct for the call, and then there are few extra
 opcodes which dereferences each of them until they are rubbish values,
 then tries to make the call, which jumps to a bad address.

 Bit of this: https://img42.com/oqN6y ;)


I can't do anything with this, as the code submitted in the bug report is 
incomplete.


 I am off work for 3 weeks from Friday, I don't think I have any more
 time for this sadly.


Have a nice vacation, look forward to you getting back!
Jan 27 2016
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/27/2016 3:56 PM, Walter Bright wrote:

 I can't do anything with this, as the code submitted in the bug report is
 incomplete.


I think the problem is the 'final'. Try removing it as a workaround.
Jan 27 2016
parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 28 January 2016 at 10:27, Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 1/27/2016 3:56 PM, Walter Bright wrote:

 I can't do anything with this, as the code submitted in the bug report is
 incomplete.



 I think the problem is the 'final'. Try removing it as a workaround.


Okay, I can try that quickly tonight.
99% of functions are final, and about 80% of virtual functions are final too.
Jan 27 2016
parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/27/2016 4:45 PM, Manu via Digitalmars-d wrote:

 I think the problem is the 'final'. Try removing it as a workaround.


 Okay, I can try that quickly tonight.
 99% of functions are final, and about 80% of virtual functions are final too.


I understand, and I'll see if I can figure out a proper fix. Thanks for your 
patience with this!
Jan 27 2016
prev sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 28 January 2016 at 09:56, Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 1/27/2016 2:50 AM, Manu via Digitalmars-d wrote:

 On 26 January 2016 at 15:20, Manu <turkeyman gmail.com> wrote:

 On 26 January 2016 at 15:11, Walter Bright via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On 1/25/2016 9:02 PM, Manu via Digitalmars-d wrote:

 Next blocker: https://issues.dlang.org/show_bug.cgi?id=15610






 Tried today's nightly (https://builds.dawg.eu/dmd-nightly/)
 Built 27-Jan-2016 05:22, which is definitely after 5364 was merged
 ("committed 21 hours ago", which was during the 26th)
 Still crashes. Setup looks similar; leading to the call, RAX is the
 vtable and RCX is 'this', there is a moment prior to the call where
 they are both correct for the call, and then there are few extra
 opcodes which dereferences each of them until they are rubbish values,
 then tries to make the call, which jumps to a bad address.

 Bit of this: https://img42.com/oqN6y ;)



 I can't do anything with this, as the code submitted in the bug report is
 incomplete.


I hoped the winkey face would imply that this was a joke...
Although the joke's on me; the point is, it takes me a really long
time to trace through and try and understand what's going on. Finding
my way to this image is not a short process. It was 2am before trying
to reduce what I found... didn't get to it last night >_<
Jan 27 2016
parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/27/2016 4:43 PM, Manu via Digitalmars-d wrote:

 I hoped the winkey face would imply that this was a joke...
 Although the joke's on me; the point is, it takes me a really long
 time to trace through and try and understand what's going on. Finding
 my way to this image is not a short process. It was 2am before trying
 to reduce what I found... didn't get to it last night >_<


I understand and appreciate your efforts. And another upside of small examples 
is they go into the test suite so they *stay* fixed! Nobody likes regressions.
Jan 27 2016
prev sibling parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 26 January 2016 at 15:02, Manu <turkeyman gmail.com> wrote:

 On 24 January 2016 at 20:40, Walter Bright via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On 1/22/2016 5:46 PM, Manu via Digitalmars-d wrote:

 I brought a work laptop home this weekend in anticipation ;)



 Here ya go:

   https://github.com/D-Programming-Language/dmd/pull/5364

 Be wary of:

   https://issues.dlang.org/show_bug.cgi?id=15589

 and use the workaround as necessary. This is lower priority, so I won't be
 dealing with it for a bit.


 Next blocker: https://issues.dlang.org/show_bug.cgi?id=15610

 C++ methods with multiple-inheritence expect that 'this' is a pointer
 to the base class that introduced the function.
 When using C++ 'interface's, which C++ just treats like normal
 multiple-inheritence, C++ expects that the 'this' pointer is adjusted
 to the offset of the interface's vtable.

 If I have:
 extern(C++) interface Interface { voif f(); }
 extern(C++) class C : Base, Interface
 {
   void f();
 }

 Calling c.f(), D is passing 'this' unaltered, but C++ expects 'this'
 is a pointer to 'Interface', and then it crashes accessing members at
 incorrect offsets.


Also, bugs in the name mangling are really becoming a problem. I have
logged several bugs of this sort, but my code has developed a serious
case of pragma(mangle, "??XYZ.....") appearing all over the place to
make it link.

https://issues.dlang.org/show_bug.cgi?id=15608
https://issues.dlang.org/show_bug.cgi?id=15576
https://issues.dlang.org/show_bug.cgi?id=15473

This is not a blocker, but I think it's high priority.
Jan 25 2016