The recent thread about using C headers made me think about using C++ projects.

Found that the SWIG tool converts C/C++ .h files into glue code and bindings for e.g. Python, Modula 3... but not Delphi/Object Pascal.

It seems you get an object-oriented binding.

Did see this post from 2010 about Delphi support:
http://stackoverflow.com/questions/2559995/create-an-instance-of-an-exported-c-class-from-delphi

... in a quick browse, couldn't find that branch though. (Note: the poster's mail address is mentioned in that post)

Perhaps this could be useful for somebody interested in this/needing this kind of functionality.

Thanks,
Reinier

Found the code and a discussion on the swig mailing list:

The patches:
https://sourceforge.net/tracker/index.php?func=detail&aid=2010931&group_id=1645&atid=301645 The patch.zip includes some documentaton in html format; it e.g. indicates the code creates (what SWIG calls) proxy classes in Pascal for C++ classes.
Couldn't find the branch in the SWIG repository mentioned in the post above, but haven't looked lately.

Good news: the code in question is written to support FPC in Delphi mode: http://article.gmane.org/gmane.comp.programming.swig.devel/18311

It has been used to create a Delphi binding for GDAL: http://article.gmane.org/gmane.comp.programming.swig.devel/18297

Bad news: it hasn't been committed to SWIG trunk, and is fairly old (swig 1.3.35), but may well be revived (don't know).

Perhaps this could help somebody and... perhaps we might even see this in SWIG trunk some day.

Thanks,
Reinier

So it will be possible to convert for example libQT4Pas?

Krzysztof wrote

So it will be possible to convert for example libQT4Pas?

Haven't used libQT4Pas, but I understand it is the wrapper to let FPC talk to the C++ Qt libs.
So SWIG could automatically generate an alternative to libQT4Pas.

I wonder if it would be good enough to embed the ECLiPSe CLP solver in an application-specific Lazarus frontend? That combination could be seriously useful for timetabling etc.

http://eclipseclp.org/doc/embedding/embroot.html

Hi,

Perhaps this could help somebody...

I kept an eye on Swig for quite some time, but reading your posting I decided to give it a try.

A summary for everyone interested:
[latest swig (2.0.8) - adapted patch - not sure if I made everything correct (API changed since the patch was made)]

1. The generated C++-Wrapper looks quite good and is compilable; at some places it seems to be a bit overkill, e.g.:

<<--

SWIGEXPORT int Delphi_gcd(int pasarg0, int pasarg1) {
  int cresult = 0 ;
  int arg1 ;
  int arg2 ;
  int result;
  arg1 = (int)pasarg0;
  arg2 = (int)pasarg1;
  result = (int)gcd(arg1,arg2);
  cresult = result;
  return cresult;
}

-->>

Maybe I'm totally wrong, but in my eyes the following would be enough:

<<--
SWIGEXPORT int Delphi_gcd(int pasarg0, int pasarg1) {

  return (int)gcd((int)pasarg0,(int)pasarg1);

}
-->>

2. The Delphi / ObjectPascal part definitely needs some more work, the function import is ok, but the object wrapper doesn't work properly and swig generates unusable code [it could be, that I messed up something, when adapting to new swig].

But if you would edit the pascal unit anyway - I certainly would - it is quite usable in its current (early?) state...

I tested just out of interest and have no plans to do further work - but I assume - if somebody really needs it - you could make it fully work with little effort...

Hopefully this report helps somebody...
Btw. if somebody wants the adapted code, I will upload it..

Regards,
d.l.i.w

<snip>

Hi d.l.i.w.,

Thanks for the adaptations and report.

I'd think it would be good idea if you could upload it so your work won't get lost!

Thanks,
Reinier

Hi,
here it is:
http://downloadit.pf-control.de/dl.php?ref=swig

Unfortunately I made the mistake and did the work on a non version controlled folder - therefore it is whole swig and not just a patch :(

Feel free to move the file to any other - possibly more "central" - place and hopefully there will be a working version in swig trunk someday.

Regards,
d.l.i.w

Downloaded swig 2.0.8 (not winswig) from sourceforge, and ran diff --unified --recursive --new-file swig-2.0.8 swig-2.0.8-delphi on it (hope I used the right command).

Result:
http://members.upc.nl/s.grewar/swig_2.0.8_to_swig_delphi.diff

Unfortunately looks like there's a lot of autogenerated stuff that pollutes the patch :(

Hi,

http://members.upc.nl/s.grewar/swig_2.0.8_to_swig_delphi.diff

Hm, this really doesnt look good.. :(

I did run "make maintainer-clean" before packing - and hoped this would remove all this autogenerated stuff - apparently this wasn't the case [although the size of the whole thing went down from ~16MB to ~4MB].

Maybe there is a even stricter "make ...-clean", does anybody know?

If I find time, I will do this again on trunk and make a proper patch, but I cannot promise and it certainly won't be very soon; if so, I will report it here, anyway.

Regards,
d.l.i.w

FYI, created wiki page
http://wiki.lazarus.freepascal.org/SWIG
to bundle information.

Thanks,
Reinier

Thanks for that. I was looking at an interesting article yesterday on developing for the Pebble smartwatch, and wondering whether the people who write the APIs for that sort of device will without thinking use techniques that FPC would have difficulty accommodating.

http://www.theregister.co.uk/2013/07/18/how_to_write_apps_for_the_pebble_smartwatch/

Reinier Olislagers wrote

FYI, created wiki page http://wiki.lazarus.freepascal.org/SWIG to bundle information.

Uploaded binaries for Linux x86 and Linux x64 on the bitbucket repository mentioned in the wiki article.

Unfortunately I managed to generate a syntax error [1] while trying to import the tesseract OCR .h - repeated with stable SWIG version... so perhaps this time it's not a problem behind the keyboard but in the SWIG code...

By the way, if people happen to have a Windows version of the SWIG Delhi branch, I'd be happy to upload it to bitbucket.

Thanks.

[1] http://permalink.gmane.org/gmane.comp.programming.swig/19765

Hi,

The wiki page is a good idea, things have to be clarified though.

I don't know in how far others dealt with the code in the meantime - so this is my personal view:

When I ported the patch to 2.0.8 things looked quite good, the changes needed were very straightforward - and in the end the result was quite usable.

But IMO the code itself is / was a big mess and far from being clean & readable - which is no bigger problem if 'it simply works' :D

Now - I tried a port to latest swig (2.0.10) some months ago [even made a fork on github...], but never released, the reason: it doesn't work any more. I didn't search for the relevant changes in their changelog, but I didn't managed to get it even compiled - too many functions simply were missing.

Even worse, the Fortran module (upon which the Delphi module is based) although being in trunk also didn't compile - exactly the same missing functions.

In short: IMHO the patch is too much bitrotten to be further used, I think a clean and new implementation from scratch would be the much better way.

Maybe this can do the trick, too:
https://github.com/swig/swig/wiki/GSoC-2013-ideas#wiki-Support_for_C_as_target_language I mean, h2pas does a decent job...

And if it's allowed to dream: one time fpc will simply link against C++ directly :)

Regards,
d.l.i.w

Am 01.08.2013 11:10, schrieb

And if it's allowed to dream: one time fpc will simply link against C++ directly :)

If you prefer to work in Pascal instead of C++ then you could work on that dream by improving the cppclass code in the compiler. Linking against static C++ class methods already works, what's (basically) missing is support for C++ runtimes (at first the stdc++ one would be sufficient), support for vtables and object instantiation/destruction.

Regards,
Sven

Not even C++ compilers can use each other's DLLs, if I understood correctly.

I just received a (clean) patch from Sven Barth, which expands on your patch. It's on 2.0.8, and indeed does not work with swig trunk.

I was planning to try and get this into swig, but after your remarks, I am no longer so sure that this is a good idea :)

Michael.

How do you handle different binary formats of C++ compilers ? Or is this meanwhile standardized ?

Michael.

Support for every C++ compiler (mainly MSVC, C++ builder and GCC [LLVM counts here as GCC]) needs to be implemented explicitely, because they not only differ in class layout, but also in e.g. name mangling. So in the end (if we want to support more than GCC and LLVM) we'll need to use a directive to declare which compiler to target and this then includes a corresponding interface unit for the runtime (like is done with Objective C) and let the compiler generate the code correctly. Maybe together with packages support it should be possible to interface with multiple different a first step I'd only target GCC and LLVM as these are the main compilers for the majority of our platforms.

Regards,
Sven

Eh, MSVC also seems popular on windows ? ;)

Michael.

That's basically what I said :)

We have three windows platforms with MSVC and I don't know how many platforms where GCC or LLVM is the main compiler. I'm not going for popularity here, just for the majority of platforms.

Regards,
Sven

<snip>

Looking at the options
1 use swig architecture to parse the C++ source code/headers and extract Pascal bindings - either by a rewrite or adapting the current effort 2 accommodate (and maintain) various compiler idiosyncracies

from a distance... I'd say option 1 would be the easiest and best maintainable?
- SWIG already provides infrastructure to parse the source files
- People using Delphi would probably also be interested in fixing/patching bugs
- On top of the previous point: changes in C/C++ standards/formats would not be our concern so much because those will be dealt with by the wider SWIG community
- Of course, if swig is ever extended to support more languages, we get that for free

Of course I understand it's very attractive to have everything in house and native in FPC, but I suspect the effort needed to develop/maintain it may outweigh that...

@dliw: wasn't the Object Pascal module based on the Modula 3 module? IIRC recent posts on the swig mailing lists did indeed indicate the Modula 3 module was buggy in current SWIG.

Important point for variant 2: less overhead. Using swig you first flatten the API and then unflatten it again into Object Pascal classes. For callbacks you have also wrappers (which are hidden from you). In case of cppclass you don't have all this, because code will be called directly.

Regards,
Sven

@dliw: wasn't the Object Pascal module based on the Modula 3 module? IIRC recent posts on the swig mailing lists did indeed indicate the Modula 3 module was buggy in current SWIG.

Sorry, you're right - it was based on Modula - I did mix it up. Thanks for this correction.

Important point for variant 2: less overhead.

Right, that's the biggest plus in my eyes.

Or is this meanwhile standardized ?

Unfortunately not. It starts in different name mangling - as already said here
- and other (small) differences.
So working on a cross-platform project in C++ with different compilers involved - is still quite an adventure :D

then you could work on that by improving the cppclass code in the compiler

Hm, I will at least take a look.

d.l.i.w

And: it's written in Pascal.

The problem with tools such as swig is, that, unless it works 'out of the box' for the particular DLL you're interested in, basically, you are stuck.

Like as in:
Leap.i:259: Error: Syntax error in input(1).

The line in question being:
SWIG_CSBODY_PROXY(public, public, SWIGTYPE)

To make matters worse, the actual error depends on the target output language. Aha....

Hm....

With swig, I must now learn C, C++, the swig .i and .swg file formats. And then I must still get started on the swig java/csharp/delphi/whatever backend.

And that is if I am lucky that the providers of the DLL provided me with a input file for swig. If not, I still must construct that...

Now if it is written in Pascal, I pull up my sleeves, open whatever it is in Lazarus and start debugging/coding. Not so in tools like swig.

Michael.

Thanks for the info, Sven.

However, I'm reminded of the flurry of activity when SCADA malware was found in the wild a couple of years ago: it was decided fairly early that it had probably been compiled with MS tools, but inspection of the calling convention suggested that it was non-standard and it took a lot of head scratching before people decided which compiler/linker and what pragmata had been used.