Constructors Are Broken 

The realization 'in a factory, you can do a bunch of logic, then construct the object with all its initial values in one fell swoop, so there's never an invalid object' is really clever.

“You can grep your files for unsafe and find where you might have made a mistake” is the single best way of explaining (to me) why the “unsafe” keyword exists and why the compiler is more strict otherwise. That made so many things just *click* in my mind - great video!!

This reminds me of a concept I picked up in one of @NoBoilerplate's videos, which I now repeat like mantra when coding in Rust: "Make invalid state unrepresentable"

Note that at 7:47 the same optimization (0 = None) means that the NonZeroU8::new function is actually a no-op even though it returns Option and contains a match. Using it won't cause a branch until/unless you check the result yourself, for example by unwraping it. If you want a NonZeroU8 the effect is largely the same, but of you're passing to an API that wants Option regardless, then no extra branch is incurred. (This doesn't necessarily apply without optimizations turned on, of course.)

Another observation: It's refreshing that your videos have no background audio. Pure calm voice is so much better to deliver concise factual information than noisy music. Wish that more educators would rediscover "less is more".

8:30 note that the “new” and “unchecked_new” functions need to be marked as ‘pub’ in order for them to be exposed for outside use - and that the member(s) of the structure must not be marked pub to prevent people from constructing a NonZeroU8 on their own (and from mutating the member(s)).

I really enjoyed this video, I've used a bunch of languages with constructors (C++, Java, C#) and have been using Rust for a little while now. The other day, I had a little C# to write, and when working with constructors I felt a familiar tiny little pang of dread again, and I think you just nailed down what I was feeling. The metaphor that a constructor is a function that returns an initialised object isn't quite true, and it's in the details where some subtle ambiguities and bugs often lie. Rust applies the metaphor much more literally, and I feel a lot more confident in what I'm doing. Funnily enough, this is one of the things I've appreciated the most with Rust. There are much fewer "things" to consider in the language. It's closer to C in many ways in that regard.

incredible video. editing, narration, explanation, the code itself - everything was fantastic and so concise. as a rust programmer who’s never touched c++ i still learned a lot about programming in general. please keep it up.

9:00 "first of all exceptions are incredibly expensive for what's supposed to be a very simple and low-level type " This is only true if exceptions are used as a regular control flow mechanism (I think because of the stack unwinding but I'm not actually familiar). If the exception is not triggered, the cost is insignificant. Everything else you said about them is true though. Might've been worth mentioning that panic! exists for some niche low level uses, and that Result can't replace exceptions in every instance, but in practice for the vast majority high level code it can. Really really high quality video, I am astounded by the amount of misinformation that exists on C++, especially from other young people.

10:38 A potential way to “mark” create_unchecked as unsafe (although I personally think that “grep unsafe” is analogous to “grep unchecked”) is to use “the passkey idiom” as a way of keeping more control of which code might call specific member functions.

The only problem with Rust's style is that in-place initialization on the heap isn't guaranteed. The code: let data = Box::new([0u8; 10_000_000]); is supposed to create 10 megabytes of data on the heap but might overflow the stack in the process. I tested this and it actually crashes in debug mode but works in release mode, pretty gross. I think solutions to guarantee a stack overflow won't happen are being worked on but it's not trivial. The way constructors in C++ work, you can just allocate the space on the heap and then call the constructor on the pointer.

C++ initialization rules are a mess man

8:30 "Which is something you can grep your code for" is slightly complicated by the fact that the actual mistake can easily happen outside the unsafe block. We can see that in this very example if you pass a variable to new_unchecked() and somewhere else in the code can accidentally set that variable to 0 before that call. It is still a very good idea to have in the language. It just doesn't make it as easy as it might seem at first glance.

10:28 "Because C++ doesn't have a builtin notion of safety" It does, you just dismissed it at 8:57. With exceptions enabled you can make an "unsafe" factory function by marking it noexcept. In case of invalid input the constructor will throw an exception, terminating your program. You (almost) don't pay for exceptions, don't have to handle them for such a scenario, and it guarantees the invariant. It is a bit 'hacky' and I acknowledge that it is less 'neat' than the rust way, but it's possible. And I don't think your arguments against exceptions hold much ground. 1. Yes, fully exceptionless C++ is faster. But firstly, exceptions incur most of their cost when they're actually thrown and handled. For most use cases the overhead for exceptions being enabled is negligible. Secondly, if we're doing a feature comparison here, safe Rust is also slower (potentially also really slow and expensive) compared to unsafe Rust. I'd go as far as to say that these arguments have the same weight when comparing language performance, cancelling each other out, although it's too much work to prove it properly. 2. "Lots of codebases aren't prepared to handle them". Well, sounds like they should start using the language like it's supposed to be used and actually learn the core safety features. I agree with "invisible code path" argument though, it is the only sound one and actually a really strong one.

6:10 if I remember correctly 42 is what’s set because NSDMI is basically a default value, could be wrong tho lol

Reading about the Superconducting Super Elider brings up another fun thing about Rust: moves. C++ has all sorts of rules about when moves can and can't be elided, specifically because there's API surface for arbitrary types to be told when they are being moved - move constructors, specifically. In Rust, anything can move anything as many or as few times as it likes, and if you don't like that, you have to stuff it behind a smart pointer (like Pin). This is mainly notable because it results in one of the biggest problems with Rust/C++ interop: everything has to be behind smart pointers. If you put a C++ type on a Rust stack frame, Rust will move it around without calling the move constructor, which is hilariously unsound.

This video is so nice! It just resonates so much with struggle I had using C++ at first (like finding out that order of class members affects init order or that factory functions make much more sense in general) and constructors problem so well covered here.

Another great video! I'm always astounded when watching your videos how often you state an idea that I say all the time to my teammates. Avoiding partially initialized objects, making constructor bodies empty, Being wary of how the spaces between lines can evolve even if the current code looks good. I need to keep directing my teammates to your videos

It just amazes me time and time again, how the great choices that were made at rusts core make it such a practical and cohesive language to work with and reason about and have a butterfly-effect-like influence on so many parts in the language itself Another great example for that is the std::mem::drop implementation, made me chuckle when I found out about it :D

It's been quite a while since I've worked with C++, but that packing of private implementation made me think of the PImpl pattern. Not for the same application reasons, but certainly still to improve safety/stability, and also similarly with a cost from the indirection that cannot be optimized away.

The solution you propose at the end (using aggregate data structures to ensure type validity) for the C++ side reminded me of a CppNorth talk from last year, "Writing C++ to Be Read". It touches on the topic of constructor initialization and how aggregate initialization provides advantages for quite a few cases.

I believe clangd has warnings for every mistake inside a constructor that you mentioned. It will tell you if you're reading from a member that hasn't been initialized yet, it will tell you that you aren't calling an overridden virtual function, etc. Obviously it would be better to disallow those mistakes in the language standard instead of relying on warnings, but good tooling helps a lot.

I'm not sure I would call these associated fns "factories." The term "constructor" seems to apply equally well. My understanding of factories from OOP is that they are objects whose sole responsibility is constructing other objects (especially abstract ones with multiple implementations). I think there's a key distinction in that factories hold onto configuration data while constructors are simply pure functions.

Thanks for these videos! An informed opinion, educated discussion, and soothing voice with great visuals make this a great channel. Keep doing what you're doing, man.

As someone who doesn't know C++ and hasn't learned Rust yet, this was very informative 🎉

Honestly one of the better coding talks I have seen. It is very thoughtful and your solution can be easily reasoned about

Impressive, a single vid and you got a subscriber. That didn't happen for me for a long time. I knew C++ was unsafe but this really makes it stick in. I like the m. approach though. Scary to propose it in production code but I for sure will try that in my day to day programs.

Most languages benefit this, particularly when incorporating the Result or Option types. Make invalid states unrepresentable. It's only a problem when the frameworks being used fail to support it effectively, and force you into the constructor approach

I'm so glad this high-level content exists. Great video. Your expertise and knowledge is clear.

what about a private constructor that takes in all fields?

Great video, very interesting. Also great editing and presentation. Thanks for sharing!

The unsafe part is wrong actually. We get the same reasoning for NonZeroU8 - it can be 0 and undefined at all points of the program, due to the exposed unchecked API. This is identical to the exposed static function in C++. And the constructors, you're doing what a lot of people unfortunately mistake the constructors in C++ to do. You're handling business logic in the constructor. That is "wrong". The constructor is meant to initialize ("acquisition of memory or a resource") not transform. The correct way would have been to have the definition of the constructor be CString(std::unique_ptr&& buf, u64 len, bool is_ascii) noexcept. This is a mistake a lot of people do. For instance, you wouldn't do this in Rust (pseudo code): let cstr = CString { ptr: alloc(ptr_cstr, strlen(ptr_cstr)), len: strlen(ptr_cstr), is_ascii: check_ascii(ptr_cstr) }. Obviously, what you would do is construct each part, and then hand it to the initialization of the object. This is how you should *always* go about doing it for classes and structs in C++ too. Also, use public members. Write your `Immutable` wrapper class that has an `const T& operator() const noexcept { return data; }` and you need no getters and setters. The problem is people reach for a class WAY, WAY, WAY (I mean, WAAAAAAAY) too often when they really need a struct. The CString in the C++ example should be a struct, honestly. struct CString { Immutable ptr, Immutable len, Immutable is_ascii; }; Also, emplace_back API's takes `Args...` for a reason! To be able to construct "my" CString type like so: vec.emplace_back(std::move(un_ptr), 42, true); Otherwise I absolutely agree - constructors has been a mess in C++, since so many want to do logic in them. That is a problem this video highlights both explicitly and implicitly.

Thanks for thoughtful videos, always a pleasure to watch them

Amazingly informative video, as usual. Very well presented

I always called factories as functions that returned new instances of a set of classes based on their arguments or other rules. The classic example is an image factory that can return a jpeg image class or a png image class based on the image file type. Callers need not care about the specialization and have a single method for construction

One advantage with C++ constructors is "emplace_back" for vectors and other in-place construction. For Rust, you typically have to hope the compiler optimises it that way (I believe its called Return Value Optimisation). However, it's of course trivial to have it in C++ since constructors use pointers instead. I know eventually it's going to be solved, but it's taking a bit unfortunately.

As a C programmer, I dont use constructors

Constructors can be good as an interface (i.e. you know you're instantiating something but don't know what that thing is), though that does require that all the types you handle require the same amount of arguments for their constructor. It may or may not apply to C++ in particular, but it definitely applies to higher-level languages. For more complex initialisation such as the non-zero refined type case, I think static factory functions are reasonable if you have support for nullable types. Just return a NonZeroU8? from one, and a NonZeroU8 from the other. I do agree with many of the points you make, I just don't think they're inherent flaws of the constructor method, just of the way constructors work in C++ specifically. For instance, you could make a guarantee that in the constructor, any field of class A that has type T will have type T? instead until you assign it a value. And if by the end there are paths where not all fields are set, that's a compiler error because you didn't instantiate your object correctly. The type checker should be able to similarly reason about how fields are accessed in methods that you call. If it's just a setter, go ahead. You can treat it as though it accepts a type that has nullable fields of which the class you defined is a refined type. So long as the type-checker determines the method can work with this implicitly defined superset of your class, you're allowed to call it. Most of the other issues come down to a combination of syntax and language semantics, but none of them are flaws with what a constructor method does at its core.

Yep, it makes a lot of sense I like that pattern. I will try it. I think I have actually already seen it several times within the standard library

I was thinking if another issue, at least in c++. Even if you initialise your NonZeroU8 properly, there no protection from setting the member “value” to zero afterwards. You would need a getter, or cast operations, since there is no such thing as read-only fields in c++

As always, your videos are absolutely fantastic. I can’t get enough.

the curly brackets in the C++ constructor are pretty nice to do some quick math with passed in arguments to put a create a value for another struct variable. Instead of creating an instance and then calling an init function you can just create an instance and some base initializing will be done.

Great insight and explanations as always

A few notes: 1. I'm a bit disappointed, that you didn't go into templates and meta-programming. Especially the NonZeroU8 case is a perfect example where templates can emulate a more complex compile time type system. (even though the syntax makes you want to hurt someone) 2. The private struct solution is a pattern many code bases already use especially for dynamically linked libraries to isolate the struct layout from the library user called "private implementation" (PIMPL) but it always annoyed me how you either need a pointer indirection or get rid of the C++ type system and resort to basic C-style OOP to make it work without it. 3. A CS teacher once told me "any design pattern is just a work around for the deficiencies of the language of choice". This video perfectly illustrates that statement! 4. Making unchecked_new "safer" in C++ is possible with "friend classes" but that is a giant mess in and of itself.

beautiful! thanks for making this!

10:16 if rust enforce the invariant thru UB (no one can stop u from passing 0, but nothing is guaranteed if we do so), we could do the same in c++, tho? like this: if(x != 0) { NonZeroU8 res; res.value = x; return res; } // Nothing here afterwards. Not even a return statement. If 0 is passed, it’s UB since we don’t return It actually works (everything is optimized as if the x is never 0), except the memory layout is not enforced. We can use std::unreachable in c++ 23 to explicitly cause UB also

I always lean towards a static factory creation, usually returning a smart pointer for my C++ creation; I can vouch for this working and being absolutely the way to go. Making my constructors private, adding helper utilities, which you can then control access to the constructors via friendship has solved a lot of headaches for several projects my end. Especially when writing code which is to be used by others, preventing willy nilly stack allocation is really rather good, and though you say "factory" and you get glared at, I absolutely agree with the sentiments in this video.

You could get your constructors back once you aggregated all of your fields. Then the constructor could simply be this: 'CString() : m(CString::create()) {}' or this 'CString(const char* in) : m(CString::create(in)) {}'. This is actually very efficient thanks to NRVO. You also might want to replace the construct() methods with lambdas to have all the code right there.

9:22 if you know x is not zero you can do `if(!x)__builtin_unreachable();` before calling constructor. This will tell compiler that x=0 is not possible.

My favorite channel on RU-vid. Another great upload 👍🏻

Very interesting video, thanks! Note that the first big general-purpose OOP language was very OOP, in that classes were actually object instances (whose supertype was "Class", which was also an object instance), and the only way to allocate an object was to call a factory function on the class object. So "Point.new()" [not the right syntax] was invoking the new function on the object stored in the global variable Point. Anyone who wants to learn more about invariants (and pre- and post-conditions) should check out Meyer's tome "Object-Oriented Software Construction", which you can get as a PDF floating around since he gave away PDF copies with his compiler. It's an interesting delve into how programming languages are designed. Like, what's the mathematical reasoning behind the various higher-level structures. Very handy concepts that have oozed into other programming languages, even if you're not writing OOP programs. For example, in Meyer's language, the constructor would have a precondition that the argument passed in isn't zero, and an invariant that the value inside the object isn't zero. That's part of the type signature, so you know that's the requirement. If the requirement is more complex (e.g., an array of bytes contains valid UTF-8) then a non-failing function has to be provided so you can check it. Then the constructor relies on the precondition being met, and if it isn't an exception is thrown in the caller which you cannot catch and continue on from (but you can retry, in a sense), and the top of the exception stack traceback is the caller and not the non-zero-constructor code. Just as an idea of a different way of handling it. His whole exception thing is so much cleaner than other languages.

I love how the best solution to C++'s unergonomic initialization is to make a C struct. 😂

after learning all of c++'s initialization rules i didn't realize it was such a horrible nightmare... and for no justifiable reason. most of the complexity comes from backwards compatibility and lack of foresight.

Access modifiers are there to protect the programmers, it's not hardware level protected or anything. Like if I know where the instance of an object is stored in memory, I can just jump to it and change to whatever I want.

Your argument at 8:52 is broken by "there's a way to do it (exceptions), but i don't like it, so it doesn't exist, see, (my partial version of) C++ is broken". Well if you don't like it as it is, fine, but that's not a useful argument. Also at 10:35, WHY do you even make a create_unchecked function ? For the sake to explain "oh no, we can't know if it's unchecked, C++ is broken" ??? If it is necessary for speed you have the EXACT same problem in rust (sure you can grep it with unsafe...). You could instead have put a reinterpret_cast(u8) everywhere speed is required to do exactly that, and it would do the job you want. Your point at 12:30 is valid and a real problem. Interesting discussion overall 🙂

I noticed a similar issue in C# in some UTs where two-step initialization is kinda forced upon and bim, what you said would happen, did: Stuff was accessed before it was initialized and, worse, it didn't crash. It was happily null and creating really hard to find bug

15:55 "There is no problem that can't be solved with additional layers of abstraction (other than having too many layers of abstraction)". All in all I felt throughout the video that the problem you are presenting a solution to is significantly exaggerated, but if it bothers you so much, I can't argue that it's not a real problem. But not for me (I have over 10 years of commercial C++ experience, FWIW).

Around 11:40: Personally, I would use a delegating constructor for CString: add a second constructor taking a pointer and length, and have the first delegate to the second passing the result of calling strlen.

The exception in the constructor would solve everything also. But as you said, it would mandate a try - catch somewhere to avoid issues with it. optional makes it possible to solve it in modern c++.

C++ and Haskell are the best

i use boost outcome + 3 phase initialization. sure C++ don't have unsafe keyword but that's good enough for me. I don't think most C++ programmers need hand holding while writing a constructor, "spaces" between lines of code in constructor sound like a trivial problem, because constructor should be as simple as possible, if someone write 50 lines of code in constructor that would be smelly to me. May be i haven't wrote that kind of constructor, or work in a team like you but i think it is fine for me for now. Very nice video. i like it.

I think this is a really interesting idea, and a valid C++ criticism. The throwing constructor is a huge concern in a lot of places.

Awesome video, I really like how clearly you explain and compare things. I would love to hear more, especially a Rust tutorial for C++ developers. Some concept in Rust are just so alien to me I can't grasp this language properly (like how would you control a global list of objects for some important thing in project well).

iirc from a c++ weekly video that constructors are just converters (casts). You can't even take the address of constructors, much like destructors. Hence, without the explicit keyword, the constructor is used implicitly, much like how casts are done implicitly. The (old) constructor syntax (S s = S(42);) also comes from the syntax for C-style casts (float f = float(42);), so it's not designed to be for constructors (well the brace initialization S s{42}; or S s = S{42}; kinda make sense though, but it's newer). Therefore, constructors in C++ began simply as a glorified custom cast, and since this does not change as the language move forwards, constructors, which could only get some temporary patches and fixes (like the brace initialization syntax), remain broken. btw the pattern/paradigm in 16:42 is kinda genius ngl

You don't mention if you were aware of it, but Josh Bloch talks about this same thing (as _static factory methods_ ) in _Effective Java._ He gives a lot of the same reasons for it, even though Java has strong guarantees about not letting you operate on an uninitialized object and cleanup on creation failure.

Used to hate writing factory code whenever I could cause it felt ugly. Though I write rust now this video gave me a new perspective and I will try to use them as much as possible in the future.

Great video, especially the talk about half-initialized instances, this is something that should have been solved ages ago by the standard. One thing is bugging me about exceptions though. You mention that they are extremely expensive. This used to be the case, but in most modern compilers, the cost of exception handling should be basically null unless an exception is actually thrown, in which case yes, exceptions are more costly than checking the return value (mostly due to the handler being store in cold memory). I used to rely on exceptions as my sole error-handling mechanism. Since moving to rust as my main programming language, when I go back to C++, I do rely less often on exceptions, but not because of performance concerns, I simply want to force users of my API to reason about error handling with std::expected or std::optional (including explicitly saying "I want an expection if the value is not valid"). I think in some cases exceptions might still be slower than checking the return value because of easier optimizations (including calling std::unreachable in the "failure" branch of the error checking), but I have no data about this.

Great video, and I thought your perspective was very interesting l! Keep at it!

Super solid video!

I'm glad I'm not the only one disillusioned with traditional 'seemingly infallible' constructors. Factory functions are a much better way to do this.

Great video, as always.

This is the best video on the subject by far

I think that there are good reasons to criticize c++ but in case of NonZeroU8 it’s not the case in my opinion. Example: In c++ you can easily create the same NonZeroU8 using std::optional, private constructor and static std::optional NonZeroU8::new(u8 x). #include using u8 = unsigned char; using opt_u8 = std::optional; class NonZeroU8 { u8 val; explicit NonZeroU8(u8 x) : val(x) {} public: static opt_u8 NonZeroU8(u8 x) { If(x != 0) { return NonZeroU8(x); } return std::nullopt; }; It’s important to say that there’s the doom of backwards compatibility that makes thigs pretty annoying but the c++ standard is trying to make sensible changes to improve safety and simplicity of the language. For example in c++ 23 there is a strong notion to use std::excepted instead of exceptions to maintain safety with minimal overhead.

Great video as always! Small correction at 2:38 (and following slides): It is not valid to add a comma after Default::default() (or any value).

7:45 Edit below I'm very ignorant of Rust. But this confuses me beyond what I expect. Why are we branching if the type level knowledge of the nonzerou8 not being valid if it's 0 exists? You said 0 can represent none in this type. Why isn't this factory just 'return x' after compilation? Why is there a branch in the compiler output? Whenever you check/extract the some out of your option it must check x == 0 unless it can figure out x isn't 0 of course. Maybe it's that branch you're eliminating instead. But it's very confusing to have the factory up on screen and pointing to it while you're actually talking about eliminating the check in option. What's described doesn't follow the types as written in the code (after the factory you'll have an option, not a nonzerou8). Perhaps this is a feature of Rust I don't know about. Edit: So I let this sit in my brain for a while. Now it makes perfect sense again. It's still confusing to look at, the description in the video wasn't what I expected for this. But obviously if I looked at the return types at 8:09 the unsafe doesn't return the option type. What made me fail to understand was that we had just talked about how the none state can be represented by 0. I thought that was relevant. It's completely irrelevant. It's an unrelated tangent that's important (wouldn't want to make a u8 fatter), just not relevant to the rest of the video. What's relevant is that the unsafe function doesn't ever make an option and garauntees (within the contract given to the caller of course) that the u8 isn't zero.

Video of golden quality, thanks

Awesome video, thank you!

What the hell, this is so good! Moving from C++ to C#, I've never been so confident about initialization as with your Rust code. So atomic and safe!

I dislike sometimes how tightly OOP type things naturally couple lifetime into things. It's nice to use allocators (mainly arena allocators) to get a block and use a factory/c-style init function to fill in a pod struct into some aligned offset into the allocator's big block of memory. People teaching c++ will squak it has to be impossible to have invalid data but sometimes you just have to accept the responsibility. By dodging the construction, you can dodge the destruction. Just reset the allocator (that invalidates all structs placed in it) and go again for a new frame or hot loop iteration. I think c++ gets a lot better when you stop forcing everything to tangle data, lifetime, and functions into a class. Data, functions, and memory allocation can be handled seperately.

It's a neat idea, but I don't see how you can make it work in practice unfortunately: That static factory function returns an `std::optional`, this is all well and good (I don't see what better type to return without exceptions), but you'd like to get rid of that optional wrapper once you've made sure that optional contains a proper `T` and not `std::nullopt`. That means either copy-constructing or move-constructing a new `T` from the `T` inside that optional. Copying will likely be either inefficient or even incorrect if `T` is noncopyable (e.g. if `T` is a wrapper around a file descriptor). Which means we need to be able to move-construct a `T`, so an object of type `T` can be in an empty moved-from state, that is, one of those unusable states we intended to avoid being representable by using that factory method over the constructor in the first place. It'd have worked with a destructive move, but we don't have that. Bummer. That means you'd be doomed to drag that extra `std::optional` everywhere which kinda defeats the point of having all objects of type `T` always being valid since they're now replaced by `std::optional` (which can be invalid by definition). At best, you now know that if you pass a `T&` or `const T&`, you know it's a valid object (well, unless that reference is somehow dangling, but that would be unrecoverable anyway). Still the caller will have to work with an `std::optional` instead of a `T` and either ignore nullopt checks (i.e. "trust me, I know this optional contains something") or add extra unneeded checks everywhere (slight performance loss, less readable code). Still, interesting comparison.

Why can't you use an aggregate initialiser without a member struct?

One thing about Cstring class for C++: Is a valid way of solving that problem not to push the responsibility of finding out the string length from the constructor to the callee, and pass it as a parameter? The isAscii function could be ran on the inputted pointer too, and then you should be able to get the invariant statement straight from valid arguments.

I don't know C++, so please correct me if I'm wrong. In the CString example, why can't we use a private (unsafe) constructor that takes in all the fields, and use it instead of a nested struct (`M` in this example). ``` class CString { unique_pointer buf; int len; bool is_ascii; explicit CString(unique_pointer buf, int len, bool is_ascii) : buf(buf) , len(len) , is_ascii(is_ascii) {} public: static auto create(const char* in) { const auto len = ...; auto buf = ...; const auto is_ascii = ...; CString result (buf, len, is_ascii); return result; } } ``` PS. I really liked the language logo in the bottom right!

Interesting content, thanks

learning c++ as a grad student I thought it was cool to know these easter eggs and irrational behaviors that could vary depending on the machine and compiler 😂 now I realise it's basically putting up with someone else's 💩

10/10 video thank you for your contributions 🫡

How does the nested structure way of holding member data play with inheritance? So far I've noticed it doesn't really.

13:56 I vividly remember dealing with uninitialized vtable when I was working in Chromium

15:51 I like how U come to inner struct model from safety reasons. I'm using it, because it looks nice in the long run (it states the layout in one place, sagesting that next 10+ lines don't). And it can shorten Ur code, when U have a lot of overloaded operators. But "m" is just ugly, use "mem" at lest. For example, I'm using "data", but l'm not rigid on this.

I've actually started doing this in javascript myself

I really love your videos

I only know a bit of Rust and no C++, but each time I'm watching you talk about C++, I appreciate how many footguns Rust avoids which I don't have to worry about. Each one is only tiny thing to think about, but in aggregate it's the difference between painful worrying and painless comfort.

To be fair the problems with struct padding and the order/performance of the code is not solved, it's just hidden away or there are compromises made, which you can't control. I think if you need control of such small details, writing code that has to be correct is a decent tradeoff

This is a great video! I'm definitely going to send it to some colleagues of mine to check out.

16:10 I don't really understand why the helper struct is needed here.

[0:47 thanks for mentioning us - the neither ones too (:

In an older more imperative language such as C++ doing things this way would probably mean overhead as the code dictates that you first declare the variables, reserving memory, then operate on them and then copy them by value to the struct memory when constructing the object. I assume Rust is smart enough to see that a variable will be directly used to initialise an object later in the function and places it in the destination address straight away. Which is what the C++ thing with an output pointer pointing to a partially initialised object is doing very explicitly, as C[++] does. Though I guess probably nothing in the C++ spec (besides the actual current constructor rules) prevents the compiler from doing the same when noticing a function returns an object and sneakily allocating the declared variables exactly where it knows it will place the object? Or maybe I'm wrong and they've been doing that for a long time?

8:24 this is a VERY good point. the fact that you can explicitly go out of your way to do something in an "unsafe" manner, but then be able to EASILY track down when you have done this is a VERY powerful tool you can have, that also isnt babying and distrusting of the user / developer, which is a pretty pervasive culture that i highly dislike. with this, though, you not only make safer and more robust code but you also lack this inherent distrust of the developer

Great video as always thanks

Can't type constraints/concepts be used to enforce x != 0?