Hey, i just wanted to thank you for your videos about Zig. You are more or less the only source on youtube to learn zig. So, thank you very very much. Please continue the series!!! ❤❤❤
Rust's memory management is indeed revolutionary and advanced. But for some really low-level projects, you end up with most of your code in unsafe blocks and that turns out to not feel as Rusty.
@@dudethebuilder I was just baiting 🙃 I use Zig and I prefer it over Rust for simplicity and few other design decisions :D Still, thanks for your answer.
I am curious! Why is it legal in Zig to return a reference to a var that is allocated on the stack? Isn't this always wrong? There must be important situations that require this not to be an error...
I remember seeing a discussion on the Zig project GitHub mentioning that it's planned to be an error in the future, but I'm not sure if that's still the plan. Right now the main goal is compile speed and incremental compilation, so maybe if this type of analysis gets in the way of that, they'll hold it off.
Thanks again for yet another beautiful and helpful tutorial. Running the c function twice, as in your video results in the exact same addresses as well as values when I run it: ptr_to_const: 10da430f7 = 3, ptr_to_var: 7ff7b2585ec6 = 99 . Is this because of the version of Zig I'm running: 0.13.0-dev.46+3648d7df1 ? Point is, the value of the var doesn't change are the first function call has exited. Could you replicate this?
Yes this is why returning a pointer to stack memory is considered "undefined behavior," because the results are unpredictable. You may get the same value, or you may get anything else. This can vary beteween operating systems and build modes. On macOS, I always get 0 in debug mode and varying values in the different release modes. On Linux, I always get different values no matter what the build mode. You can change the build mode by adding -Doptimize=ReleaseSafe (or ReleaseFast or ReleaseSmall) to zig build run.
![Stromae, Pomme - “Ma Meilleure Ennemie” (from Arcane Season 2) [Official Visualizer]](http://i.ytimg.com/vi/1F3OGIFnW1k/mqdefault.jpg)
![[#2024MAMA] G-DRAGON - 무제(Untitled, 2014)+POWER+HOME SWEET HOME+뱅뱅뱅+FANTASTIC BABY | Mnet 241123 방송](http://i.ytimg.com/vi/Ox29z5Nf1Uk/mqdefault.jpg)
This is the clearest demonstration of memory I have ever seen, you are a brilliant educator!
Hey, i just wanted to thank you for your videos about Zig. You are more or less the only source on youtube to learn zig. So, thank you very very much. Please continue the series!!!
❤❤❤
I DON’T KNOW why this video has only 300 views… This is such great content. Thank you so much!
Dude the builder, you're like a beacon of light for those newcomers in Zig.
Thank you for the series, this is amazing!
Pointers, memory, RAII... Rust is *always* one step ahead.
Rust's memory management is indeed revolutionary and advanced. But for some really low-level projects, you end up with most of your code in unsafe blocks and that turns out to not feel as Rusty.
@@dudethebuilder I was just baiting 🙃 I use Zig and I prefer it over Rust for simplicity and few other design decisions :D Still, thanks for your answer.
I am curious! Why is it legal in Zig to return a reference to a var that is allocated on the stack? Isn't this always wrong? There must be important situations that require this not to be an error...
I remember seeing a discussion on the Zig project GitHub mentioning that it's planned to be an error in the future, but I'm not sure if that's still the plan. Right now the main goal is compile speed and incremental compilation, so maybe if this type of analysis gets in the way of that, they'll hold it off.
Thanks again for yet another beautiful and helpful tutorial. Running the c function twice, as in your video results in the exact same addresses as well as values when I run it: ptr_to_const: 10da430f7 = 3, ptr_to_var: 7ff7b2585ec6 = 99 . Is this because of the version of Zig I'm running: 0.13.0-dev.46+3648d7df1 ? Point is, the value of the var doesn't change are the first function call has exited. Could you replicate this?
Yes this is why returning a pointer to stack memory is considered "undefined behavior," because the results are unpredictable. You may get the same value, or you may get anything else. This can vary beteween operating systems and build modes. On macOS, I always get 0 in debug mode and varying values in the different release modes. On Linux, I always get different values no matter what the build mode. You can change the build mode by adding -Doptimize=ReleaseSafe (or ReleaseFast or ReleaseSmall) to zig build run.