C++ Binding Generator

[Moritz Maxeiner]

On Tuesday, 18 February 2014 at 11:52:24 UTC, Abdulhaq wrote:
>
> At the moment smidgen (morsel is the example C++ library I use 
> for testing) only wraps C++ classes, on the TODO is of course 
> to wrap C++ top level functions etc. It makes a lot of sense to 
> add support for C functions too, but to be totally honest I 
> have no personal need for that ATM so it would come after 
> everything else. I would class smidgen as at beta stage at the 
> moment in terms of the functionality it currently supports. It 
> needs to be (ab)used by some other developers testing it out on 
> some small APIs, and then once I feel it has settled down 
> others could contribute code to support C APIs.
>
> Regarding memory leaks, you're right, to wrap a C++ library 
> there has to be manual effort on the part of the developer to 
> tell the wrapper where object ownership is transferred etc. 
> This cannot be automated. Smidgen is based on the sip format 
> and it's pretty easy to annotate the API to indicate where 
> ownership is transferred.
>
>> 2) What is the main difference between using morsel and SWIG, 
>> other than the language used to specify the interface?
>
> I don't know much about SWIG but the biggest difference would 
> have to be SWIG's great maturity and extensive feature set. 
> Smidgen has its own plusses too though:
>
> * It's pure D and the code is tested and maintainable - i.e. if 
> it doesn't work for someone they could probably extend/change 
> it so that it did
>
> * It's a very thin wrapper around the client library, so I 
> suspect it's a bit faster at runtime than the more generic SWIG
>
> * Did I mention it's in D :-)


Thanks for the comprehensive write-up, I'll have a look at
smidgen the next time I'm fiddling with llvm-d, then. It seems
promising, but I'm not yet entirely convinced that it'd fit well
with LLVM: About 70% of their C++ API not in the backend is
essentially helpers classes to deal with things either already
present or not needed in languages like D. The problem is that
the methods you actually want to access very often require
arguments with the type being one of these helper classes. And
there's no benefit of having these classes in D other than to use
instances of them as arguments to the rest of the LLVM API, since
their functionality is already present in D or not needed.
Anyway, I'll try it out when I have time and see if it beats
writing the wrapper manually.