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?
