www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - How to use inheritance when interfacing with C++ classes?

reply rempas <rempas tutanota.com> writes:
I would like to interface with a C++ library called 
[FLTK](https://www.fltk.org/). I'm trying to implement the 
binding for the classes based to what I've read 
[here](https://dlang.org/spec/cpp_interface.html#classes) but it 
seems that It doesn't work as expected for me. I want to 
implement the "abstract" class "Fl_Widget" and the class 
"Fl_Group" which inherits from the "Fl_Widget". I will put a part 
of the code as there is no reason to put the whole code and make 
the post unnecessarily big. If in any case however, you need the 
whole reference: 
[Fl_Widget](https://fltk.gitlab.io/fltk/classFl__Widget.html) and 
[Fl_Group](https://fltk.gitlab.io/fltk/classFl__Group.html). Here 
is the code:

```
extern(C++) {
   abstract class Fl_Widget {
     void   _clear_fullscreen();
     void   _set_fullscreen();
   }

   class Fl_Group : Fl_Widget {
     ref Fl_Widget*    _ddfdesign_kludge();
     void              add(ref Fl_Widget);
     void              add(Fl_Widget*o);
   }
}
```

Normally this should work but the "Fl_Group" class makes in bug 
and I'm getting the following error message:

```
Linking...
/usr/bin/ld: 
.dub/build/application-debug-linux.posix-x86_64-dmd_v2.098.0-A4E26D206D34B9B9CA1A0366B3CE0F2C/dfltk.o:(.data._D4test8Fl
Group6__vtblZ+0x0): undefined reference to `Fl_Widget::_clear_fullscreen()'
/usr/bin/ld: 
.dub/build/application-debug-linux.posix-x86_64-dmd_v2.098.0-A4E26D206D34B9B9CA1A0366B3CE0F2C/dfltk.o:(.data._D4test8Fl
Group6__vtblZ+0x8): undefined reference to `Fl_Widget::_set_fullscreen()'
/usr/bin/ld: 
.dub/build/application-debug-linux.posix-x86_64-dmd_v2.098.0-A4E26D206D34B9B9CA1A0366B3CE0F2C/dfltk.o:(.data._D4test8Fl_
roup6__vtblZ+0x10): undefined reference to `Fl_Group::_ddfdesign_kludge()'
/usr/bin/ld: 
.dub/build/application-debug-linux.posix-x86_64-dmd_v2.098.0-A4E26D206D34B9B9CA1A0366B3CE0F2C/dfltk.o:(.data._D4test8Fl_
roup6__vtblZ+0x18): undefined reference to `Fl_Group::add(Fl_Widget*&)'
/usr/bin/ld: 
.dub/build/application-debug-linux.posix-x86_64-dmd_v2.098.0-A4E26D206D34B9B9CA1A0366B3CE0F2C/dfltk.o:(.data._D4test8Fl_
roup6__vtblZ+0x20): undefined reference to `Fl_Group::add(Fl_Widget**)'
collect2: error: ld returned 1 exit status
Error: linker exited with status 1
```

Anyone has an idea?
Dec 09 2021
parent reply Tim <tim.dlang t-online.de> writes:
On Thursday, 9 December 2021 at 19:05:08 UTC, rempas wrote:

 Anyone has an idea?


The referenced methods like Fl_Widget::_clear_fullscreen are 
implemented directly in the header, so the D code also needs the 
implementation, because it is not included in the compiled 
library.

Methods, which are not virtual in C++, also have to be marked 
final in D, because C++ and D use a different default.
Dec 09 2021
parent reply rempas <rempas tutanota.com> writes:
On Thursday, 9 December 2021 at 21:35:14 UTC, Tim wrote:

 The referenced methods like Fl_Widget::_clear_fullscreen are 
 implemented directly in the header, so the D code also needs 
 the implementation, because it is not included in the compiled 
 library.


What is funny about that is that I looked an the official class 
reference and copy pasted the code from here but I also looked at 
the header files and saw what you said but for some reason it 
completely slipped from my head...


 Methods, which are not virtual in C++, also have to be marked 
 final in D, because C++ and D use a different default.


Is this a must or just good practices?
Dec 10 2021
parent reply Tim <tim.dlang t-online.de> writes:
On Friday, 10 December 2021 at 12:46:07 UTC, rempas wrote:

 On Thursday, 9 December 2021 at 21:35:14 UTC, Tim wrote:

 Methods, which are not virtual in C++, also have to be marked 
 final in D, because C++ and D use a different default.


 Is this a must or just good practices?


All virtual methods have to match exactly including order. If a 
virtual method is missing or added, then calling this or a later 
virtual method could call the wrong method or generate a 
segmentation fault. Non-virtual methods have to be marked final 
in D, but can also be removed.
Dec 10 2021
parent rempas <rempas tutanota.com> writes:
On Friday, 10 December 2021 at 16:42:33 UTC, Tim wrote:

 All virtual methods have to match exactly including order. If a 
 virtual method is missing or added, then calling this or a 
 later virtual method could call the wrong method or generate a 
 segmentation fault. Non-virtual methods have to be marked final 
 in D, but can also be removed.


Great info! I'll have everything in mind! Thanks a lot and have 
an amazing day!!!
Dec 10 2021