I love these videos! I'm a happy subscriber. 7:35 It's fair to say that Zig's defer feature is similar to Go's defer feature, but if you make that comparison, it might be also worth pointing out an important difference: Go's defer appends the defer expression to a heap-allocated function-local list, and executes them upon function exit. Zig's defer (same as D's scope(exit)) applies to the current scope only. The difference is important when, for example, using a defer statement inside a loop.
Glad to hear it! And I do hope to interview you on Zig sometime this year probably, if you're agreeable. Just waiting until I feel like it's the right time.
It might be noted that, where C lets you change argument order here, C++ lets you know the order of execution-It gives you a different mental handle in exchange. …but code that relies on the order of execution of “semantically parallel” expressions is almost always very bad and ugly-to be avoided as a goal in itself. Still, I think it's nice to be able to have a mental picture of the stack at more points. It keeps my mind near the metal.
clang has this feature since many versions. You can already use it - it's awesome! Also: clang only warns about the declaration order. Also: it's called aggregate initialization - and you can't use it if you declared a constructor.
you will not learn proper programming in school. only people that actually get to program real world stuff with other people, or read real world program code, do learn it.
it doesn't really matter whether you let the coder write the initializers in order or out of order. what really matters is the order of construction and destruction. having the order of destruction being the reverse of the order of construction allows default values for member variables to depend on other member variables with default values that were declared before them
Was really disappointed with Rust drop order. It's really counterintuitive and doesn't have any advantages. Rust have editions for introducing breaking changes, why they haven't used that? And now we stuck with this decision forever. What a waste of possibilty to do right thing from start
In the page I showed (from 2017), they discussed possibilities for allowing opt in to the other order. Maybe editions could be an option, too. I haven't studied any recent conversations, though, so I'm not sure of the current state.
I've been using rust professionally for a year now and I haven't had any issues with the destruction order. Can you provide an example where this would be a disadvantage?
@@Karrq It's counterintuitive. That's the only disadvantage I know of. And it's quite important to focus on ergonomics in safety obsessed language because humans can handle only so much unnecessary cognitive load without making mistakes. There might be some performance advantage in reverse drop order (like in C++) because it's similar to how stack works, but I don't have any information on that
@@Karrq Researched it a bit and found that: 1. Panic during initialization drops elements in reverse order (inconsistent with regular drop order) 2. Due to straight drop order, constructor and destructor might have different relations to other objects. If we look at the example in this video, we will see that "thing 2" constructor called while "thing 1" exist, but it's destructor called when "thing 1" does not exist. This might lead to bugs, because this way destructing isn't just reverse constructing
I got scared when you said Zig doesn't guarantee structs are laid out in memory the way they're defined. I use that quite a bit in my bachelor project (an operating system) when switching between C and assembly. Being able to lay out a structure in assembly and then use it in C relies on that ordering. Though I also rely on __attribute for that so I guess ¯\o/¯
@@contextfree Nice! Zig is promising as a systems development language. I enjoy C for that purpose but Zig sure looks like a nice alternative to C. And the packed struct there serve the purpose I mentioned before. Quite similar to my GCC based __attribute__((__packed__)) I already use to better control padding
@@casperes0912 That's the main point of it. Zig also has a lot of low-level builtins so you can do essentially anything you want with packed structs. By default, you have a good amount of safety features (at least compared to C) but you can turn them off
2:36 When you take the address of a struct literal, where does the struct live? Is it put on the stack? What is it's lifetime? Usually temporaries only live for their enclosing statement, but that would mean the shown code has a dangling pointer. So I guess this is not what happens?
According to §6.5.2.5.5, "The value of the compound literal is that of an unnamed object initialized by the initializer list. If the compound literal occurs outside the body of a function, the object has static storage duration; otherwise, it has automatic storage duration associated with the enclosing block." (Spec version: ISO/IEC 9899:201x Committee Draft April 12, 2011 N1570, www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf )
I originally learned C when I first started out coding years ago and then moved onto C++ because I naively thought it would be 'better' in some way or 'more powerful' and harder to make mistakes... More recently I have learned how wrong I was and how uneducated the people were who were telling me this. It seems like C++ has massively held me back in terms of productivity in ways that C never did and I'm just about ready to ditch C++ altogether and jump back to C for the majority of my code and possibly C# for some things that C isn't great at natively (web mainly).
@@azyrael96 C can very easily perform everything 'oop' thats useful in c++. The only thing I can think would be a challenge to implement easily and well maybe multiple inheritance which I generally avoid if I can in c++.. generally if you're faced with an object that is an x and a y it's usually very easy to refactor to say object has an x and has a y. Oop has always existed in C it just doesn't have the syntactic sugar to express that. C++ has templates and more compile time features but generally many of this can actually be done with macros and pre processor.
@@fredhair > C++ has templates and more compile time features but generally many of this can actually be done with macros and pre processor. That's simply nonsense. C++ templates are a Turing-complete language that fully integrates with the rest of the language and its runtime. The pre-processor is a primitive text-replacement tool that shares no semantics with C and cannot interact with C in any way shape or form. Same with lambda's and destructors. These features cannot be emulated by C and have to be written manually each time. There's simply no way to do type-safe meta programming in C and nice utilities like auto-pointers or type inference just don't exist in C. That's not just syntactic sugar, that's fundamental language features.
@@totalermist Type safe meta programming is overrated. Not sure what you mean about C not being able to do 'auto pointers' but C is certainly capable of doing reference counting on pointers. You really don't know C very well I'm guessing..
@@fredhair I honestly don't care about your opinion on type safe meta programming. I pointed out that your statement was factually wrong. And C is *not* capable of automatic life-time management, no matter what your cognitive bias tries to tell you. You really don't know what you're talking about is what I suspect, since you don't even grasp the difference between *automatic* lifetime management and tools like reference counting. *Automatic* being the keyword here. > You really don't know C very well I'm guessing.. I don't need to guess to know that you don't have the faintest clue what you're even talking about.
