Great video(s), as always! A few thoughts... 1) Maybe briefly talk about the differences of struct (stack allocated) vs. class (ref, heap allocated) w.r.t. other languages, which use these `keywords` (e.g., C#, D, etc.) (?) 2) What is the rational of using `k*` for ([k]onstante) variables? This is the old-school Hungarian notation... 3) You can spare yourself a few key strokes at the end of the `main` function: no need to add `return 0;`. This is not mandated by the C++ standard. 4) You went from data-oriented programming (very efficient) to object-oriented programming ;) 5) I like that you append an underscore for member variables, and not prepend them (a bit more problematic w.r.t. the C++ standard)
Thanks for your comment! Let me address your points here briefly: 1) I think you're confusing something here. Struct and class do _exactly_ the same thing in C++ with just one difference that I mention towards the end of the video. There is no connection to being heap or stack allocated. We can allocate objects of our structs and classes on heap and stack depending on how we create these objects. That being said, we can implement the internals of both classes or structs to be allocated on the stack or on the heap. That being said, we _will_ talk about stack and heap allocation later. For now everything that we have discussed has been allocated on the stack (unless it's smth like a vector which allocates on a heap internally). As for the connection to other languages, I don't think I'll do this as this is mostly a course of C++ and I'm building it up so that if one watches the playlist in order, one always has enough knowledge for the next video. I don't assume people will know other programming languages here. I might add that as a separate discussion video after the whole course is spelled out. 2) The rationale comes from following the suggestion of the Google Style: google.github.io/styleguide/cppguide.html#Constant_Names. While I agree that Hungarian notation is outdated when we're talking about things that can be inferred directly from the type of the variable, we still have some benefit in it in the areas where we represent the semantic information. Here, the kSomeConstant and some_constant have a different meaning: kSomeConstant maintains its value for the duration of the program, while some_constant is probably scope-local. Does this make sense? 3) That's true. However, I'm just used to this and it does not hurt. 🤷 4) I think that "not yet" 😉Let me explain what I mean. We are still just learning how to bundle data together. The data and object-oriented programming are much more high level concepts, while here we're just talking about the mechanics of the language. We still could use structs and classes in data-oriented programming (e.g. for convenient views of our data). That being said, both object-oriented and data-oriented (just as functional) styles have their own strong and weak points. I plan to talk about it towards the end of the course once we have all the technical machinery in check. 5) Again, this comes from the Google C++ style guide: google.github.io/styleguide/cppguide.html#Variable_Names
@@CodeForYourself Fully agree on almost everything you said ;) I'm aware about the differences of struct / class in C++ (public vs. private by default). What I meant was addressing the difference for people coming from other languages where this is important. But I understand that you want to keep your course as focused as possible. Keep up the good work, and please excuse my nitpickin' ...
@@CodeForYourself damn, it's like I know your thoughts😂. The first time was on the CMake video where I spoke about GoogleTest and you said that this was what you'd be coming up with next and now, Design Patterns 😅. Fascinating👌🏽 Thank you 🙌🏽 Greetings from Germany.
I wouldn’t bother. It’s really not such a big deal. One usually needs those flags only to figure out some weird thing happening. Once you see the linker errors you know you forgot the -c flag 😁
This is more complex than it should be really, but in this case if a variable represents an index into a vector it should be a size_t as that's the type vector expects for its index. The other variables could be any type really 🤷♂️
@@CodeForYourself the man page in my terminal says that malloc() takes size_t for the count too. Here's an example where your index rule isn't well respected. I understand that size_t is just a typedef, however is there a general recommendation? I mean can I setup a linter or something which can do the complaining and cognitive load here?
There is a warning that will trigger of you try to use a signed type where an unsigned one is needed but other that we're on our own to pick the correct type. It all comes after a widely regarded mishap of using unsigned types for indices in the standard library so now we're stuck with this. 🤷♂️
Your guideline about using structs vs. classes is not fully correct in my opinion. You said that if you have at least one method you should use class. I think this guideline should be refined to: If you have at least one non-const method you should use a class. It is totally fine to have structs with const methods (i.e. observer methods). A trivial example of this is a struct Vector2D which has 2 members (x and y) and you can add const methods angle() and length() without introducing any class invariants, which means you don't need to change the struct to a class. As for everything else, great explanation. I fully agree with what you've said in the video. And I like that you're explaining these topics in a simple way for everyone to understand (without using words like "invariant", "trivially constructible", etc.)
I definitely see your point about structs and const methods. You are absolutely right from a technical point of view. However, I still like the simple rule I mentioned in the video as it is very simple to explain and remember and doesn't hurt. In my experience it is very helpful to have simple rules to follow and remove the "thinking" from the decision making as much as possible if this makes any sense 😉 And thanks for your compliments! 🙏
I'm missing the function Move in some parts of this video, but I hope you get the gist 😜 Please comment below with any suggestions or comments!
Thank you for effort and time.
Lost track following the course for sometime.
I am back now 🙂.
Welcome back! 😉
Great video(s), as always! A few thoughts...
1) Maybe briefly talk about the differences of struct (stack allocated) vs. class (ref, heap allocated) w.r.t. other languages, which use these `keywords` (e.g., C#, D, etc.) (?)
2) What is the rational of using `k*` for ([k]onstante) variables? This is the old-school Hungarian notation...
3) You can spare yourself a few key strokes at the end of the `main` function: no need to add `return 0;`. This is not mandated by the C++ standard.
4) You went from data-oriented programming (very efficient) to object-oriented programming ;)
5) I like that you append an underscore for member variables, and not prepend them (a bit more problematic w.r.t. the C++ standard)
Thanks for your comment! Let me address your points here briefly:
1) I think you're confusing something here. Struct and class do _exactly_ the same thing in C++ with just one difference that I mention towards the end of the video. There is no connection to being heap or stack allocated. We can allocate objects of our structs and classes on heap and stack depending on how we create these objects. That being said, we can implement the internals of both classes or structs to be allocated on the stack or on the heap. That being said, we _will_ talk about stack and heap allocation later. For now everything that we have discussed has been allocated on the stack (unless it's smth like a vector which allocates on a heap internally). As for the connection to other languages, I don't think I'll do this as this is mostly a course of C++ and I'm building it up so that if one watches the playlist in order, one always has enough knowledge for the next video. I don't assume people will know other programming languages here. I might add that as a separate discussion video after the whole course is spelled out.
2) The rationale comes from following the suggestion of the Google Style: google.github.io/styleguide/cppguide.html#Constant_Names. While I agree that Hungarian notation is outdated when we're talking about things that can be inferred directly from the type of the variable, we still have some benefit in it in the areas where we represent the semantic information. Here, the kSomeConstant and some_constant have a different meaning: kSomeConstant maintains its value for the duration of the program, while some_constant is probably scope-local. Does this make sense?
3) That's true. However, I'm just used to this and it does not hurt. 🤷
4) I think that "not yet" 😉Let me explain what I mean. We are still just learning how to bundle data together. The data and object-oriented programming are much more high level concepts, while here we're just talking about the mechanics of the language. We still could use structs and classes in data-oriented programming (e.g. for convenient views of our data). That being said, both object-oriented and data-oriented (just as functional) styles have their own strong and weak points. I plan to talk about it towards the end of the course once we have all the technical machinery in check.
5) Again, this comes from the Google C++ style guide: google.github.io/styleguide/cppguide.html#Variable_Names
@@CodeForYourself Fully agree on almost everything you said ;) I'm aware about the differences of struct / class in C++ (public vs. private by default). What I meant was addressing the difference for people coming from other languages where this is important. But I understand that you want to keep your course as focused as possible. Keep up the good work, and please excuse my nitpickin' ...
@@bsdooby no worries at all! Thanks for spending time to improve what I do! 🙏
@@CodeForYourself Appreciate what you do!
BTW: Would you be interested in giving a talk @ Bern University of Applied Sciences? Should you be, you can DM me on the bird (or reply here).
Another great video.
Igor, do you, by any chance, think about creating a course on Design Patterns in C++? Hahah
Thanks.
They will be part of this course pretty soon 😉 right after we finish classes!
@@CodeForYourself damn, it's like I know your thoughts😂. The first time was on the CMake video where I spoke about GoogleTest and you said that this was what you'd be coming up with next and now, Design Patterns 😅.
Fascinating👌🏽
Thank you 🙌🏽
Greetings from Germany.
Hi, I seem to forget small details like flags -c to not use linker etc. How to remember them?
I wouldn’t bother. It’s really not such a big deal. One usually needs those flags only to figure out some weird thing happening. Once you see the linker errors you know you forgot the -c flag 😁
Helped a lot
How do you decide when to use size_t vs int ?
This is more complex than it should be really, but in this case if a variable represents an index into a vector it should be a size_t as that's the type vector expects for its index. The other variables could be any type really 🤷♂️
@@CodeForYourself the man page in my terminal says that malloc() takes size_t for the count too. Here's an example where your index rule isn't well respected. I understand that size_t is just a typedef, however is there a general recommendation?
I mean can I setup a linter or something which can do the complaining and cognitive load here?
There is a warning that will trigger of you try to use a signed type where an unsigned one is needed but other that we're on our own to pick the correct type. It all comes after a widely regarded mishap of using unsigned types for indices in the standard library so now we're stuck with this. 🤷♂️
Your guideline about using structs vs. classes is not fully correct in my opinion.
You said that if you have at least one method you should use class.
I think this guideline should be refined to: If you have at least one non-const method you should use a class.
It is totally fine to have structs with const methods (i.e. observer methods).
A trivial example of this is a struct Vector2D which has 2 members (x and y) and you can add const methods angle() and length() without introducing any class invariants, which means you don't need to change the struct to a class.
As for everything else, great explanation. I fully agree with what you've said in the video. And I like that you're explaining these topics in a simple way for everyone to understand (without using words like "invariant", "trivially constructible", etc.)
I definitely see your point about structs and const methods. You are absolutely right from a technical point of view. However, I still like the simple rule I mentioned in the video as it is very simple to explain and remember and doesn't hurt. In my experience it is very helpful to have simple rules to follow and remove the "thinking" from the decision making as much as possible if this makes any sense 😉
And thanks for your compliments! 🙏
Thought this was a Typescript tutorial, perhaps some more elaborate thumbnail or title would be better.
\
Thanks for this feedback! That might explain the low view count 🤔