Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C Macro Reflection in Zig

jstrieb.github.io

Post reply on HN
Print view View original

11–20 of 139 posts

Re: C Macro Reflection in Zig

#11

Post by flohofwoe »

voidUpdate wrote: post #6

I really want to like zig, but I've just had some annoying problems with it, most of which I think are just a result of it not being in 1.0 yet. For example, the recommended way to start a project, with `zig init`, has a load of code that I really don't need when I just want a bare project to get started. I only recently found out that you can just `zig build-exe filename.zig` and skip the whole init part. Also I've…

Tbf, when coming from the C/C++ ecosystem, these types of problems are 'just another Tuesday' (especially for cross-platform projects and the official VSCode C/C++ extension).

Re: C Macro Reflection in Zig

#12

Post by voidUpdate »

flohofwoe wrote: post #11
voidUpdate wrote: post #6

I really want to like zig, but I've just had some annoying problems with it, most of which I think are just a result of it not being in 1.0 yet. For example, the recommended way to start a project, with `zig init`, has a load of code that I really don't need when I just want a bare project to get started. I only recently found out that you can just `zig build-exe filename.zig` and skip the whole init part. Also I've…

Tbf, when coming from the C/C++ ecosystem, these types of problems are 'just another Tuesday' (especially for cross-platform projects and the official VSCode C/C++ extension).

Yeah, that's one of the reasons I dislike the C++ ecosystem so much and want to like Zig haha

Re: C Macro Reflection in Zig

#13

Post by Cloudef »

voidUpdate wrote: post #6

I really want to like zig, but I've just had some annoying problems with it, most of which I think are just a result of it not being in 1.0 yet. For example, the recommended way to start a project, with `zig init`, has a load of code that I really don't need when I just want a bare project to get started. I only recently found out that you can just `zig build-exe filename.zig` and skip the whole init part. Also I've…

zls should generally work out of the box but I don't use vscode, so your mileage may vary. Make sure your zls and zig versions match. zig build-exe, zig run can be fine for small things, but when you want to start importing modules or do something more fancy, build.zig is nice to have.

Re: C Macro Reflection in Zig

#14

Post by jay-barronville »

skywal_l wrote: post #2

@cImport is on the chopping block though [0]. You will still be able to import c files but it will require a little more work. This is because they want this functionality out of the language so they can remove libclang dependency. [0]: https://github.com/ziglang/zig/issues/20630

While I understand the reasoning, I think this is one of the most disappointing decisions by the Zig team.

One of the main reasons I took Zig seriously was their C interop story—as someone who loves C and dislikes almost every implementation of C interop and FFI I’ve used in other languages (Rust is a notable exception to this), I was pretty much sold on Zig when I was able to, in a total of I respect Andrew a lot (I think he’s pretty brilliant), so I hope this turns out to not be as bad as I think it’ll be for those of us who love Zig for what brings to the table for programmers who are biased toward C.

Re: C Macro Reflection in Zig

#15

Post by g15jv2dp »

JonChesterfield wrote: post #10
Joker_vD wrote: post #4

Clang's preprocessor is actually not implemented as a separate compilation pre-pass, it's essentially a part of the lexer and I would be willing to bet that gcc uses a similar scheme. So there is nothing technically impossible about having the access to macro names as a compiler-specific extension, it's just that there is no much demand for it.

Clang prints out things about macro instantiations on the semantic error reporting paths. That probably means it has all the macro information available already. It's not probably reflected to the language because C++ fears reflection in general and hates macros in particular.

> C++ fears reflection in general and hates macros in particular.

Macros aren't a particular case of reflection... And at least in the way they're done in C++, they're a big source of bugs / spaghetti.

Re: C Macro Reflection in Zig

#16

Post by flohofwoe »

Cloudef wrote: post #7
eska wrote: post #3

Wouldn’t this add at least UINT16_MAX*sizeof(intptr_t) bytes into the executable per enum?

It adds 65536 pointers to the binary. Alternative would be to use a hash map. I think if they made function that used inline for instead it would optimize to a switch. No need for a LUT. fn stringFromMsg(umsg: c_int) [:0]const u8 { @setEvalBranchQuota(1000000); inline for (@typeInfo(win32).Struct.decls) |field| { if (field.name.len >= 3 and std.mem.eql(u8, field.name[0..3], "WM_")) { if (umsg == @field(win32, field.n…

> ...instead it would optimize to a switch. No need for a LUT.

IME there's is no difference in (optimized) code generation between an if-else chain, a switch or (like in your example) an unrolled for-loop with an if inside. All those high level constructs will be optimized into a single lookup table, or a combination of multiple lookup tables and binary search to select between those. Only if there are absolutely no consecutive ranges in the switch-set, a binary search without jump tables will be used.

Re: C Macro Reflection in Zig

#17

Post by Cloudef »

flohofwoe wrote: post #16
Cloudef wrote: post #7

Earlier quoted context omitted.

It adds 65536 pointers to the binary. Alternative would be to use a hash map. I think if they made function that used inline for instead it would optimize to a switch. No need for a LUT. fn stringFromMsg(umsg: c_int) [:0]const u8 { @setEvalBranchQuota(1000000); inline for (@typeInfo(win32).Struct.decls) |field| { if (field.name.len >= 3 and std.mem.eql(u8, field.name[0..3], "WM_")) { if (umsg == @field(win32, field.n…

> ...instead it would optimize to a switch. No need for a LUT. IME there's is no difference in (optimized) code generation between an if-else chain, a switch or (like in your example) an unrolled for-loop with an if inside. All those high level constructs will be optimized into a single lookup table, or a combination of multiple lookup tables and binary search to select between those. Only if there are absolutely no…

Note that you can't use normal for here as you are accessing comptime known variables. Inline for will unroll the loop so that comptime constants get resolved for testing against runtime variables and then the optimizer picks out the best code (often jump tables / switch) to generate. You are right though.

Re: C Macro Reflection in Zig

#18

Post by voidUpdate »

Cloudef wrote: post #13
voidUpdate wrote: post #6

I really want to like zig, but I've just had some annoying problems with it, most of which I think are just a result of it not being in 1.0 yet. For example, the recommended way to start a project, with `zig init`, has a load of code that I really don't need when I just want a bare project to get started. I only recently found out that you can just `zig build-exe filename.zig` and skip the whole init part. Also I've…

zls should generally work out of the box but I don't use vscode, so your mileage may vary. Make sure your zls and zig versions match. zig build-exe, zig run can be fine for small things, but when you want to start importing modules or do something more fancy, build.zig is nice to have.

According to the extension, ZLS is optional, but according to some zig docs I found, its part of the extension. I may have misread, I'll try this stuff again sometime

Re: C Macro Reflection in Zig

#19

Post by jay-barronville »

voidUpdate wrote: post #6

I really want to like zig, but I've just had some annoying problems with it, most of which I think are just a result of it not being in 1.0 yet. For example, the recommended way to start a project, with `zig init`, has a load of code that I really don't need when I just want a bare project to get started. I only recently found out that you can just `zig build-exe filename.zig` and skip the whole init part. Also I've…

> […] I've had a lot of issues getting editor integration to work correctly. I've installed the VSCode extension but I don't seem to be getting autocomplete etc. […]

If you use ZLS [0], make sure you’re always using the right version for the Zig version you have installed on your machine. In my experience, that fixes 90% of editor issues I’ve encountered using Zig (I don’t use Visual Studio Code though, so it’s possible your editor issues are related to the editor itself).

[0]: https://github.com/zigtools/zls

Re: C Macro Reflection in Zig

#20

Post by flohofwoe »

jay-barronville wrote: post #14
skywal_l wrote: post #2

@cImport is on the chopping block though [0]. You will still be able to import c files but it will require a little more work. This is because they want this functionality out of the language so they can remove libclang dependency. [0]: https://github.com/ziglang/zig/issues/20630

While I understand the reasoning, I think this is one of the most disappointing decisions by the Zig team. One of the main reasons I took Zig seriously was their C interop story—as someone who loves C and dislikes almost every implementation of C interop and FFI I’ve used in other languages (Rust is a notable exception to this), I was pretty much sold on Zig when I was able to, in a total of I respect Andrew a lot (I…

The translate-c build system step and wrapping the output in a Zig module is currently about 10 lines in build.zig, and I guess this could be reduced further by merging those two steps into a single step.

I think that's an acceptable compromise.

Especially for C libraries which require configuration via preprocessor defines or compilation flags, the build.zig way is a lot cleaner than the @-builtins that are currently used (IMHO).

Post reply on HN