extern(C++) multiple inheritence

IgorStepanov via Digitalmars-d digitalmars-d at puremagic.com
Thu Jan 21 19:13:12 PST 2016


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?






More information about the Digitalmars-d mailing list