built in import c header files

[FeepingCreature]

On Tuesday, 6 October 2020 at 20:59:54 UTC, 12345swordy wrote:
> I remember reading a reddit comment saying that if d were to 
> import c header files directly without any 3rd party libraries 
> it would be a game changer. The question is: how difficult to 
> implement a C AST parser for the dmd front end?
>
>
> -Alex

I've been doing this in both of my compiled languages. (fcc 
first, built-in, and now in cx as a macro.)

For an example of it in action, check out my glfw sample 
https://github.com/FeepingCreature/Cx/blob/master/demos/glfw.cx , 
or the macro code for it 
https://github.com/FeepingCreature/Cx/blob/master/src/cx/macros/cimport.cx .

Three things that jump out:

1. preprocessed headers with `gcc -dD -E` are a lot easier to 
work with, because gcc helpfully unrolls *most* of #define 
definitions, but leaves enough standing so that you can generate 
enums for all the #defines. This is why it's a useful thing to 
have unrestricted IO support, including arbitrary command 
execution, in CTFE. :)

2. "Header C" is actually pretty easy to parse if you just 
studiously ignore all the weird things, weird inside-out type 
format aside.

3. 10% of effort to parse C gets you 99% of value: because the 
vast majority of typing work involved in making a C header 
binding is trivially simple to parse from the header, and the 
rest you can always just do by hand, or (if your language has 
macros) expand as you need it. I presume glibc headers are more 
complicated, but I have been massively positively surprised how 
much of GLFW and GL I could get running with a day or two of 
coding work on this. To a first approximation, once I added 
function pointers, it pretty much all just worked.

I can wholeheartedly recommend any language do this. It unlocks a 
lot of value and removes a lot of manual work.