FreeBASIC and C++ interop current status?

[systemctl]

I saw the examples for C++ under other-language directory and I notice FreeBASIC could use C++ library directly and supports C++ namespace, simple classes and operator overloading but just that. More advanced features like template and more complex classes support seemed to be missing. So I think with it current status we still have to rely on a C wrapper and can't use C++ library like FLTK directly.

[dodicat]

C++ template does a similar job to a freebasic macro, so it certainly looks like you cannot pass on a template via a dll.
I was experimenting here:
viewtopic.php?f=7&t=28468
11 posts down, vectors.zip
Class methods are not passed directly, a little tweak is required.
Constructors and operators also, a little tweak.
It all looks a bit quaint because the decorated names are used.
If you download vectors to have a look there is also a dll to translate decorated names to a more readable form.
I am looking around for a small C++ library to experiment with.

[systemctl]

I am looking around for a small C++ library to experiment with.

I want to use the FOX Toolkit from FreeBASIC (fox-toolkit.org) but I found it's to be difficult to install. So now I think you should try FLTK. FLTK is considered as small (even though I don't think so) and is packaged by most Linux distributions. No need to compile from source, just fire up the package manager and done.

[TeeEmCee]

It all looks a bit quaint because the decorated names are used.

I thought that fbc decorates method names and overloaded functions in the same way as gcc? But IIRC there are some edge cases involving certain types of constructor where it isn't compatible yet. And I don't know how good the ABI compatibility is in general, eg for vtable layout. But there's clearly an ambition for FB and g++ to be ABI compatible for the subset of C++ that FB supports (e.g. no multiple inheritance).

[Xusinboy Bekchanov]

It all looks a bit quaint because the decorated names are used.

I thought that fbc decorates method names and overloaded functions in the same way as gcc? But IIRC there are some edge cases involving certain types of constructor where it isn't compatible yet. And I don't know how good the ABI compatibility is in general, eg for vtable layout. But there's clearly an ambition for FB and g++ to be ABI compatible for the subset of C++ that FB supports (e.g. no multiple inheritance).

I think we need to add multiple inheritance to FreeBasic. It only improve FreeBasic.

[caseih]

Indeed FBC does decorate method names and overloaded functions in the same way as gcc. However you need a lot more than that to interact with most C++ classes, particularly ones that involve virtual methods (polymorphism). That requires the ability to interact with C++ objects' vtables at runtime to dispatch the calls. As near as I can tell, FB has no understanding of C++'s vtables. To say nothing of templates, closures, and other things that are common in modern C++ libraries.

And actually you can't even mix C++ object code between C++ compilers even! Although I think recent standards are improving the ABI compatibility between different C++ compilers.

FB could never be ABI compatible with C++ unless it implemented the exact object model that C++ implements, which would make FB basically C++ with an FB syntax. Is that desirable?

C++ has always been a difficult language to interoperate with, from any language. Most languages bind to C++ libraries using C++-based wrappers that expose a simpler C-style API that can more easily be wrapped by the language in question. This C++ wrapper would manage the C++ objects. This is how PyQt works with Qt, for example. It can get very convoluted and prone to subtle problems, however. PyQt has a python object that exists for every C++ object and goes to great lengths to hide that fact and keep them synchronized. It's amazing it works as well as it has. I did find a subtle problem once, where a C++ object got deleted out from under me due to some garbage collection issues with references. Point is, it's tricky!

I would think that wrapping a library written in any object-oriented language is going to be difficult for another language that has differences in the object model, memory management, etc.

I think we need to add multiple inheritance to FreeBasic. It only improve FreeBasic.

Who's this "we" you refer to? Are you volunteering to begin the effort?

[systemctl]

It all looks a bit quaint because the decorated names are used.

I thought that fbc decorates method names and overloaded functions in the same way as gcc? But IIRC there are some edge cases involving certain types of constructor where it isn't compatible yet. And I don't know how good the ABI compatibility is in general, eg for vtable layout. But there's clearly an ambition for FB and g++ to be ABI compatible for the subset of C++ that FB supports (e.g. no multiple inheritance).

I think we need to add multiple inheritance to FreeBasic. It only improve FreeBasic.

I don't think so. I prefer the Java OOP system.

[TeeEmCee]

Right. I jumped to the conclusion that total interoperability with a subset of C++ was the goal. But there are other reasons for doing name mangling in the same way, such as: it's sane to follow standards, be able to use the standard "c++filt" name demangling tool, or just being able to call regular C++ functions.

Also, apologies to forum regulars, I've just discovered this was all discussed at length recently in the FreeBASIC 1.08 Development thread, in particular by coderJeff. That link he posted was interesting, https://dlang.org/spec/cpp_interface.html which says that D has vtable interop with C++ classes with single inheritance.
I'm speaking from ignorance but would think that implementing a vtable compatible with gcc is quite achievable.
Note also that D has interop with MSVC++ on Windows, something FB probably wouldn't care much for, being wedded to gcc.

Multiple inheritance isn't on my wishlist.

[angros47]

Personally, I am trying translating at least in part the FLTK headers from C++ to FreeBasic, and so far, they seem to work (linux 32 bits). The main difference is that, since FreeBasic doesn't support inlining, methods that are implemented directly in the header can't be supported in the same way.

So far, I managed to get a FLTK window with a button to display, using FreeBasic, using no wrapper, and coding in OOP style.

[marcov]

I don't think so. I prefer the Java OOP system.

Java has interfaces that are also a form of MI.

[Xusinboy Bekchanov]

I think we need to add multiple inheritance to FreeBasic. It only improve FreeBasic.

Who's this "we" you refer to? Are you volunteering to begin the effort?

I’m not ready yet, there’s a lot to learn.

[TeeEmCee]

Java has interfaces that are also a form of MI.

Yes, I think that was systemctl's point. Since only one base class can contain members, most of the nasty complexity of MI disappears. No offsetting pointers when casting to a base class, no need for multiple vtable pointers. I read that Java interfaces can't have constructors, so maybe method resolution order in diamond inheritance shapes (e.g. the order in which constructors are called) isn't a problem either?

(Note: I don't actually know Java, or any other language that does single inheritance + interfaces)

The main difference is that, since FreeBasic doesn't support inlining, methods that are implemented directly in the header can't be supported in the same way.

As I said in another thread, the closest equivalent in FB to C's "inline"* is "private". Mark a sub/function private and it'll be safe to put in a .bi and is likely to be inlined if using -gen gcc (or be removed if not used). If using -gen gas then you get some bloat and no inlining.

Anyway, cool! I was interested in using FLTK in FB.

*In C, "inline", "extern inline" and "static inline" are three different things and vary by C standard. "private" is actually equivalent to C's "static".

[systemctl]

snipped by moderator

Please don't hijack my thread.

[Imortis]

Thanks. I missed this one.

[angros47]

My first results are here: viewtopic.php?f=7&t=28527