Interfacing with C libraries may become a bit easier, with a C-to-Delphi header translator that is powered by libclang for Delphi.
Interfacing with C libraries may become a bit easier, with a C-to-Delphi header translator that is powered by libclang for Delphi.
https://blog.grijjy.com/2018/05/29/chet-a-c-header-translator-powered-by-clang/
https://blog.grijjy.com/2018/05/29/chet-a-c-header-translator-powered-by-clang/
Great stuff. I especially like the note about FFMPEG converting correctly.
ReplyDeleteDavid Millington I don’t know about “correctly”, but at least it compiles...
ReplyDeleteWhich is a big difference. Just being able to compile some header file and actually passing stuff properly is a different story (as we all learned many times from wrong translated winapi imports from Windows.pas and others)
ReplyDeleteWhat occured to me for example is that it translates >> as shr. That is incorrect when used on a signed type (not sure if it translates that different though).
#define X -6
#define Y X>>1 // that is -3
Delphi would make -6 shr 1 out of it which results in 2147483645
Ah - yes, as Stefan says, there can be a difference there :)
ReplyDeleteOne question I have: how does it convert pointer parameters? Does it pass pointers or as a var or out parameter?
I wonder how it should be cardinally better than for example FPC's h2pas ?
ReplyDeleteclang and similar tools rock for code-generation. CODE.
but for mere syntax parsing and declarations translations - won't it be an overkill?
Stefan Glienke That’s correct. But I argue that that is a Delphi bug and either shr should work with signed integers or Delphi should add a sar operator. But in the vast majority of cases, translating >> to shr works fine.
ReplyDeleteDavid Millington it leaves pointer parameters as pointers right now, because depending on the API, it may be legal to pass nil, and you cannot do that with var or out parameters. Maybe it can get smarter by looking at context, qualifiers or parameter names? Suggestions?
ReplyDeleteArioch The I don’t know if it is overkill to use Clang here. It certainly makes life easier. I have written header translators before and they got incredibly messy dealing with all nuances and language ambiguities. Clang takes care of that for you...
ReplyDeleteErik van Bilsen I see that has already been rejected shakeshead
ReplyDeletehttps://quality.embarcadero.com/browse/RSP-9944
Arioch The I feel the opposite. It doesn't make sense to me to recreate the language parsing logic and abstraction, when an Libclang exists and does a wonderful job of this. Also, in my experience the existing header conversion solutions rarely work.
ReplyDeletetime will show. Let blossom a thousand flowers
ReplyDeleteStefan Glienke Yes, very frustrating because the way it currently works isn't a "feature".
ReplyDeleteDoes it support bitfields?
ReplyDeleteEriks A. No (not yet). Those are hard to convert in a general useful way...
ReplyDeleteGreat work. Thanks for sharing it. I'll try it in a header file which I had to convert recently. It should give me a good idea. BTW, h2pas failed miserably in this specific case. My best companion was Rudy Velthuis' "Conversion Helper Package" which works very well (http://rvelthuis.de/programs/convertpack.html). However Rudy's tool, as the name implies, it's not an automatic converter.
ReplyDeletervelthuis.de - Rudy's Delphi Corner - Conversion Helper Pack
Alexandre Machado I didn’t know about Rudy’s helper, although I know he has a lot of great stuff! That’s an interesting approach to the problem, because he’s right that automated tools are never perfect. His tool takes more time and effort, but can result in cleaner code (because of the manual labor). Thanks for sharing this link!
ReplyDelete