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