WEBVTT 1 00:00:00.120 --> 00:00:02.799 Welcome to the deep dive. You know, for a lot 2 00:00:02.799 --> 00:00:06.240 of people, C plus plus has this reputation maybe a 3 00:00:06.240 --> 00:00:09.960 bit intimidating, right, like this super powerful tool that's also 4 00:00:10.400 --> 00:00:11.560 well kind of complex. 5 00:00:11.919 --> 00:00:14.720 It definitely has that aura sometimes. But the reality is 6 00:00:14.919 --> 00:00:17.600 this isn't some dusty old language. 7 00:00:17.280 --> 00:00:22.079 No exactly, it's constantly evolving, getting smarter really for today's challenges. 8 00:00:22.160 --> 00:00:26.839 Absolutely, it's vibrant, it's living, built on this rock solid foundation. 9 00:00:27.399 --> 00:00:30.640 And for this deep dive, we're cracking open professional C 10 00:00:30.960 --> 00:00:33.560 plus plus. Think of it like our treasure. 11 00:00:33.240 --> 00:00:35.799 Map, and where are the guides pointing out the gold? 12 00:00:36.280 --> 00:00:38.280 Specifically for you, the learner. 13 00:00:38.119 --> 00:00:41.520 That's the plant. We're pulling out the essentials about modern 14 00:00:41.560 --> 00:00:43.679 C plus plus from this material. 15 00:00:43.359 --> 00:00:45.759 Yeah, tracing its journey right from the beginnings to the 16 00:00:45.799 --> 00:00:49.000 latest features, navigating that big standard library. 17 00:00:49.119 --> 00:00:51.359 Consider this your express route. We want you to get 18 00:00:51.359 --> 00:00:54.679 what's significant, what's exciting and C plus plus but without 19 00:00:54.719 --> 00:00:56.039 getting totally bogged down. 20 00:00:56.079 --> 00:00:59.560 We're hunting for those aha moments, the practical stuff you 21 00:00:59.560 --> 00:01:00.399 can actually use. 22 00:01:00.439 --> 00:01:02.560 Okay, so let's kick off with just how much C 23 00:01:02.679 --> 00:01:05.719 plus plus has grown. It's pretty striking. Ah So, well, 24 00:01:05.760 --> 00:01:07.879 you look at the C twenty three standard speck it's 25 00:01:08.040 --> 00:01:11.400 what under eight hundred pages pretty lean? Okay, Then you 26 00:01:11.439 --> 00:01:15.280 look at C plus plus twenty three over two thousand pages. 27 00:01:15.359 --> 00:01:16.640 Whoa, that's a lot more. 28 00:01:16.719 --> 00:01:20.560 It's not just pages, right, It shows this massive expansion 29 00:01:20.760 --> 00:01:24.159 in what C plus plus can do. Features piled on features, 30 00:01:24.719 --> 00:01:27.000 it really cements it as a true superset of C. 31 00:01:27.280 --> 00:01:29.760 Okay, let's unpack that. The story is C plus plus 32 00:01:29.840 --> 00:01:31.920 started as C with classes. 33 00:01:31.640 --> 00:01:34.439 More or less, that was the kernel. Yeah, brings C's 34 00:01:34.519 --> 00:01:37.159 power together with object oriented thinking. 35 00:01:37.040 --> 00:01:39.000 And it sounds like it's been on a constant growth spurt, 36 00:01:39.040 --> 00:01:41.719 evers men's fixing some of C's old issues along the way. 37 00:01:41.760 --> 00:01:45.000 Precisely, there's share history, some familiar syntax if you know C, 38 00:01:45.560 --> 00:01:49.319 but the paths have really diverged, and they keep diverging, 39 00:01:49.519 --> 00:01:52.599 which means even if you know C or Java or 40 00:01:52.640 --> 00:01:55.439 C sharp, maybe even praython, you've got to stay aware. 41 00:01:55.760 --> 00:01:58.359 Modern C plus plus has its own unique syntax, new 42 00:01:58.359 --> 00:02:01.560 features popping up all the time, always something new, right. 43 00:02:01.439 --> 00:02:04.319 Which leads is perfectly into exploring some of those modern features. 44 00:02:04.319 --> 00:02:06.879 That new syntax. Now, I saw something about needing a 45 00:02:06.879 --> 00:02:09.479 special compiler switch to even use the latest stuff. 46 00:02:09.800 --> 00:02:13.560 Ah. Yes, if you're using GCC the compiler, you'll likely 47 00:02:13.599 --> 00:02:15.879 need STDC plus plus two B. 48 00:02:15.879 --> 00:02:17.560 C plus plus two B. 49 00:02:17.479 --> 00:02:20.319 Yeah, that's the flag right now to unlock C plus 50 00:02:20.319 --> 00:02:23.840 plus twenty three features. It'll probably become STDC plus plus 51 00:02:23.840 --> 00:02:27.319 twenty three eventually once things are fully finalized, but for now, 52 00:02:27.639 --> 00:02:29.120 that's your key to the cutting edge. 53 00:02:29.479 --> 00:02:32.400 Interesting, and one of those cutting edge things seems to 54 00:02:32.439 --> 00:02:34.560 be how we even bring in the standard library. 55 00:02:34.599 --> 00:02:38.199 Something about modules, Yeah, that's a pretty fundamental shift. C 56 00:02:38.319 --> 00:02:41.400 plus plus twenty three introduces this idea of a standard 57 00:02:41.560 --> 00:02:43.560 named module. It's just called std. 58 00:02:43.759 --> 00:02:44.080 Okay. 59 00:02:44.120 --> 00:02:46.759 The long term goal is you'll just write import std 60 00:02:47.039 --> 00:02:50.120 and boom, you get the whole standard library, much cleaner, 61 00:02:50.400 --> 00:02:52.919 more efficient than the old hashtag include way. 62 00:02:53.080 --> 00:02:55.039 Sounds great, but. 63 00:02:55.000 --> 00:02:59.080 Compiler support for that single STD module is still well, it's. 64 00:02:58.960 --> 00:03:01.159 Early days, ah so for now. 65 00:03:01.240 --> 00:03:03.479 For now, you'll probably still need to import individual bits, 66 00:03:03.520 --> 00:03:05.240 like if you want the new print functions, you do 67 00:03:05.360 --> 00:03:06.039 import print. 68 00:03:06.240 --> 00:03:09.280 Notice the difference. No angle brackets for the main module 69 00:03:09.319 --> 00:03:14.520 import std, but you use them for specific headers import print. 70 00:03:14.800 --> 00:03:18.080 Got it. So moving towards cleaner imports, but we're not 71 00:03:18.159 --> 00:03:20.639 quite there yet. It's still a bit like hashtag include, 72 00:03:20.680 --> 00:03:22.080 but with import. 73 00:03:21.840 --> 00:03:25.000 Pretty much for the time being. Okay, now the real 74 00:03:25.080 --> 00:03:31.000 basics numbers, characters, int, double char, has anything changed in how. 75 00:03:30.879 --> 00:03:34.520 We declare those The types themselves, the fundamental ones are 76 00:03:34.520 --> 00:03:38.360 the same, but how you initialize them. Modern C plus 77 00:03:38.400 --> 00:03:42.919 plus really pushes for uniform initialization using curly braces, so. 78 00:03:42.919 --> 00:03:46.759 Like int ii eleven instead of into ee eleven exactly. 79 00:03:47.000 --> 00:03:50.000 And the nice thing is that syntax works consistently everywhere 80 00:03:50.240 --> 00:03:52.599 for all types and all sorts of situations. It helps 81 00:03:52.639 --> 00:03:54.560 avoid some old weird ambiguities. 82 00:03:54.719 --> 00:03:56.080 Makes sense. Consistency is good. 83 00:03:56.319 --> 00:03:59.039 And we also have newer character types like chart char sixteenth, 84 00:03:59.120 --> 00:04:03.840 chart thirty two. Handling different unicode encodings properly super important Nowadays. 85 00:04:03.479 --> 00:04:07.039 Bedifort initialization sounds more predictable, easier to read. Now I 86 00:04:07.080 --> 00:04:10.039 saw some other let's say, unusual syntax, something with double 87 00:04:10.080 --> 00:04:11.879 square brackets. Fall through. 88 00:04:12.120 --> 00:04:14.560 Yes, fall through, that's an attribute you use it inside 89 00:04:14.560 --> 00:04:17.360 switch statements. Okay, well, you know how in C plus 90 00:04:17.399 --> 00:04:19.439 plus C if you forget a break in a case, 91 00:04:19.920 --> 00:04:21.839 execution just falls through to the next one. 92 00:04:22.000 --> 00:04:23.920 Yeah, that can cause nasty bugs. 93 00:04:23.839 --> 00:04:26.439 Right, but sometimes you want it to fall through, so 94 00:04:26.600 --> 00:04:29.800 fall through is like putting up a big sign saying, compiler, 95 00:04:29.920 --> 00:04:33.199 I meant to do this, no bug here makes the 96 00:04:33.199 --> 00:04:34.240 intent super clear. 97 00:04:34.519 --> 00:04:37.759 Oh okay. Explicitly saying I know there's no break and 98 00:04:37.800 --> 00:04:41.399 that's okay makes sense for clarity. What about I think 99 00:04:41.399 --> 00:04:43.279 they called it this spaceship operator. 100 00:04:44.319 --> 00:04:47.879 That's weird, the spaceship operator. Officially, it's the three way 101 00:04:47.879 --> 00:04:49.720 comparison operator. It's fantastic. 102 00:04:49.800 --> 00:04:50.199 Why is that? 103 00:04:50.720 --> 00:04:54.759 Because it does all six comparisons less than, greater than, 104 00:04:54.920 --> 00:04:57.519 equal to, not equal to, less greater than or equal 105 00:04:57.600 --> 00:05:00.360 all in one go. Really, how it returned turns a 106 00:05:00.360 --> 00:05:04.079 special result, often a type like strong ordering. The value 107 00:05:04.079 --> 00:05:06.199 tells you if the first thing is less, greater or 108 00:05:06.240 --> 00:05:09.360 equal to the second, okay, And it's smart for things 109 00:05:09.399 --> 00:05:13.199 like floating point numbers where you have magnan not a number. 110 00:05:13.160 --> 00:05:15.680 Which isn't really lesser greater than anything exactly. 111 00:05:16.000 --> 00:05:18.920 The spaceship operator can return a partial ordering for those 112 00:05:19.079 --> 00:05:22.120 acknowledging they aren't strictly comparable. It's a game changer for 113 00:05:22.160 --> 00:05:26.600 writing generic comparisons. Plus, the compiler can often autogenerate all 114 00:05:26.600 --> 00:05:29.720 six comparison operators for you if you define just this 115 00:05:29.759 --> 00:05:32.519 one less code fewer mistakes. 116 00:05:32.800 --> 00:05:37.160 Wow, okay, one operator all the info even handles trippy 117 00:05:37.199 --> 00:05:41.360 stuff like nan powerful now functions. I saw a note 118 00:05:41.360 --> 00:05:44.000 about empty parameter lists. Any change there. 119 00:05:44.160 --> 00:05:47.160 Yeah, small simplification in C plus plus A if a 120 00:05:47.199 --> 00:05:51.439 function takes no parameters, just use empty parentheses void my function. 121 00:05:51.639 --> 00:05:54.000 No need for void inside the parentheses like in some 122 00:05:54.079 --> 00:05:55.000 older SEA styles. 123 00:05:55.079 --> 00:05:58.399 Nope, not needed. But crucially you still must use void 124 00:05:58.399 --> 00:06:00.720 for the return type if the function doesn't return any thing. 125 00:06:00.879 --> 00:06:04.439 Got it empty for no input, void return for no output. 126 00:06:04.720 --> 00:06:07.000 Simple enough? What about text? We still stuck with those 127 00:06:07.000 --> 00:06:08.920 tricky C style character arrays? 128 00:06:09.040 --> 00:06:12.639 Thankfully no. Modern C plus plus gives us STD dot string. 129 00:06:12.680 --> 00:06:14.600 You get it from the string header and that's better 130 00:06:14.680 --> 00:06:18.160 because oh it's miles better, easier, safer. You can assign text, 131 00:06:18.279 --> 00:06:22.079 join strings, access characters easily, all without the manual memory 132 00:06:22.120 --> 00:06:25.279 management headaches of char It basically EXE a built in type. 133 00:06:25.279 --> 00:06:30.240 Now anyone who's undered a null terminator bug will appreciate that. Yeah, okay, 134 00:06:30.319 --> 00:06:33.040 so C plus plus is clearly more than just a 135 00:06:33.040 --> 00:06:37.360 better see it's properly object oriented. Quick refresher, what's the 136 00:06:37.399 --> 00:06:40.879 core idea there? In modern C plus plus? Go right? 137 00:06:41.000 --> 00:06:44.720 Oop object oriented programming. It's a shift from just thinking 138 00:06:44.759 --> 00:06:47.079 about sequences of actions. You think about objects. 139 00:06:47.199 --> 00:06:48.120 And objects are. 140 00:06:48.079 --> 00:06:50.800 They bundle data? They're attributes and the functions or methods 141 00:06:50.800 --> 00:06:53.000 that work on that data. In C plus plus A, 142 00:06:53.160 --> 00:06:55.240 the blueprints for these objects are classes. 143 00:06:55.439 --> 00:06:57.959 Okay, and where do we define these classes? Now? With 144 00:06:58.120 --> 00:06:58.879 modules and all. 145 00:06:58.959 --> 00:07:01.680 Often you'll define them in modern interface files. These usually 146 00:07:01.720 --> 00:07:05.160 have a dot CPPM extension. Then you explicitly export the 147 00:07:05.160 --> 00:07:07.720 module and the class definitions you want others to use. 148 00:07:07.959 --> 00:07:10.680 So the dot CPPM file is like the public facing 149 00:07:10.720 --> 00:07:11.759 design exactly. 150 00:07:11.800 --> 00:07:16.040 Imagine a module airline ticket. Inside you export class airline ticket. 151 00:07:16.199 --> 00:07:18.720 It would have public stuff functions like calculate price end 152 00:07:18.759 --> 00:07:21.120 dollars or get passenger name, things. 153 00:07:20.920 --> 00:07:22.759 You can call from outside right, and. 154 00:07:22.720 --> 00:07:25.360 It would have private members. The internal data like in 155 00:07:25.439 --> 00:07:31.000 passenger name or number of miles hidden managed internally. That's encapsulation, 156 00:07:31.240 --> 00:07:34.639 bundling data and functions, controlling access. 157 00:07:34.439 --> 00:07:39.839 Public private classic oop. Got it. When we create one 158 00:07:39.879 --> 00:07:43.319 of these airline ticket objects, how do those private data 159 00:07:43.319 --> 00:07:46.040 members like number oh miles get their starting values? 160 00:07:46.240 --> 00:07:50.519 Modern C plus plus has in class initializers. Write in 161 00:07:50.560 --> 00:07:52.839 the class definition you can give a data member a 162 00:07:52.879 --> 00:07:55.759 default value oh neat Yeah, Like in an employee class, 163 00:07:55.759 --> 00:07:58.680 you could write in salary seventy five thousand right there. 164 00:07:58.800 --> 00:08:01.519 If you create an employ object without specifying a salary, 165 00:08:01.600 --> 00:08:04.279 it gets that default. If a basic type doesn't have one, 166 00:08:04.319 --> 00:08:07.639 it usually gets zero. Initialized helps ensure objects start in 167 00:08:07.680 --> 00:08:08.600 a known state. 168 00:08:08.920 --> 00:08:12.040 Setting defaults right where you declare them. Seems handy. Okay, 169 00:08:12.079 --> 00:08:14.879 let's tackle a topic that sometimes makes people nervous. Pointers 170 00:08:14.879 --> 00:08:17.800 and references. How do they fit into modern C plus 171 00:08:17.839 --> 00:08:20.160 plus sac has that changed much? 172 00:08:20.399 --> 00:08:23.360 Coiners are still around, definitely needed for low level stuff 173 00:08:23.480 --> 00:08:27.920 or interacting with C libraries, but modern C plus plus 174 00:08:28.439 --> 00:08:33.799 really encourages minimizing manual pointer use, especially for memory ownership. 175 00:08:33.399 --> 00:08:37.080 Right less direct fiddling with memory addresses exactly now. 176 00:08:37.120 --> 00:08:40.559 With constant pointers, there's a useful rule. Const applies to 177 00:08:40.639 --> 00:08:43.320 what's immediately to its left. If there's nothing left, it 178 00:08:43.320 --> 00:08:46.279 applies to their right. It constan applies left unless it's 179 00:08:46.320 --> 00:08:49.759 at the very beginning. So in const ptr means a 180 00:08:49.799 --> 00:08:53.600 pointer to a constant integer. You can change where ptr points, 181 00:08:53.639 --> 00:08:56.720 but not the in value via ptrh And. 182 00:08:56.759 --> 00:08:58.080 In const ptr, yeah. 183 00:08:57.960 --> 00:09:00.320 Const is to the left of ptr. So it's a 184 00:09:00.360 --> 00:09:03.440 constant pointer to a non constant integer, you can change 185 00:09:03.480 --> 00:09:06.559 the NS value, but you can't make ptr points somewhere else. 186 00:09:06.559 --> 00:09:10.480 And in constant ptr both constant pointer to a constant 187 00:09:10.480 --> 00:09:12.679 integer can't change the in value, can't change where the 188 00:09:12.720 --> 00:09:16.200 pointer points. That finer control helps right safer code. 189 00:09:16.279 --> 00:09:19.879 Constant plies left. Okay, that's a good knemonic. What about references? 190 00:09:19.960 --> 00:09:22.720 They feel similar to pointers, but different they are different. 191 00:09:23.200 --> 00:09:25.919 Think of our reference as an alias, just another name 192 00:09:25.960 --> 00:09:30.080 for an existing variable. When you say nten x, refix 193 00:09:30.399 --> 00:09:31.559 x ref is x. 194 00:09:32.120 --> 00:09:32.720 The key thing. 195 00:09:33.080 --> 00:09:36.200 Once a reference is initialized, it cannot be changed to 196 00:09:36.240 --> 00:09:39.759 refer to a different variable. Ever, you can change the 197 00:09:39.879 --> 00:09:42.080 value of the variable it refers to if it's not 198 00:09:42.120 --> 00:09:44.879 a constant reference, but the referance itself is. 199 00:09:44.879 --> 00:09:47.000 Stuck and references to constant like. 200 00:09:46.960 --> 00:09:49.600 Constant in treface. Some ind they're simpler in a way 201 00:09:49.639 --> 00:09:53.039 because the reference itself is implicitly constant regarding what it 202 00:09:53.080 --> 00:09:55.519 refers to, and you can't change the value through it. 203 00:09:55.720 --> 00:09:58.440 Okay, So when do you pick a pointer versus a reference? 204 00:09:58.480 --> 00:09:59.440 In modern code? 205 00:10:00.000 --> 00:10:03.039 It mainly for dynamic memory you get from new you 206 00:10:03.080 --> 00:10:05.519 need a pointer to hold that address. Also, if you 207 00:10:05.600 --> 00:10:08.399 need something that might be null and optional value pointers 208 00:10:08.440 --> 00:10:10.799 can be null, ptr references. 209 00:10:10.360 --> 00:10:12.200 Can't, and polymorphism yep. 210 00:10:12.120 --> 00:10:15.639 Storing different derived types via a base class pointer in containers. 211 00:10:16.440 --> 00:10:19.360 But the big thing about ownership modern C plus plus 212 00:10:19.480 --> 00:10:23.720 is avoid raw pointers for owning memory. Use smart pointers instead. 213 00:10:23.720 --> 00:10:25.399 We'll get to those so smart. 214 00:10:25.120 --> 00:10:28.519 Pointers handle the ownership when our reference is the better choice. 215 00:10:28.720 --> 00:10:31.799 Often for function parameters, if you need to guarantee the 216 00:10:31.799 --> 00:10:35.240 function gets a valid object. References are great because they 217 00:10:35.279 --> 00:10:37.840 can't be null and if the function might modify the 218 00:10:37.879 --> 00:10:40.799 object and it's not a constant reference. They often lead 219 00:10:40.799 --> 00:10:41.879 to cleaner syntax too. 220 00:10:42.120 --> 00:10:44.879 It's like a variable as a house. A reference is 221 00:10:44.879 --> 00:10:47.600 a nickname for the house. A pointer is the address 222 00:10:47.600 --> 00:10:49.759 on a piece of paper. You can change the address 223 00:10:49.799 --> 00:10:50.879 to point to a different house. 224 00:10:51.039 --> 00:10:54.200 That's a great analogy. References are bound to one house. 225 00:10:54.320 --> 00:10:55.799 Pointers can be retargeted. 226 00:10:55.960 --> 00:11:00.960 Smart pointers definitely sounds like the way forward from memory. Okay, 227 00:11:01.039 --> 00:11:05.440 zooming out best practices for writing good C plus plus code. 228 00:11:05.240 --> 00:11:09.559 Overall several things. One use getters and setters, accessor and 229 00:11:09.679 --> 00:11:12.960 mutator methods, even to access data members within the same. 230 00:11:12.799 --> 00:11:14.960 Class, really even inside the class. 231 00:11:15.000 --> 00:11:17.840 Why it gives you a layer of abstraction maybe later 232 00:11:17.879 --> 00:11:19.879 you need to add validation or change how the data 233 00:11:19.919 --> 00:11:23.240 is stored internally or log access. Using methods means you 234 00:11:23.240 --> 00:11:26.639 can change the implementation without breaking how other parts of 235 00:11:26.639 --> 00:11:27.639 the class use the data. 236 00:11:27.840 --> 00:11:30.440 Ah, future proofing makes sense. What else? 237 00:11:30.720 --> 00:11:35.279 Clear code structure? Breakdown functions? Seriously, if a function does 238 00:11:35.279 --> 00:11:38.240 three different things, it should probably be three functions. Makes 239 00:11:38.279 --> 00:11:43.919 it easier to read, test, maintain single responsibility principle. 240 00:11:43.559 --> 00:11:46.919 Basically, smaller focused functions. Got it right. What about naming 241 00:11:47.000 --> 00:11:50.879 things variable names? I've seen debates about prefixes like M 242 00:11:50.919 --> 00:11:51.519 for members. 243 00:11:51.720 --> 00:11:54.519 Yeah, that's a bit contentious. Prefixes like M or G 244 00:11:54.919 --> 00:11:58.360 or ptr. Some find them helpful, but the modern trend 245 00:11:58.399 --> 00:12:02.200 is often against them. Why they can hurt maintainability. If 246 00:12:02.240 --> 00:12:04.480 you change a variables type or scope, you have to 247 00:12:04.480 --> 00:12:07.840 remember to change the prefix everywhere miss one and the 248 00:12:07.919 --> 00:12:11.720 name becomes misleading. Better to choose names that clearly describe 249 00:12:11.720 --> 00:12:15.080 the variable's purpose, not just its type. The compiler knows 250 00:12:15.120 --> 00:12:15.679 the type. 251 00:12:15.799 --> 00:12:18.879 Focus on purpose, not type hints in the name. Okay, okay. 252 00:12:19.159 --> 00:12:21.799 We also said references are often safer than rob pointers. 253 00:12:22.159 --> 00:12:24.440 Any common mix ups there, especially with function calls. 254 00:12:24.679 --> 00:12:27.240 Yeah, A big one is thinking that seeing an ampersand 255 00:12:27.360 --> 00:12:30.399 in a function call automatically means the original variable will 256 00:12:30.440 --> 00:12:33.600 be changed, or that no ampersand means it won't be changed. 257 00:12:33.639 --> 00:12:35.720 That's not true, not necessarily. You have to look at 258 00:12:35.759 --> 00:12:38.440 how the parameter is declared in the function's definition. Is 259 00:12:38.480 --> 00:12:43.519 it TN non constant reference consts TNT non constant pointer 260 00:12:44.080 --> 00:12:47.279 const T Only the const versions guarantee no modification through 261 00:12:47.279 --> 00:12:49.840 that parameter. The call site syntax alone doesn't tell the 262 00:12:49.840 --> 00:12:50.399 whole story. 263 00:12:50.720 --> 00:12:54.120 Okay, crucial distinction. Look at the function declaration, not just 264 00:12:54.159 --> 00:12:58.360 the call. Got it shifting gears? Planning? How important is 265 00:12:58.399 --> 00:13:00.879 designing stuff before writing c P plus plus code? 266 00:13:01.039 --> 00:13:04.879 Hugely important, especially for bigger projects. It's like needing blueprints 267 00:13:04.919 --> 00:13:05.799 before building. 268 00:13:05.559 --> 00:13:07.879 A house avoids chaos exactly. 269 00:13:08.000 --> 00:13:11.039 Design helps define how parts interact, who's responsible for what, 270 00:13:11.320 --> 00:13:14.399 how requirements are met. Without it, you risk missing connections, 271 00:13:14.399 --> 00:13:17.799 missing chances for code reuse, picking inefficient solutions. It's the 272 00:13:17.840 --> 00:13:19.720 big picture and it's documentation. 273 00:13:19.960 --> 00:13:25.200 But what about agile ideas like working software over comprehensive documentation. 274 00:13:25.559 --> 00:13:29.279 Good point, It's a balance. Agile doesn't mean no documentation. 275 00:13:29.879 --> 00:13:32.559 You still absolutely need up to date design docs for 276 00:13:32.600 --> 00:13:35.679 the key architectural stuff. Essential for the long run. 277 00:13:36.000 --> 00:13:39.679 Okay, finding that balance? What are some core design principles 278 00:13:40.080 --> 00:13:43.440 C plus plus dev should really internalize. 279 00:13:42.799 --> 00:13:46.240 Two huge ones, abstraction and reuse abstraction? 280 00:13:46.360 --> 00:13:47.759 First, what's the essence. 281 00:13:48.360 --> 00:13:52.120 Designing so users of your class or function interact via 282 00:13:52.240 --> 00:13:55.759 a clear interface without needing to know the messy internal details. 283 00:13:55.799 --> 00:13:58.759 Like the chessboard example. Earlier you make moves, you don't 284 00:13:58.799 --> 00:14:00.240 need to know if the board is totor or does 285 00:14:00.279 --> 00:14:03.519 an array or pointers or whatever implementation hidden? 286 00:14:03.679 --> 00:14:07.519 Hide the complexity behind a clean interface and reuse. 287 00:14:07.799 --> 00:14:09.919 Just like the baking analogy, you don't build an oven 288 00:14:09.960 --> 00:14:13.360 every time you bake a cake. Right reuse means actively 289 00:14:13.480 --> 00:14:18.320 looking for existing code libraries, frameworks, your own pass code 290 00:14:18.320 --> 00:14:20.960 that does what you need. Saves massive time and effort, 291 00:14:21.120 --> 00:14:24.000 usually leads to more robust code because it's already tested. 292 00:14:24.399 --> 00:14:27.080 Don't reinvent the wheel if a perfectly good one exists. 293 00:14:27.120 --> 00:14:30.440 Makes total sense. But how do you choose what to reuse? 294 00:14:30.960 --> 00:14:32.120 Picking the right library? 295 00:14:32.200 --> 00:14:36.080 Say good question? First, Really understand its capabilities and its limitations. 296 00:14:36.360 --> 00:14:39.320 Read the docs, study the API. If you can look 297 00:14:39.320 --> 00:14:42.559 at the source, talk to people. Definitely ask other devs 298 00:14:42.559 --> 00:14:45.559 who've used it. What are the strengths, weaknesses, any traps. 299 00:14:45.840 --> 00:14:48.879 Get the core idea, then think about your specific needs. 300 00:14:48.879 --> 00:14:54.200 Understand it fully, read the manual, ask around solid advice now. 301 00:14:54.240 --> 00:14:57.600 The source mentioned a mental shift moving from procedural thinking 302 00:14:57.679 --> 00:15:01.279 to object oriented thinking. How does that usually happen? 303 00:15:01.360 --> 00:15:04.879 Often there's an aha moment. Programmers start seeing how data 304 00:15:04.960 --> 00:15:07.639 and the functions that act on it naturally belong together 305 00:15:07.799 --> 00:15:09.519 in well classes. 306 00:15:09.120 --> 00:15:10.159 At lays they're grouping things. 307 00:15:10.320 --> 00:15:13.679 Yeah, some might refactor existing procedural code bit by bit, 308 00:15:13.759 --> 00:15:16.960 turning related stuff into classes. Others might dive straight into 309 00:15:17.000 --> 00:15:20.080 an O design for a new project. The source notes 310 00:15:20.159 --> 00:15:24.600 two main approaches using classes selectively we're convenient or building 311 00:15:24.600 --> 00:15:27.559 the whole system around interacting objects from the start. No 312 00:15:27.679 --> 00:15:31.080 single right path, but understanding the benefits is key. 313 00:15:31.279 --> 00:15:34.320 A spectrum then from tactically used to full adoption. What 314 00:15:34.399 --> 00:15:37.039 about going too far the other way? Designing classes that 315 00:15:37.080 --> 00:15:37.840 are too general? 316 00:15:38.039 --> 00:15:41.440 Ah, the overly general class. That's usually a bad sign. 317 00:15:41.559 --> 00:15:44.559 Trying to make one class handle too many unrelated things like. 318 00:15:44.519 --> 00:15:49.720 The media organizer example, photos, music, movies, journals all in one. 319 00:15:49.559 --> 00:15:53.399 Class exactly, It ends up confusing, hard to understand, hard 320 00:15:53.480 --> 00:15:57.759 to use generic properties like data a performed method that 321 00:15:57.799 --> 00:16:02.799 does wildly different things. It's better to have specific classes, 322 00:16:02.879 --> 00:16:05.120 each representing one clear concept. 323 00:16:05.279 --> 00:16:08.159 One class to rule them all usually rules none of them. 324 00:16:08.200 --> 00:16:11.600 Well, gotcha? How do classes relate to each other? The 325 00:16:11.639 --> 00:16:13.039 source mentioned has. 326 00:16:12.840 --> 00:16:16.639 A and is a fundamental relationships, has a is composition 327 00:16:16.759 --> 00:16:19.840 or containment. One class holds an instance of another as a. 328 00:16:19.799 --> 00:16:22.320 Member, like car has an engine. 329 00:16:22.039 --> 00:16:26.120 Perfect example. The engine is a component is inheritance. A 330 00:16:26.200 --> 00:16:29.039 derived class is a specialized version of a base class. 331 00:16:29.200 --> 00:16:31.120 Sports car is a car. It gets all the car stuff, 332 00:16:31.120 --> 00:16:32.399 maybe adds more specific things. 333 00:16:32.480 --> 00:16:35.480 Has a for components, is a for specialization. Clear? What's 334 00:16:35.519 --> 00:16:38.559 the main win from using inheritance code reuse? 335 00:16:38.639 --> 00:16:42.080 Primarily the derived class automatically gets the base class members 336 00:16:42.080 --> 00:16:44.720 and functions, no need to rewrite common stuff. It works 337 00:16:44.720 --> 00:16:47.559 best when the base class defines a common interface maybe 338 00:16:47.720 --> 00:16:50.240 abstract the derived classes implement. 339 00:16:50.360 --> 00:16:53.039 You need to be careful. Yeah, if a derived class 340 00:16:53.120 --> 00:16:55.960 ends up overwriting or changing most of its parent stuff, 341 00:16:56.240 --> 00:16:59.919 maybe inheritance wasn't the right fit. There is a relationship 342 00:17:00.000 --> 00:17:00.879 should feel natural? 343 00:17:01.120 --> 00:17:04.680 Makes sense. The source also mentioned multiple inheritance C plus 344 00:17:04.680 --> 00:17:05.640 plus allows. 345 00:17:05.359 --> 00:17:08.039 That it does. A class can inherit directly from more 346 00:17:08.079 --> 00:17:11.680 than one base class. The example was maybe an animal base, 347 00:17:11.960 --> 00:17:16.440 then hierarchies for size, diet movement. A dog bird could 348 00:17:16.440 --> 00:17:18.839 inherit from dog like and bird like bases. 349 00:17:19.160 --> 00:17:21.880 Sounds potentially complicated. 350 00:17:22.039 --> 00:17:24.519 It can be, especially with the diamond problem. If a 351 00:17:24.559 --> 00:17:27.119 class inherits from two classes that both inherit from the 352 00:17:27.160 --> 00:17:31.039 same grandparent class, you get ambiguity. Which grandparent member do 353 00:17:31.079 --> 00:17:34.279 you use? C plus plus has mechanisms like virtual inheritance 354 00:17:34.319 --> 00:17:37.519 to solve it, but yeah, it adds complexity, needs careful handling. 355 00:17:37.599 --> 00:17:40.799 The diamond problem something to watch out for. Okay, beyond 356 00:17:40.920 --> 00:17:44.319 reuse and abstraction any other key design principles C plus 357 00:17:44.319 --> 00:17:45.640 plus dev should keep front. 358 00:17:45.519 --> 00:17:49.200 Of mind definitely clear code structure. Like we said, usable 359 00:17:49.200 --> 00:17:53.640 interface is intuitive for others to use, balancing generality versus specificity. 360 00:17:53.680 --> 00:17:55.880 Don't make it too complex by trying to handle everything, 361 00:17:56.119 --> 00:18:00.079 but don't make it so specific it's inflexible and all 362 00:18:00.200 --> 00:18:05.599 to principles five core OO design guidelines for maintainable flexible code. 363 00:18:05.880 --> 00:18:08.720 We won't dive deep into solid now, but they're worth learning. 364 00:18:08.920 --> 00:18:11.640 Lots to think about for good design. The source used 365 00:18:11.640 --> 00:18:15.880 a cool analogy for the strategy pattern interchangeable parts like 366 00:18:15.920 --> 00:18:18.079 a car and its engine. Can you expand on that? 367 00:18:18.279 --> 00:18:21.240 Yeah, that illustrates it well. Instead of hard coding engine 368 00:18:21.279 --> 00:18:24.839 logic inside the car class, the strategy pattern says, define 369 00:18:24.880 --> 00:18:28.119 a separate engine interface or base class. Maybe have gasoline 370 00:18:28.160 --> 00:18:29.880 engine electric engine. 371 00:18:29.640 --> 00:18:31.480 Implementations, and the car just holds one. 372 00:18:31.680 --> 00:18:34.480 Right, the car class holds a pointer or reference to 373 00:18:34.519 --> 00:18:36.680 some kind of engine. This makes it super flexible. You 374 00:18:36.680 --> 00:18:39.160 can swap engine types easily, maybe even at run time, 375 00:18:39.240 --> 00:18:41.440 without changing the car class itself, just like real cars. 376 00:18:41.880 --> 00:18:46.559 Modularity adaptability design for swappable parts makes software more flexible. 377 00:18:46.599 --> 00:18:49.640 Okay. Template programming now the huge C plus plus feature 378 00:18:49.880 --> 00:18:51.160 design considerations there. 379 00:18:51.279 --> 00:18:55.119 Templates let you write code parameterized by type. Think std 380 00:18:55.240 --> 00:18:59.160 dot vectorant and std dot vector double. Same vector code. 381 00:18:58.880 --> 00:19:01.920 Works for both once, use it for many types. 382 00:19:02.000 --> 00:19:05.200 That's the core idea. Create generic classes or functions that 383 00:19:05.240 --> 00:19:08.359 work with different data types without duplicating code. It can 384 00:19:08.400 --> 00:19:12.039 get really advanced, but even basic templates give huge wins 385 00:19:12.079 --> 00:19:15.920 for reuse and flexibility, like a single sort template sorting, 386 00:19:16.000 --> 00:19:20.240 ince double strings, anything comparable. We'll dig into writing custom 387 00:19:20.279 --> 00:19:20.960 templates later. 388 00:19:21.200 --> 00:19:25.440 Generic code adapting to types powerful stuff. Now shifting to 389 00:19:25.480 --> 00:19:28.680 safety and robustness. How do we design C plus plus 390 00:19:28.759 --> 00:19:30.160 code to be reliable? 391 00:19:30.359 --> 00:19:33.400 It's about proactively building in checks and safeguards. How do 392 00:19:33.400 --> 00:19:36.000 you use signal errors instead of just magic numbers or 393 00:19:36.079 --> 00:19:39.359 error codes? Modern clus plus has better tools like what 394 00:19:39.680 --> 00:19:42.359 std't at optional for values that might be absent, forces 395 00:19:42.359 --> 00:19:45.119 the caller to check, or exceptions for more serious errors 396 00:19:45.160 --> 00:19:47.759 the current code can't handle. Let someone else catch and 397 00:19:47.799 --> 00:19:50.599 deal with it. We'll cover exceptions more soon. The main 398 00:19:50.599 --> 00:19:54.200 thing is anticipating problems and handling them gracefully, not just crashing. 399 00:19:54.440 --> 00:19:58.079 Be proactive, use the right tools like optional or exceptions. 400 00:19:58.559 --> 00:20:02.400 Got it? The source also distinguish between internal contracts and 401 00:20:02.559 --> 00:20:04.559