More automated interfacing of D with C codebases

timotheecour thelastmammoth at gmail.com
Mon Oct 22 22:09:35 PDT 2012


>If you try to automate processing of the pre-processed headers,
> all of the included system headers will be processed and too 
> much that isn't needed will be output.

Swig has lots of customization to control what gets translated. 
For example, we recursively translate the contents of header 
files or just the contents minus without looking into the include 
statements (the default):

b.h:
void funb();
a.h:
#include b.h
void funa();

%{
%include "a.h"
%}
%include a.h

=> the default is NOT to inlude funb(), which is inside an 
include statement.

>> If SWIG has a full blown C++ parser, then why is it choking on 
>> some
code?
One example is when there's no D equivalent, eg multiple 
inheritance. But there are more:
actually in the example above, if I understand correctly, the 
stuff inside the %{ %} uses the full blown C++ parser, whereas 
the stuff after has some swig specificities and sometimes can't 
handle certain rare constructs if one uses the lazy approach that 
I've taken of translating the whole header file (%include a.h):

some stuff it choked on:
A) typedef Matx<_Tp, MIN(m, n), 1> diag_type;
B) void addParam(   int (Algorithm::*getter)()=0)


> Will this generate C code or can it be made to generate 
> something like this:
> http://michelf.ca/projects/d-objc/syntax/

I haven't tried, I'd be curious to know.





More information about the Digitalmars-d-learn mailing list