Well, the first problem is that there is no "C++" abi to interface. Every C++ compiler has its own rules wrt mangling and other details.Right, this is what I was hoping someone had a solution to. It looks like Rust provides a library for demangling LLVM names. I'm not sure how good an idea this ultimately is.
The easiest way to do this is to also have a Free C++ compiler and keep it strictly aligned to FPC. (more or less like Embacadero does with C++ builder and Delphi)Well, if that is indeed the best solution I do not see it happening very soon.
Well, the first problem is that there is no "C++" abi to interface. Every C++ compiler has its own rules wrt mangling and other details.Right, this is what I was hoping someone had a solution to. It looks like Rust provides a library for demangling LLVM names. I'm not sure how good an idea this ultimately is.
The easiest way to do this is to also have a Free C++ compiler and keep it strictly aligned to FPC. (more or less like Embacadero does with C++ builder and Delphi)Well, if that is indeed the best solution I do not see it happening very soon.
Another might be exposing "class" information in C linkage blocks. This is why I had been asking about COM/GObject, though I think FreePascal could do far better than either.
Hopefully it can be seen that these two are kind of related.
What about using FPC code from C/C++ without shoving everything through a dynamic library?
Sorry, a linkage block looks like:
extern "C" { void exported_function(void); }
The only valid string is typically "C" but GCC has supported one nontraditional one, "Java," which created virtual method tables that would interop. with GCC's now defunct Java compiler.
Is there any code available that shows parsing the RTTI from C?
Ideally I'm wanting to get everything but COM working (I don't care too much for Windows, and it already half-works) but for one person it is definitely a multiyear project.
Well, one could try to use the spiritual predecessor of COM: SOM (https://en.wikipedia.org/wiki/IBM_System_Object_Model). Originally developed by IBM for OS/2 there exists an open source implementation (https://sourceforge.net/p/somfree/wiki/Home/) of it, though it would need an Object Pascal emitter.QuoteIdeally I'm wanting to get everything but COM working (I don't care too much for Windows, and it already half-works) but for one person it is definitely a multiyear project.
COM is the only somewhat mature option that already exists. And I don't see anything else happening anytime soon.
Well, one could try to use the spiritual predecessor of COM: SOM (https://en.wikipedia.org/wiki/IBM_System_Object_Model). Originally developed by IBM for OS/2 there exists an open source implementation (https://sourceforge.net/p/somfree/wiki/Home/) of it, though it would need an Object Pascal emitter.
This is just a syntax detail of how two aligned compilers specify things. Just like we have cdecl and C-like packing options.Extant syntax in C++ is a good thing because it means most of GCC can be reused. Java I think is a special case, because there is no native vanilla Java code to target. While only C is implemented the point of the feature is what is being discussed now.
The problem is not the syntax, but fully aligning those two compilers on the binary level. Which, as said is typically only done for compilers from the same organization. As you demonstrate that gcc is not compatible to general Java, but only its own Java.
And then with two compilers that were not designed to have common ground.
No. And RTTI is not 100% stable in time either, and is occasionally (but not often) expanded when new features are necessary.Is there no chance of a stable interface being agreed upon seeing as there might be a use for one? As long as things aren't removed the stability requirement could be met fairly easily.
Not a horrible idea. How does this compare in complexity to IDispatch?COM is the only somewhat mature option that already exists. And I don't see anything else happening anytime soon.Well, one could try to use the spiritual predecessor of COM: SOM (https://en.wikipedia.org/wiki/IBM_System_Object_Model). Originally developed by IBM for OS/2 there exists an open source implementation (https://sourceforge.net/p/somfree/wiki/Home/) of it, though it would need an Object Pascal emitter.
Extant syntax in C++ is a good thing because it means most of GCC can be reused.
Java I think is a special case, because there is no native vanilla Java code to target. While only C is implemented the point of the feature is what is being discussed now.
Is there no chance of a stable interface being agreed upon seeing as there might be a use for one? As long as things aren't removed the stability requirement could be met fairly easily.
What about using FPC code from C/C++ without shoving everything through a dynamic library?
The main usecase I can see is taking an existing C++ codebase and making it usable with FPC.Maybe SWIG can be helpful?
Even then we're only really caring about source compatibility here, not binary compatibility...QuoteIs there no chance of a stable interface being agreed upon seeing as there might be a use for one? As long as things aren't removed the stability requirement could be met fairly easily.
It is at it is. Backwards compatibility is important, also for Pascal codebases, but there are no guarantees.