zig is getting me back into low level code after decades of hiding from the crazy and old C preprocessor. Reading macro laden code haunts my dreams and tooling only helps me a little. I'm very thankful for this language :)
I just started laughing when he said "If you do not know what pointers are, I'm sorry but I'm just not gonna address that". Like, I knpw it wasn't meant, but it's still a good pun imo
I thought sometimes it is simpler to just introduce the concept right away than to waste time explaining why not to do so. Concept of a pointer is not difficult if visualized well
What I some times do @27:22 when I just dont wanna deal with type mismatches in testing, is set a comptime parameter to accept a type, which I send by doing typeof on the whateverI am trying to send to the function, and the actual parameters that the function will use will be set to that comptime type. I sometimes do the same for the return values ( from within that function )
Perfect scope of clarifying zig pointers for programmers. I've dealt with slices, raw pointers, typed pointers etc. But I ran by accident into a slice type error and couldn't figure it out. I also found the memory ownership of sized arrrays unexpected, I thought they were just a typed pointer.
Really good video, thank you for making it and posting. I fixed a bug in a program I'm writing and I had no clue how my changes fixed it, this video explained exactly why it was broken in the first place and how my changes fixed the issue
At 17:54, it was said that the first line( *[*]MyType ) is a single pointer to a sequence of unknown number of "MyType"s but shouldn't it be a single pointer to a pointer to a sequence of unknown number of "MyType"s or am I mistaken here?
I'm not perfect at describing weird pointer combos, but in general the important part is that [*] is a pointer to an item, and all the brackets are telling you that by adding sizeOf(MyType) to that pointer you might have another instance of MyType. The way you can know that's the case or not is through a separate scheme (e.g. you have a second argument that conveys how many, or you know there's going to be a sentinel instance of MyType that tells you it's the end of the line). So with that in mind, *[*]T means that you have a pointer pointing to a pointer to T, so you have a **T, but you know that the pointer you get by dereferencing the initial value, might have other Ts in front of it. So if `a` is the original value, `a.*` is a pointer to T, `a.*[1]` is a T (index access to a pointer adds the size and dereferences). I hope that is a good explanation, also take a look at the compileLog messages in this snippet: zig.godbolt.org/z/EYzrqT
@@kristoff-it I think your description in your response to Balen is correct, from looking at the Zig docs and the compileLog link you gave. But I think that means that your first two explanations (17:54) must be wrong... or at least a slip of the tongue. shouldn't they both have one more level of indirection than you said because the [ ] are also a dereference themselves.
@@shoulderstack5527 I think I might have used "sequence" and "sequence of pointers" a bit too liberally (to mean the same thing). Looking at the timestamp you linked, the first example is a single pointer that, when dereferenced, brings you to an array of pointers to MyType, but you don't know the length of that array. So to get to an instance of MyType (so not a pointer-to, but straight up a MyType value) you would write something like `my_var.*[2]`. The second example has the array in the outer layer, so you'd need to do `my_var[2].*` to obtain a MyType. Of course, this is all assuming the [*] have enough elements to accommodate for my example.
@@kristoff-it Also, I wanted to say 'Thanks so much' for these Zig Showtime and the Advent of Code videos. They really help to lower the cost of entry for someone like me. It means I can afford to devote some time to finding out if Zig is a good choice for me because you made it so easy to explore. Thanks!
Null (address 0) represents the nil case of an optional value. This is similar to Rust's null pointer optimization where for instance the size of Option is the same as the size of &T. The 'nil' case can be safely represented as address 0 because pointers in rust (and zig) cannot be null.
@@HairyPixels Yeah basically Optional pointers in Zig or Rust are just syntactic sugar for branching on null. The equivalent in C would be : foo() { ... stuff happening. my_type *ptr = memory_reference_of_something(); if (ptr == NULL) // aka pointing at address 0. return (error); ... stuff happening. } The problem with null pointer is that they can be null, and if they are not systematically checked than it's a big deal, Optional, put that burden on the type system and the compiler. In Zig or Rust you can't access a pointer unless you are explicitly acknowledging that it can be null, either by handling the null case, or by assuming it to be unreachable.
ty nise video explaining pointers in zig . i have this idea hat insted of "&adress" it should be "adress." so the logic whit the pontiers would be easyer adress. *pointer .value insted of &adress *pointer . value
![I.N "HALLUCINATION" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/n5B5q1Hwt_U/mqdefault.jpg)
zig is getting me back into low level code after decades of hiding from the crazy and old C preprocessor. Reading macro laden code haunts my dreams and tooling only helps me a little. I'm very thankful for this language :)
I just started laughing when he said "If you do not know what pointers are, I'm sorry but I'm just not gonna address that".
Like, I knpw it wasn't meant, but it's still a good pun imo
Your comment is failing to compile (line 3 > error: Like, I knpw it wasn't meant)
I thought sometimes it is simpler to just introduce the concept right away than to waste time explaining why not to do so. Concept of a pointer is not difficult if visualized well
@@seanknowles9985 parsing error: "Like, I knpw it wasn't meant" found on line 4
pointer is a stupid abstraction, use raw adresses like a pro
What I some times do @27:22 when I just dont wanna deal with type mismatches in testing, is set a comptime parameter to accept a type, which I send by doing typeof on the whateverI am trying to send to the function, and the actual parameters that the function will use will be set to that comptime type. I sometimes do the same for the return values ( from within that function )
Perfect scope of clarifying zig pointers for programmers. I've dealt with slices, raw pointers, typed pointers etc. But I ran by accident into a slice type error and couldn't figure it out. I also found the memory ownership of sized arrrays unexpected, I thought they were just a typed pointer.
Really good video, thank you for making it and posting. I fixed a bug in a program I'm writing and I had no clue how my changes fixed it, this video explained exactly why it was broken in the first place and how my changes fixed the issue
I love the font you are using for the presentation code. Is it Proggy?
fonts.google.com/specimen/Press+Start+2P
At 17:54, it was said that the first line( *[*]MyType ) is a single pointer to a sequence of unknown number of "MyType"s but shouldn't it be a single pointer to a pointer to a sequence of unknown number of "MyType"s or am I mistaken here?
I'm not perfect at describing weird pointer combos, but in general the important part is that [*] is a pointer to an item, and all the brackets are telling you that by adding sizeOf(MyType) to that pointer you might have another instance of MyType. The way you can know that's the case or not is through a separate scheme (e.g. you have a second argument that conveys how many, or you know there's going to be a sentinel instance of MyType that tells you it's the end of the line). So with that in mind, *[*]T means that you have a pointer pointing to a pointer to T, so you have a **T, but you know that the pointer you get by dereferencing the initial value, might have other Ts in front of it. So if `a` is the original value, `a.*` is a pointer to T, `a.*[1]` is a T (index access to a pointer adds the size and dereferences).
I hope that is a good explanation, also take a look at the compileLog messages in this snippet: zig.godbolt.org/z/EYzrqT
@@kristoff-it That was a very clear explanation, thank you!
@@kristoff-it I think your description in your response to Balen is correct, from looking at the Zig docs and the compileLog link you gave. But I think that means that your first two explanations (17:54) must be wrong... or at least a slip of the tongue. shouldn't they both have one more level of indirection than you said because the [ ] are also a dereference themselves.
@@shoulderstack5527 I think I might have used "sequence" and "sequence of pointers" a bit too liberally (to mean the same thing). Looking at the timestamp you linked, the first example is a single pointer that, when dereferenced, brings you to an array of pointers to MyType, but you don't know the length of that array. So to get to an instance of MyType (so not a pointer-to, but straight up a MyType value) you would write something like `my_var.*[2]`. The second example has the array in the outer layer, so you'd need to do `my_var[2].*` to obtain a MyType. Of course, this is all assuming the [*] have enough elements to accommodate for my example.
@@kristoff-it Also, I wanted to say 'Thanks so much' for these Zig Showtime and the Advent of Code videos. They really help to lower the cost of entry for someone like me. It means I can afford to devote some time to finding out if Zig is a good choice for me because you made it so easy to explore. Thanks!
42:04 this doesn't seem to work as of today
Thank you! You are awesome!
whoever. came up with the citrus duck. THANK YOU
Thanks 👍 keep sharing!
36:42
Thank you very much :)
Good stuff
How is an optional pointer the same size as a pointer? doesn't it need some flag to know if it's set or not?
Null (address 0) represents the nil case of an optional value. This is similar to Rust's null pointer optimization where for instance the size of Option is the same as the size of &T. The 'nil' case can be safely represented as address 0 because pointers in rust (and zig) cannot be null.
@@shilangyuoh that's interesting, nil is reserved by virtue of it being illegal on raw pointers. Makes sense now thanks.
@@HairyPixels Yeah basically Optional pointers in Zig or Rust are just syntactic sugar for branching on null. The equivalent in C would be :
foo() {
... stuff happening.
my_type *ptr = memory_reference_of_something();
if (ptr == NULL) // aka pointing at address 0.
return (error);
... stuff happening.
}
The problem with null pointer is that they can be null, and if they are not systematically checked than it's a big deal, Optional, put that burden on the type system and the compiler. In Zig or Rust you can't access a pointer unless you are explicitly acknowledging that it can be null, either by handling the null case, or by assuming it to be unreachable.
"if you know python.." goes on with an example where a slice in a reference and an assignment is a copy.. the exact opposite of python :D
ty nise video explaining pointers in zig . i have this idea hat insted of "&adress" it should be "adress." so the logic whit the pontiers would be easyer adress. *pointer .value insted of &adress *pointer . value
At 14:20 it should be "you first unpack the optional", not "you first unpack the pointer".
ruclips.net/video/VgjRyaRTH6E/видео.html
feature suggestion: suggest the fix in the compiler error like rust does
Nice :)