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