C++ interop

[Fiji]

How can i share strings, arrays, simple types(int, float, etc.), structs, classes with a GCC dll? There is a feature in trunk where it allows for FPC to use classes exposed by GCC. Does this work for other compilers aswell or only GCC?

[Leledumbo]

I believe it's GCC only. Other than simple types (and records with correct alignment), everything else is implementation dependant. However, opaque pointers will always work.

[Basile B.]

For records I think interop is granted if they are POD (no functions, old_school pascal records), but their members must be themselves simple types (excluding strings).

[hinst]

to pass char*, pass @yourString[1]
to pass array, say, int*, pass @yourArray[1]
to receive char*, pass char*, receive PChar, then loop through it to find 0-char which indicates end of string, then copy it to Pascal string
to receive int[], pass int[], pass its length, receive a: PInteger and length: Integer, then copy memory to array of Integer
it's that simple
pascal strings and dynamic arrays are released as soon as they are not in scope. If you need to store pascal string in C++ part of program, then make a copy of it; same goes to dynamic arrays

you can share record <-> struct as well if they are identical and packed. In FPC use packed keyword, in GCC use

Code: [Select]

struct __attribute__ ((__packed__)) my_packed_struct
            {
               char c;
               ...
yesss.... https://gcc.gnu.org/onlinedocs/gcc/Type-Attributes.html
it's that easy. I spent some time learning this stuff so it just comes naturally to me

read some article
here's some article: http://rvelthuis.de/articles/articles-convert.html not sure if it will be helpful

[marcov]

to pass char*, pass @yourString[1]
to pass array, say, int*, pass @yourArray[1]

All after checking for NIL and length 0 of course.

to receive char*, pass char*, receive PChar, then loop through it to find 0-char which indicates end of string, then copy it to Pascal string

(there are routines to help with this, strlen, strpas in sysutils. Don't use the strings unit ones, they return shortstrings and cause 255 char limits)

[Fiji]

So is it possible to get the size of an array in C++? I could not find a way.. Also to pass strings you can pass an array of bytes/chars, BSTR is not a wise choice..

To unmangle names can I use this?

#pragma comment(linker, "/EXPORT:SomeFunction=_SomeFunction@@@23mangledstuff#@@@@")

[marcov]

So is it possible to get the size of an array in C++? I could not find a way..

There is no general way. Mangling is C++ compiler and version dependent.

That's why I asked if with C# interop you can access C++ from older VS versions in the "FPC vs C#" thread.

But worse, for complex types you must know the internal buildup too. It is assumed that simple types can be made to match easily to Pascal equivlaents, but not for complex types, STL and most
importantly stringtypes other than basic pointer to char.

[skalogryz]

But worse, for complex types you must know the internal buildup too. It is assumed that simple types can be made to match easily to Pascal equivlaents, but not for complex types, STL and most

This is a bit off-topic, but since involved participants (the ones advocating for pascal syntax extension) are here.

That's one of the reasons NOT to extend FPC with all sort of "sugar-syntax" and "modern" structures.

The portability of the code drops. Not just to other languages, but across different versions of the compiler (FPC vXXX <-> FPC vYYY, FPC <-> Delphi). As the result you might stuck with the code and the compiler for a project.

[Fiji]

So is it possible to get the size of an array in C++? I could not find a way..

There is no general way. Mangling is C++ compiler and version dependent.

That's why I asked if with C# interop you can access C++ from older VS versions in the "FPC vs C#" thread.

But worse, for complex types you must know the internal buildup too. It is assumed that simple types can be made to match easily to Pascal equivlaents, but not for complex types, STL and most
importantly stringtypes other than basic pointer to char.

Yes there is PInvoke, CLI/C++. But to answer your question. Yes! It is currently available in Visual Studio 2005, 2008, 2010, 2012 and 2013, including the Express editions.

CLI can access classes, PInvoke can only access functions, structs etc.

[taazz]

But worse, for complex types you must know the internal buildup too. It is assumed that simple types can be made to match easily to Pascal equivlaents, but not for complex types, STL and most

This is a bit off-topic, but since involved participants (the ones advocating for pascal syntax extension) are here.

That's one of the reasons NOT to extend FPC with all sort of "sugar-syntax" and "modern" structures.

The portability of the code drops. Not just to other languages, but across different versions of the compiler (FPC vXXX <-> FPC vYYY, FPC <-> Delphi). As the result you might stuck with the code and the compiler for a project.

That is half true the other half is that the compiler designers do not want to be tight down by existing rules claiming that it is easier to extend the compiler and for that they sacrifice portability. That is probably ok for an open source project but that does not make it an impossible goal just one not wanted.

[marcov]

The portability of the code drops. Not just to other languages, but across different versions of the compiler (FPC vXXX <-> FPC vYYY, FPC <-> Delphi). As the result you might stuck with the code and the compiler for a project.

The case where fpc version is older than the version it is written for is IMHO not a problem.  But I believe that compiler extensions must have a certain value, and shorthands like case of string are IMHO not worth it.

[Fiji]

The portability of the code drops. Not just to other languages, but across different versions of the compiler (FPC vXXX <-> FPC vYYY, FPC <-> Delphi). As the result you might stuck with the code and the compiler for a project.

The case where fpc version is older than the version it is written for is IMHO not a problem.  But I believe that compiler extensions must have a certain value, and shorthands like case of string are IMHO not worth it.

Yes. Anonymous methods in Delphi are basically interfaces.

[marcov]

Yes there is PInvoke, CLI/C++. But to answer your question. Yes! It is currently available in Visual Studio 2005, 2008, 2010, 2012 and 2013, including the Express editions.

I'm not interested in CLI/C++, since for me the reasons to interface C++ is mostly in vendor delivered libs, and they are all for native, not CLI.

I don't want to know if pinvoke is in every version, but if it works ACROSS versions. So I want to know if you can access a C++ class using PInvoke from a different VS than the one you are working in C#, since that would mean that VS supports mangling of all versions.  So if C# VS2013 can access a function if the vendor only has the C++ DLL  for VS2008.

A suite tools nearly always works together (just like in Delphi you can use C++Builder, but not VS). But that is something else.

And if classes don't even work (let alone templates, and other STL stuff), then IMHO it is hardly any better than we have now, since most C++ interfaces will still need to be modified to be usable.
 

[Leledumbo]

Yes there is PInvoke, CLI/C++. But to answer your question. Yes! It is currently available in Visual Studio 2005, 2008, 2010, 2012 and 2013, including the Express editions.

I'm not interested in CLI/C++, since for me the reasons to interface C++ is mostly in vendor delivered libs, and they are all for native, not CLI.

I don't want to know if pinvoke is in every version, but if it works ACROSS versions. So I want to know if you can access a C++ class using PInvoke from a different VS than the one you are working in C#, since that would mean that VS supports mangling of all versions.  So if C# VS2013 can access a function if the vendor only has the C++ DLL  for VS2008.

A suite tools nearly always works together (just like in Delphi you can use C++Builder, but not VS). But that is something else.

And if classes don't even work (let alone templates, and other STL stuff), then IMHO it is hardly any better than we have now, since most C++ interfaces will still need to be modified to be usable.
 

From my experience, no. Even worse, we need to use dependency walker to get the mangled name and bind that instead, until I finally port it to C instead.