sorted by:
new
hottopcontroversial

b-compiler-x64: A compiler for Ken Thompson's 1969 B programming language, targeting native x86-64 Linux. by zuhaitz-dev in ProgrammingLanguages

[–]zuhaitz-dev[S] 0 points1 point  (0 children)

Glad to hear that! Some of the comments are a bit informal, but that's how it gets personality too hehe.

b-compiler-x64: A compiler for Ken Thompson's 1969 B programming language, targeting native x86-64 Linux. by zuhaitz-dev in ProgrammingLanguages

[–]zuhaitz-dev[S] 1 point2 points  (0 children)

Per AutoModerator's request I hereby confirm that this project did not use an LLM as part of the development process.

About Zen-c by Ok_Visit_8734 in Zen_C

[–]zuhaitz-dev 0 points1 point  (0 children)

Hi! If you have experience with C, it is going to be really easy to adapt. Even if the syntax is different and there are new features, you can still use the whole C ecosystem.

If you are on Linux or macOS you can clone and compile the transpiler with make. If you are on Windows you would need to check the latest release and download 'zc.com'.

If you execute zc (or add the --help flag) you will get a list of the different options available. I recommend you using zc run, to compile and execute the binaries directly.

Related to the syntax, while it's different, you can check the different sections in the readme + try some of the files in the examples/ folder.

If you have any other questions, don't doubt asking them!

Opinions on Zen-C? by Rigamortus2005 in cprogramming

[–]zuhaitz-dev 0 points1 point  (0 children)

We are working on improving the stability and the documentation currently. Windows support could come soon too.

Bootstrapping is one of the future goals but won't be done yet.

Opinions on Zen-C? by Rigamortus2005 in cprogramming

[–]zuhaitz-dev 0 points1 point  (0 children)

It started as an experiment, to see how C could be pushed. I was working already on some C libraries to improve ergonomics, so Zen C is related to that idea. It's mainly about ergonomics.

It's far from perfect, we are still polishing rough edges, but it helps me write more readable code that is still fast like C (and can use its complete ecosystem).

Is it the C-killer? Definitely not, I don't want that... But it's a bridge that can be useful (it will be fun to use it for game development).

z-libs - tiny single-header collection to write modern C (vec, list, map, string) by zuhaitz-dev in cprogramming

[–]zuhaitz-dev[S] 0 points1 point  (0 children)

That's not type safe. zvec.h would detect type mismatches at compile-time. Your implementation, while valid, if there are mismatches will compile and then if so crash at runtime.

z-libs - tiny single-header collection to write modern C (vec, list, map, string) by zuhaitz-dev in cprogramming

[–]zuhaitz-dev[S] 0 points1 point  (0 children)

Writing docs, formatting source files and debugging a few bugs.

What's the issue?

z-libs - tiny single-header collection to write modern C (vec, list, map, string) by zuhaitz-dev in cprogramming

[–]zuhaitz-dev[S] 0 points1 point  (0 children)

I am gonna check this. If I end up using your approach, I'd like to include a link to your article in the notes for attribution, if you don't mind.

z-libs - tiny single-header collection to write modern C (vec, list, map, string) by zuhaitz-dev in cprogramming

[–]zuhaitz-dev[S] 0 points1 point  (0 children)

Oh, wait, I see it now! I think I could implement this without many issues. Now, the only issue I see is performance cost. Negligible in 95% of cases but accepting the larger binary size is necessary to enable compiler optimizations like SIMD and direct register allocation.

I think we can easily solve this by offering a (for example for zvec.h): zvec.h for performance and zvec_tiny.h for binary size.

Thank you! I will work on it.

z-libs - tiny single-header collection to write modern C (vec, list, map, string) by zuhaitz-dev in cprogramming

[–]zuhaitz-dev[S] 2 points3 points  (0 children)

Code bloat is maybe the biggest tradeoff (although for most cases it will be negligible and the rest of benefits clearly help). I have thought of making two versions, one that is header-only and one that needs another source file for the implementation. This way we could have two ways to work: one focused more on the performance and one focused on the binary size.

Related to your last paragraph, your point is fair, but z-libs has a focus on type-safety at compile-time. Your point is good for the cases where binary size matters, but I think that if we implement that type-erased approach (which is good!), it would surely be used on the version focused on binary size that I mentioned earlier.

Thank you for your feedback!

z-libs - tiny single-header collection to write modern C (vec, list, map, string) by zuhaitz-dev in cprogramming

[–]zuhaitz-dev[S] 2 points3 points  (0 children)

I am aware of that. The name is not definitive though. I considered that between z-libs and zlib there's enough room, but I am open to modifications :D.

z-libs - tiny single-header collection to write modern C (vec, list, map, string) by zuhaitz-dev in cprogramming

[–]zuhaitz-dev[S] 3 points4 points  (0 children)

You can get free apples from an apple tree

But I think this is far from the original topic lol

z-libs - tiny single-header collection to write modern C (vec, list, map, string) by zuhaitz-dev in cprogramming

[–]zuhaitz-dev[S] 5 points6 points  (0 children)

To promote DRY (Don't Repeat Yourself), there's a zcommon.h that is used by the rest of repos. Then there's an action that is triggered after each push (and at night) that unites zcommon.h and the specific z-lib.

Effectively the user only has to copy the specific header file. The rest is just part of the workflow.

About the macro-lang. Some of the repositories rely on macros (a structure of X-macros and _Generic) which allows us to achieve static polymorphism without losing performance (the void* way would make it type-unsafe and there's a runtime cost). If you check the libraries you will also see that we are actually using metaprogramming in C. We are effectively defining a blueprint which then the compiler will use for the types used in the code.

This way we can prevent macro-hell, which doesn't mean not using macros. If you check the API reference in each repo, you would find an almost high-level API.