7 ms·

The author translates 1 line of C mess to 7 lines of Zig mess which are then manually simplified through transforms. Why not just apply transforms to the origin

The author translates 1 line of C mess to 7 lines of Zig mess which are then manually simplified through transforms. Why not just apply transforms to the original C code? Or is this only for people who know Zig syntax but not C?

mannykannot 5y ago
As someone unaware of Zig and its translate-C feature, I read the article as being about those things, not C.
rightbyte 5y ago
Or like use the cdecl cli tool ...
dosshell 5y ago
Or like use https://cppinsights.io/ https://cppinsights.io/ ...
- michaelmior 5y ago
  That gives the following output which I don't think is much more readable. void f(int * a) { void * p = reinterpret_cast<void *>(&a); ***reinterpret_cast<int *(*)[]>(p) = 1; }
  - cies 5y ago
    Maybe after several steps of manual processing it is :) (not sure what steps that should be)
    - michaelmior 5y ago
      Sure but I don't think C++ Insights really helped.
kristoff_it 5y ago
> Or is this only for people who know Zig syntax but not C? It's a blog post hosted on zig.news (so intended for an audience that knows Zig), I think we can safely assume that it's not meant to be an universal guide for understanding C code, but rather the recount of a (somewhat minor) experience lived by the author. It's even stated upfront: > @rep_stosq_void on Twitter posted this strange sample of C code, and I wanted to show my process of understanding this contrived C code. "I was presented with this code, and this is what I did to understand it"
abaracadabi 5y ago
I feel like the whole zig language is a mess. Not a mess architecturally but syntactically. Also the whole “no macros, no preprocessor” boasting is kind of annoying. Macros are often a powerful way to extend a language, and a preprocessing phase is nice way to add some logic before compilation. Sure a C preprocessor is limited but it works well for simple stuff. I’m just sick of these head-strong nerds inventing things and being like: our thing is better than your thing. Nanner-nanner-noo! I don’t understand this desire to create a new language that looks like a mix of JavaScript and Rust. If anything, a cleaner syntax like Python makes more sense—give it some airiness. And I say that as a mostly C++ programmer who has used Python occasionally and appreciates how easy it is on my eyes. Also, my recommendation for folks who want to invent a new language: simplicity first. Don’t reinvent Rust or C++ because I’d rather spend time in either of those before investing lots of mental effort in a third option. For instance, I even consider C better than Zig just because the features are small and knowable. Python is better because the syntax is simple despite many language features. Go is a quaint little beast. Simple simple simple. Don’t squeeze stuff in there to fit every niche.
- hansvm 5y ago
  Maybe it's still not the language for you or for your projects, but for anyone else stumbling across this I don't think it's a fair characterization. Would you mind elaborating on where you think I'm off-base in the following? > head-strong nerds inventing things Let people have their fun. > preprocessor allows you to add some logic before compilation Zig's comptime feature does address that need. For most use cases where comptime and the preprocessor would both suffice, comptime has tons of strong advantages (type checked, errors traced back to the right lines, ability to write arbitrary turing-complete code without unholy syntactic black magic, no double evaluation, no need to wrap everything in extra parentheses, ....). It explicitly does not address use cases where you would actually want a textual preprocessor (like making the language look like Fortran), the argument being that the burden on reading unfamiliar code would be too high. The ease with which you can write arbitrary comptime code also enables you to do things like embed lookup tables in the binary, which in C you would ordinarily do by copy pasting from another tool (or writing constants by hand) or adding yet another preprocessor to the mix. Comptime isn't a clear win over preprocessing in all cases, but having written a lot of C and a little Zig, if I had to choose one for a hypothetical new project I'd be tempted to use Zig just for access to that one feature. > Syntax Zig does feel a little clunky to write to me right now, but I think that's mainly do to how often I'm using @someBuiltin() in Zig when I would be using an operator or an additional language feature in something like Python. That said, the syntax itself is incredibly simple. You can check that yourself for Zig [0], Python [1], and Go [2]. Zig has far fewer syntactic quirks and abilities than either of the other two. You have functions, operators, code blocks, types, reserved characters/keywords for builtin stuff, a few kinds of literals, and a little bit of syntactic sugar for working with structs. > Don't reinvent C++...for instance, I even consider C better than Zig just because the features are small and knowable To each their own. FWIW, Zig is explicitly and actively avoiding becoming a kitchen sink language like Rust or C++. They've added a few new features, and I personally find it easier to keep track of those than of all the different kinds of undefined behavior I might stumble across in C, especially since most of those (defer, errdefer, labeled break, ...) behave exactly as your intuition suggests they would. [0] https://ziglang.org/documentation/master/#Grammar https://ziglang.org/documentation/master/#Grammar [1] https://docs.python.org/3/reference/grammar.html https://docs.python.org/3/reference/grammar.html [2] https://golang.org/ref/spec https://golang.org/ref/spec
sobeston 5y ago
Author here, I'm just showing how I did it. It took a few minutes to do it for myself - figured it would be worth the 15 minutes or so it'd take to write it down. Just sharing my process, there's nothing too serious about this post. I've happened to have written a lot of C, but some areas (like this one) I'm not as confident in. This way of casting, and working with types is very poor syntax in my opinion (I mean below in this thread you have people arguing about the spiral rule and such, it's obviously a common confusion). Zig's way of expressing types and pointers is far superior, these transformations I made were done quickly and I didn't feel like there was any ambiguity or confusion in anything. Just a series of simple reductions, there are no "tricks" or easy mistakes to make in the code. It feels like a trivial proof. Obviously I am biased, this was posted to zig.news. I thought it was a neat showcase of translate-c, and how zig does some of these things nicer. I'm not telling everyone that they should do what I did, but this works for me and I'm happy to share.

mannykannot 5y ago

As someone unaware of Zig and its translate-C feature, I read the article as being about those things, not C.

rightbyte 5y ago

Or like use the cdecl cli tool ...

dosshell 5y ago

Or like use https://cppinsights.io/ https://cppinsights.io/ ...

michaelmior 5y ago
That gives the following output which I don't think is much more readable. void f(int * a) { void * p = reinterpret_cast<void *>(&a); ***reinterpret_cast<int *(*)[]>(p) = 1; }
- cies 5y ago
  Maybe after several steps of manual processing it is :) (not sure what steps that should be)
  - michaelmior 5y ago
    Sure but I don't think C++ Insights really helped.

kristoff_it 5y ago

> Or is this only for people who know Zig syntax but not C? It's a blog post hosted on zig.news (so intended for an audience that knows Zig), I think we can safely assume that it's not meant to be an universal guide for understanding C code, but rather the recount of a (somewhat minor) experience lived by the author. It's even stated upfront: > @rep_stosq_void on Twitter posted this strange sample of C code, and I wanted to show my process of understanding this contrived C code. "I was presented with this code, and this is what I did to understand it"

abaracadabi 5y ago

I feel like the whole zig language is a mess. Not a mess architecturally but syntactically. Also the whole “no macros, no preprocessor” boasting is kind of annoying. Macros are often a powerful way to extend a language, and a preprocessing phase is nice way to add some logic before compilation. Sure a C preprocessor is limited but it works well for simple stuff. I’m just sick of these head-strong nerds inventing things and being like: our thing is better than your thing. Nanner-nanner-noo! I don’t understand this desire to create a new language that looks like a mix of JavaScript and Rust. If anything, a cleaner syntax like Python makes more sense—give it some airiness. And I say that as a mostly C++ programmer who has used Python occasionally and appreciates how easy it is on my eyes. Also, my recommendation for folks who want to invent a new language: simplicity first. Don’t reinvent Rust or C++ because I’d rather spend time in either of those before investing lots of mental effort in a third option. For instance, I even consider C better than Zig just because the features are small and knowable. Python is better because the syntax is simple despite many language features. Go is a quaint little beast. Simple simple simple. Don’t squeeze stuff in there to fit every niche.

hansvm 5y ago
Maybe it's still not the language for you or for your projects, but for anyone else stumbling across this I don't think it's a fair characterization. Would you mind elaborating on where you think I'm off-base in the following? > head-strong nerds inventing things Let people have their fun. > preprocessor allows you to add some logic before compilation Zig's comptime feature does address that need. For most use cases where comptime and the preprocessor would both suffice, comptime has tons of strong advantages (type checked, errors traced back to the right lines, ability to write arbitrary turing-complete code without unholy syntactic black magic, no double evaluation, no need to wrap everything in extra parentheses, ....). It explicitly does not address use cases where you would actually want a textual preprocessor (like making the language look like Fortran), the argument being that the burden on reading unfamiliar code would be too high. The ease with which you can write arbitrary comptime code also enables you to do things like embed lookup tables in the binary, which in C you would ordinarily do by copy pasting from another tool (or writing constants by hand) or adding yet another preprocessor to the mix. Comptime isn't a clear win over preprocessing in all cases, but having written a lot of C and a little Zig, if I had to choose one for a hypothetical new project I'd be tempted to use Zig just for access to that one feature. > Syntax Zig does feel a little clunky to write to me right now, but I think that's mainly do to how often I'm using @someBuiltin() in Zig when I would be using an operator or an additional language feature in something like Python. That said, the syntax itself is incredibly simple. You can check that yourself for Zig [0], Python [1], and Go [2]. Zig has far fewer syntactic quirks and abilities than either of the other two. You have functions, operators, code blocks, types, reserved characters/keywords for builtin stuff, a few kinds of literals, and a little bit of syntactic sugar for working with structs. > Don't reinvent C++...for instance, I even consider C better than Zig just because the features are small and knowable To each their own. FWIW, Zig is explicitly and actively avoiding becoming a kitchen sink language like Rust or C++. They've added a few new features, and I personally find it easier to keep track of those than of all the different kinds of undefined behavior I might stumble across in C, especially since most of those (defer, errdefer, labeled break, ...) behave exactly as your intuition suggests they would. [0] https://ziglang.org/documentation/master/#Grammar https://ziglang.org/documentation/master/#Grammar [1] https://docs.python.org/3/reference/grammar.html https://docs.python.org/3/reference/grammar.html [2] https://golang.org/ref/spec https://golang.org/ref/spec

sobeston 5y ago

Author here, I'm just showing how I did it. It took a few minutes to do it for myself - figured it would be worth the 15 minutes or so it'd take to write it down. Just sharing my process, there's nothing too serious about this post. I've happened to have written a lot of C, but some areas (like this one) I'm not as confident in. This way of casting, and working with types is very poor syntax in my opinion (I mean below in this thread you have people arguing about the spiral rule and such, it's obviously a common confusion). Zig's way of expressing types and pointers is far superior, these transformations I made were done quickly and I didn't feel like there was any ambiguity or confusion in anything. Just a series of simple reductions, there are no "tricks" or easy mistakes to make in the code. It feels like a trivial proof. Obviously I am biased, this was posted to zig.news. I thought it was a neat showcase of translate-c, and how zig does some of these things nicer. I'm not telling everyone that they should do what I did, but this works for me and I'm happy to share.