built in import c header files (page 2)

There's another huge problem with C files. It's the predefined macros. Every compiler generates a different set of them, and in each compiler the set varies by compiler version, target, switch settings, etc. Most are undocumented. I think gcc has somewhere near a thousand of them. Naturally, every non-trivial C program winds up totally dependent on them.

On 10/6/2020 7:56 PM, Max Haughton wrote: > Not impossible (it's worth saying that you can literally do this as a library via mixins), but having a c parser in the compiler seems like too much work when it's already fairly trivial to do. If D had a team of full time staff on payroll, then it could be made to work but it adds so much surface area to the compiler. You'll also have problems with all the nutburger C extensions implemented by various compilers.

On Saturday, 17 April 2021 at 21:32:24 UTC, Walter Bright wrote: > On 10/6/2020 7:56 PM, Max Haughton wrote: >> Not impossible (it's worth saying that you can literally do this as a library via mixins), but having a c parser in the compiler seems like too much work when it's already fairly trivial to do. If D had a team of full time staff on payroll, then it could be made to work but it adds so much surface area to the compiler. > > You'll also have problems with all the nutburger C extensions implemented by various compilers. There is no need for the dmd frontend to implement that. The ldc2 and the gdc compilers can relay on their c++ counterparts to provided the c extensions. -Alex

On Saturday, 17 April 2021 at 23:22:47 UTC, Max Haughton wrote:

On Saturday, 17 April 2021 at 22:12:41 UTC, 12345swordy wrote:

On Saturday, 17 April 2021 at 21:32:24 UTC, Walter Bright wrote:

On 10/6/2020 7:56 PM, Max Haughton wrote:

Not impossible (it's worth saying that you can literally do this as a library via mixins), but having a c parser in the compiler seems like too much work when it's already fairly trivial to do. If D had a team of full time staff on payroll, then it could be made to work but it adds so much surface area to the compiler.

You'll also have problems with all the nutburger C extensions implemented by various compilers.

There is no need for the dmd frontend to implement that. The ldc2 and the gdc compilers can relay on their c++ counterparts to provided the c extensions.

-Alex

No they can't or at least GCC maybe could but LDC is a separate project entirely from clang.
Actually they can. It is a question of money/time/resources not programming ability here.
Regardless the dmd front-end just need to strictly implement the c99 standard(no language extension by the compiler of any sorts) to get the ball rolling.

-Alex

April 19, 2021

Re: built in import c header files

Posted by FeepingCreature
in reply to 12345swordy

Permalink

FeepingCreature

Posted in reply to 12345swordy

Permalink

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:

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. :)
"Header C" is actually pretty easy to parse if you just studiously ignore all the weird things, weird inside-out type format aside.
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.

On Saturday, 17 April 2021 at 08:36:41 UTC, Alexis Kyaw wrote: > 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 > > This would indeed be a total game changer. Why would one implement a C parser (never mind a C++ one) when libclang exists?

Forums