# Zig for C programmers guide?

**URL:** <https://ziggit.dev/t/zig-for-c-programmers-guide/5909>\
**Category:** Explain\
**Created:** [September 6, 2024, 10:02pm UTC](https://ziggit.dev/t/zig-for-c-programmers-guide/5909 "2024-09-06T22:02:01Z")\
**Posts on this page:** 14\
**Page:** 2

<div class="post-metadata">

**Author:** ![deafbeef](https://ziggit.dev/letter_avatar_proxy/v4/letter/d/51bf81/32.png) [@deafbeef](https://ziggit.dev/u/deafbeef)\
**Post date:** [September 7, 2024, 10:23pm UTC](https://ziggit.dev/t/zig-for-c-programmers-guide/5909/21 "2024-09-07T22:23:32Z")

</div>

Thank you, guys for sharing! I think I picked up enough ammo to continue my quest!

---

<div class="post-metadata">

**Author:** ![mnemnion](https://ziggit.dev/user_avatar/ziggit.dev/mnemnion/32/2478_2.png) [@mnemnion](https://ziggit.dev/u/mnemnion)\
**Post date:** [September 7, 2024, 10:47pm UTC](https://ziggit.dev/t/zig-for-c-programmers-guide/5909/22 "2024-09-07T22:47:39Z")

</div>

> [@deafbeef](#):
>
> You have got me curious, @mnemnion. After Modula2/Pascall my will was broken by years of C/C++ to the point that I am ok with ‘\*’ vs ‘^’ 🙂. However I don’t like to type therefore I vote for {} vs begin/end. Anyway, I take you are joking…

Not joking, no. AZERTY (France, Belgium) and QWERTZ (German-speaking countries) don’t have shifted keys for `{` and `}`, they’re accessed with the AltGr key, which lives where US layouts have the right Alt key. So instead of fluently hitting one of two big shift keys, you have to hit one small Alt key.

They’re also on number keys, this is particularly annoying for QWERTZ, where the numbers are 7 and 0, I encourage you to try and type right-Alt-0 and right-Alt-7 for a sense of how badly this sucks. With AZERTY it’s 4 and 5, so typing it with both hands is not as bad.

I know about this mainly from German programmers complaining about it, for the record, rather than out of some Special Interest in international keyboard layouts. Programmers in those countries often switch to a less onerous keyboard layout when programming, or just switch period.

---

<div class="post-metadata">

**Author:** ![pierrelgol](https://ziggit.dev/user_avatar/ziggit.dev/pierrelgol/32/10233_2.png) [@pierrelgol](https://ziggit.dev/u/pierrelgol)\
**Post date:** [September 8, 2024, 12:11am UTC](https://ziggit.dev/t/zig-for-c-programmers-guide/5909/23 "2024-09-08T00:11:28Z")

</div>

I know I’m a bit hash, there is indeed some truly wonderful C/C++ codebase (looking at you Raylib). But my point was more that Zig is very readable so it’s easy for a beginner to look at advance Zig code and still make sense of it, the same is hard to say for most C/C++ out there unless you are already really versed into it.

---

<div class="post-metadata">

**Author:** ![pierrelgol](https://ziggit.dev/user_avatar/ziggit.dev/pierrelgol/32/10233_2.png) [@pierrelgol](https://ziggit.dev/u/pierrelgol)\
**Post date:** [September 8, 2024, 12:13am UTC](https://ziggit.dev/t/zig-for-c-programmers-guide/5909/24 "2024-09-08T00:13:57Z")

</div>

I can confirm as a French that the French ISO layout is truly god tier awful for programming, this is why I and most devs I know in France code on US or UK Qwerty but now it’s hard to find laptop with Qwerty kb ☹

---

<div class="post-metadata">

**Author:** ![Sze](https://ziggit.dev/user_avatar/ziggit.dev/sze/32/496_2.png) [@Sze](https://ziggit.dev/u/Sze)\
**Post date:** [September 8, 2024, 10:59am UTC](https://ziggit.dev/t/zig-for-c-programmers-guide/5909/25 "2024-09-08T10:59:51Z")

</div>

4 posts were split to a new topic: [Neovim insert mode keybinds](https://ziggit.dev/t/neovim-insert-mode-keybinds/5925)

---

<div class="post-metadata">

**Author:** ![dee0xeed](https://ziggit.dev/letter_avatar_proxy/v4/letter/d/3ab097/32.png) [@dee0xeed](https://ziggit.dev/u/dee0xeed)\
**Post date:** [September 8, 2024, 1:18pm UTC](https://ziggit.dev/t/zig-for-c-programmers-guide/5909/26 "2024-09-08T13:18:21Z")

</div>

> [@dee0xeed](#):
>
> Problems of C, and how Zig addresses them

> Any standard library function that allocates on the heap receives an `Allocator` as parameter. Anything that doesn’t do so won’t allocate on heap, guaranteed

Actually [it’s not guaranteed at all](https://ziggit.dev/t/wildcat-allocations-and-allocator-scope/2257).

---

<div class="post-metadata">

**Author:** ![dee0xeed](https://ziggit.dev/letter_avatar_proxy/v4/letter/d/3ab097/32.png) [@dee0xeed](https://ziggit.dev/u/dee0xeed)\
**Post date:** [September 8, 2024, 1:42pm UTC](https://ziggit.dev/t/zig-for-c-programmers-guide/5909/27 "2024-09-08T13:42:13Z")

</div>

> [@dimdin](#):
>
> Zig compiler decides to pass by value or by `const *`

This resembles with C#/D/Swift ‘value types/reference types’ stuff.  
Syntactically the same, semantically not. Bad IMHO.

---

<div class="post-metadata">

**Author:** ![mnemnion](https://ziggit.dev/user_avatar/ziggit.dev/mnemnion/32/2478_2.png) [@mnemnion](https://ziggit.dev/u/mnemnion)\
**Post date:** [September 8, 2024, 2:57pm UTC](https://ziggit.dev/t/zig-for-c-programmers-guide/5909/28 "2024-09-08T14:57:04Z")

</div>

> [@dee0xeed](#):
>
> > Any standard library function that allocates on the heap receives an `Allocator` as parameter. Anything that doesn’t do so won’t allocate on heap, guaranteed
> 
> Actually [it’s not guaranteed at all](https://ziggit.dev/t/wildcat-allocations-and-allocator-scope/2257).

Leaving aside the peculiarity of disagreeing with yourself this way, old-dee0xeeed was talking about the standard library, where so far as I know, it is in fact guaranteed that anything which allocates will take an allocator (and vice versa).

This is indeed a convention, not a law of the language, and that’s good. Application code in particular can benefit from global allocation, in terms of code organization.

If you’re not auditing a library your code is using, at least lightly, then a hidden global allocator is the least of your worries. If you spot a library (code intended to be used by other Zig code as a module) using an allocator without the entry point taking one, feel free to supply a patch, or raise an issue on the tracker, if only so that other people can be aware of it.

I am firmly of the opinion that library code should follow this convention strictly, and generically where possible. It may make sense under rare circumstances for a library to, for example, assume an arena, but it’s better if it doesn’t.

Use of an interior allocator, if there is any, should be isolated to a C interface, where there isn’t a lot of choice in the matter. We have [std.heap.c\_allocator](https://ziglang.org/documentation/master/std/#std.heap.c_allocator) as an adapter for this purpose.

---

<div class="post-metadata">

**Author:** ![dee0xeed](https://ziggit.dev/letter_avatar_proxy/v4/letter/d/3ab097/32.png) [@dee0xeed](https://ziggit.dev/u/dee0xeed)\
**Post date:** [September 8, 2024, 4:34pm UTC](https://ziggit.dev/t/zig-for-c-programmers-guide/5909/29 "2024-09-08T16:34:55Z")

</div>

> [@mnemnion](#):
>
> old-dee0xeeed

Who is that ‘old-dee0xeeed’? 🙂

> [@mnemnion](#):
>
> was talking about the standard library, where so far as I know, it is in fact guaranteed that anything which allocates will take an allocator

Currently I do not give an eye to Zig’s standard library,  
'cause it’s evolving thing and nobody knows where it will come eventually.

> [@mnemnion](#):
>
> I am firmly of the opinion that library code should follow this convention strictly, and generically where possible

I 200% agree, but there is no mechanism to prevent using memory allocations on the sly.

---

<div class="post-metadata">

**Author:** ![mnemnion](https://ziggit.dev/user_avatar/ziggit.dev/mnemnion/32/2478_2.png) [@mnemnion](https://ziggit.dev/u/mnemnion)\
**Post date:** [September 8, 2024, 4:43pm UTC](https://ziggit.dev/t/zig-for-c-programmers-guide/5909/30 "2024-09-08T16:43:25Z")

</div>

> [@dee0xeed](#):
>
> I 200% agree, but there is no mechanism to prevent using memory allocations on the sly.

True! Nor is there a mechanism to prevent a library from deleting your hard drive. Caveat author.

I think “other people won’t want to use a library which takes allocation out of the hands of the user” is enough social covenant to prevent this from becoming a problem. Time will tell.

There are enough good reasons to do otherwise that convention is what we have to work with. My experience in other language ecosystems is that it punches way above its weight. [Type piracy in Julia](https://docs.julialang.org/en/v1/manual/style-guide/#Avoid-type-piracy), for instance, is exceedingly rare, simply because it’s frowned upon.

---

<div class="post-metadata">

**Author:** ![dee0xeed](https://ziggit.dev/letter_avatar_proxy/v4/letter/d/3ab097/32.png) [@dee0xeed](https://ziggit.dev/u/dee0xeed)\
**Post date:** [September 8, 2024, 4:56pm UTC](https://ziggit.dev/t/zig-for-c-programmers-guide/5909/31 "2024-09-08T16:56:05Z")

</div>

> [@mnemnion](#):
>
> I think “other people won’t want to use a library which takes allocation out of the hands of the user” is enough social covenant to prevent this from becoming a problem

300% agree, but “other people” might not even suspect that a library they are using is doing something kinda “prohibited”.

---

<div class="post-metadata">

**Author:** ![deafbeef](https://ziggit.dev/letter_avatar_proxy/v4/letter/d/51bf81/32.png) [@deafbeef](https://ziggit.dev/u/deafbeef)\
**Post date:** [September 8, 2024, 6:24pm UTC](https://ziggit.dev/t/zig-for-c-programmers-guide/5909/32 "2024-09-08T18:24:04Z")

</div>

> [@mnemnion](#):
>
> I encourage you to try and type right-Alt-0 and right-Alt-7 for a sense of how badly this sucks.

Thank you for clarification @mnemnion. I am not sure what is the better alternative. Significant white spaces like Python or Yaml? I suffer from the same problem of not being a native English speaker and I use to use keyboard stickers, now days I just program on us-eng keyboard and use virtual keyboards to write in my native language. Anything Zig picks will hurt somebody in some shape or form. IMHO: moving from {} to anything else would alienate C programmers Zig is trying to target.

---

<div class="post-metadata">

**Author:** ![deafbeef](https://ziggit.dev/letter_avatar_proxy/v4/letter/d/51bf81/32.png) [@deafbeef](https://ziggit.dev/u/deafbeef)\
**Post date:** [September 8, 2024, 7:31pm UTC](https://ziggit.dev/t/zig-for-c-programmers-guide/5909/33 "2024-09-08T19:31:16Z")

</div>

> [@dee0xeed](#):
>
> This resembles with C#/D/Swift ‘value types/reference types’ stuff.  
> Syntactically the same, semantically not. Bad IMHO.

C# rules are very cut and dry (sorry, no deep knowledge of D/Swift). Value types are always passed by value (stack copy), reference types (hence the name) are always passed by reference (stack holds the reference, heap holds the actual value). BTW: C# array is a reference type, so there is no way to copy C# array items to stack.

---

<div class="post-metadata">

**Author:** ![mnemnion](https://ziggit.dev/user_avatar/ziggit.dev/mnemnion/32/2478_2.png) [@mnemnion](https://ziggit.dev/u/mnemnion)\
**Post date:** [September 8, 2024, 11:55pm UTC](https://ziggit.dev/t/zig-for-c-programmers-guide/5909/34 "2024-09-08T23:55:48Z")

</div>

> [@deafbeef](#):
>
> Anything Zig picks will hurt somebody in some shape or form.

This was my main point about `^` actually. I suspect (just based on reading the issues) that `ptr.*` was chosen more out of familiarity than because `^` is annoying to type on some keyboards. If you read through, it took a few passes before someone hit on `[identifier] [dot] [star]` being unambiguous to parse.

I think that was the better choice, personally, and Pascal was my first language. Sticking with the `*` familiar from C, but reversing declaration and dereferencing like Pascal, it’s a good balance.

Random fact: Pascal pointers were originally defined as `↑`, not `^`. The 1963 ASCII standard had an up arrow, where the caret is now. That was officially changed in 1967, but that sort of change propagated slowly, particularly in Europe.

We’ve drifted pretty far off the topic, though, which has split once already, so that’s enough lore out of me for now.

[Previous page](https://ziggit.dev/t/zig-for-c-programmers-guide/5909.md?page=1)
