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

111–120 of 139 posts

Re: C Macro Reflection in Zig

#111

Post by whitehexagon »

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

Do we know if this means the Reflection as mentioned in the article via @typeInfo will no longer work? or was it anyway comptime info? My Zig so far has been SoC level stuff, but using something like raylib or glfw is somewhere on my todo list, and this example sounds mighty useful. Anyway seems a strange thing to remove when Zig has the potential to be the new C. Hopefully also as stable for the next 30 years :)

Re: C Macro Reflection in Zig

#112

Post by pbaam »

whitehexagon wrote: post #111
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

Do we know if this means the Reflection as mentioned in the article via @typeInfo will no longer work? or was it anyway comptime info? My Zig so far has been SoC level stuff, but using something like raylib or glfw is somewhere on my todo list, and this example sounds mighty useful. Anyway seems a strange thing to remove when Zig has the potential to be the new C. Hopefully also as stable for the next 30 years :)

It will still work. If you look at the type signature of @cImport in the language reference[1], it returns a type just as @import. So you can call @typeInfo on it. But instead of writing

  const win32 = @cImport({
    @cInclude("windows.h");
    @cInclude("winuser.h");
  });
You will write:

  const win32 = @import("win32");
Where the module "win32" is declared in build.zig.

[1] https://ziglang.org/documentation/master/#cImport

Re: C Macro Reflection in Zig

#113

Post by dgb23 »

voidUpdate wrote: post #49
dgb23 wrote: post #43

Earlier quoted context omitted.

> 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 recently started a new project. zig-init provides you with a working build.zig file and two very minimal project files under /src, one of which is a hello world binary and the other is a hello world library. > Also I've had a lot of issues getting editor…

Really? I get a main.zig file with a hello world as well as some maths, and a build.zig that has stuff that I can't work out how to correctly get rid of. I'm not currently at that workstation so I can't give specifics though. I feel it would be easier if it was literally just a hello world print and the build literally just built it, rather than doing tests on code I already know works, because it shipped with the la…

Yes, that's what I meant. But I think I talked passed you in a way.

I think its fair criticism that as a beginner, you don't actually want to deal with build.zig or even understand it. You just want to write some code and run it and look at build.zig after you gained some familiarity with the language itself.

Re: C Macro Reflection in Zig

#115

Post by samatman »

jay-barronville wrote: post #92
samatman wrote: post #81

Earlier quoted context omitted.

It will require a little more work in a trivial way, but not in a meaningful way. What's happening is that C imports are moving to the build system, instead of being a compiler builtin. It's part of making LLVM and libclang optional for programs which don't use it, but the use case of building C programs, and integrating C libraries with Zig programs, remains a central design goal. The build system is relatively new,…

> It just means that importing C libraries will be a build step, and not something you write directly into the relevant source code. This is not a big deal. It 100% is a big deal. I explained this in another comment [0]. [0]: https://news.ycombinator.com/item?id=41111445

We have different ideas of what a big deal is, clearly.

The idea that C programmers, C programmers, are going to start bailing en masse out of the top of the Zig funnel, because they have to copy-paste a build.zig gist to get started? This is risible.

The complexity has moved to a slightly different place. That's it.

Re: C Macro Reflection in Zig

#116

Post by mk12 »

kbolino wrote: post #78
throwawaymaths wrote: post #51

Earlier quoted context omitted.

What's the problem? @cImport is becoming just @import.

@cImport works without build.zig and even with build.zig requires no special configuration (ignoring linking). As it is currently described, @import of C will require build.zig and specific configuration therein.

It won't require build.zig, you'll just have to run zig translate-c on the C file. Andrew's comment here[1] says that @cImport is basically @import + the compiler implicitly running translate-c for you. There was some discussion of removing the translate-c subcommand as well (which would force you to use build.zig), but I don't think it's been decided to do that.

[1] https://github.com/ziglang/zig/issues/20630#issuecomment-225...

Re: C Macro Reflection in Zig

#117

Post by jay-barronville »

samatman wrote: post #115
jay-barronville wrote: post #92

Earlier quoted context omitted.

> It just means that importing C libraries will be a build step, and not something you write directly into the relevant source code. This is not a big deal. It 100% is a big deal. I explained this in another comment [0]. [0]: https://news.ycombinator.com/item?id=41111445

We have different ideas of what a big deal is, clearly. The idea that C programmers, C programmers , are going to start bailing en masse out of the top of the Zig funnel, because they have to copy-paste a build.zig gist to get started? This is risible. The complexity has moved to a slightly different place. That's it.

> The idea that C programmers, C programmers, are going to start bailing en masse out of the top of the Zig funnel, because they have to copy-paste a build.zig gist to get started? This is risible.

What I find incredible about these takes is that they’re so removed from reality. It’s quite unfortunate how difficult it is to get a lot of programmers to evaluate things from the shoes of others.

I have firsthand experience trying to get fellow C programmers to try Zig (and Rust too), and it’s already extremely difficult as is. The three things that have helped me sell Zig has been the combination of (1) how easy it is to get up and running with it (no prerequisites or installs necessary) [0], (2) the C interop story (which was a selling point for me [1]), and (3) the very simple yet impressive and complete build process [0].

What’s interesting is that you call my point risible when, based on your response, it’s clear to me you don’t understand the audience we’re talking about.

For example, you say:

> […] because they have to copy-paste a build.zig gist to get started […]

Professional C programmers generally favor actually understanding what’s happening under the hood, so unlike, e.g., JavaScript or Python developers, suggesting they get started by copying and pasting build code they don’t understand is a nonstarter for a lot of C programmers. And understanding Zig’s build system doesn’t happen as quickly [1] as being able to use Zig directly. Even after writing a decent amount of Zig build code, I’ve had to, on a number of occasions, go read the Zig build system code to understand how something is implemented (e.g., how it deals with certain paths, peculiarities of the dependency system, caching semantics, etc.)—if I had to figure out the build system before I was able to get started with Zig and be productive, I would’ve never taken it seriously.

There’s a reason why Zig has been marketed as a compiler that can also serve as a drop-in replacement for GCC/Clang. What you’re effectively saying is that this main selling point doesn’t matter even though that’s been one of the main things that makes Zig attractive to C programmers. Incredible.

[0]: https://news.ycombinator.com/item?id=41111445

[1]: https://news.ycombinator.com/item?id=41107515

Re: C Macro Reflection in Zig

#118

Post by kitkat_new »

Joker_vD wrote: post #64
bluGill wrote: post #46

Earlier quoted context omitted.

> With hindsight, it is strange that the C community, with all the people and money behind it (and what scale!) never even managed to build a proper packaging manager (okay, there's now Conan, but that came from Python guys). Package managers are a lot more complex than people realize. Every attempt I've seen in every language has significant lacks for common real world cases. Most commonly they assume all the world…

Why would anyone want to integrate with the OS package manager? Windows, as you've said yourself, doesn't even have one (and thank goodness for that) while on Linux, the distributed packages are normally about 2 to 4 years out of date — unless you discover and use specific 3rd-party repositories at which point what's even the point then? Just use the language's CPAN/PyPI/Hex/Crates.io/etc. analogue.

Windows has winget

Re: C Macro Reflection in Zig

#119

Post by winrid »

markus_zhang wrote: post #42
jeroenhd wrote: post #37

Earlier quoted context omitted.

This is part of the reason why I don't use VSCode for C(++). Jetbrains Clion seems to be the best IDE for those languages, with Visual Studio (the full fat one, costing a grand, as the free version lacks a bunch of features) as a close second, depending on what platform you're developing for. VSCode is great when it works, but in cases like these it quickly becomes obvious that it's a hodge-podge of tools glued toget…

I have never used Clion. Can you please share why you believe it is the top of the crop? I'm writing a C++/SDL2 game engine in Visual Studio but I think the IDE is really slow and error prone even for a small project. Everything just runs so slow. Maybe I need a better machine though.

CLion has a free trial you can try. I find it works really well. I use it on a 6yo laptop quite often for C++.
Post reply on HN