Community input for a new C binding generator project
Jacob Carlborg
doob at me.com
Wed Apr 2 08:49:18 PDT 2014
On 2014-04-02 16:33, James Buren wrote:
> I have thought of designing a new C binding generator that tries to do
> more than dstep currently does.
What's the advantage of starting from scratch by building a new tool
instead of contributing to DStep?
> At the very least that would include
> automatic conversion of simple macros. Such as: characters, strings,
> aliases, integers, constant integer expressions, etc. Another thing I
> wish to add is mapping of standard C types to their D types in
> core.stdc.* if it is already defined there.
>
> However, while doing research for the project, I have come across a
> number of concerns I have. So, I am asking for community input before I
> get serious with this project because I want to actually make something
> people would want to use.
>
> Specifically, this is what I need to know about:
>
> 1) C has many standards (C89/C99/C11) and non-standard extensions (GNU
> C). By the very nature of C grammar, it can be quite difficult to parse
> properly. Would anyone care if I excluded non-standard features that may
> be present in a header? For example, non-standard bitfields -- they use
> integers other than 'int'. This is non-portable behavior.
Use a compiler that can already parse C, i.e. Clang.
> 2) As an extension to above, should I bother supporting rarely used
> features? Some of them are non-standard but others are standard. For
> example, #pragma pack() or GNU attributes and how those effect struct
> alignment in the D interface module is non-standard. Another example is
> converting inline functions, which is supported via C99 standard.
Use a compiler that can handle those extensions, i.e. Clang.
--
/Jacob Carlborg
More information about the Digitalmars-d
mailing list