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
