WEBVTT 1 00:00:00.040 --> 00:00:04.559 Okay, let's unpack this. Imagine your software running right, doing 2 00:00:04.599 --> 00:00:09.080 its thing, but underneath all that, there's this this hidden world, 3 00:00:09.359 --> 00:00:12.439 unseen forces basically running the show. It's the connection between 4 00:00:12.480 --> 00:00:15.759 your code and the computer's memory. Today we're doing a 5 00:00:15.800 --> 00:00:19.760 deep dive into C plus plus memory management. It's fascinating stuff, 6 00:00:20.079 --> 00:00:24.160 but yeah, often pretty intimidating too. We're using Patresea's really 7 00:00:24.160 --> 00:00:27.039 comprehensive book as our guide here. Now. C plus plus 8 00:00:27.039 --> 00:00:29.600 memory Management it can feel like a maze, you know, 9 00:00:30.239 --> 00:00:33.280 full of complex rules, hidden traps. But our mission today 10 00:00:33.320 --> 00:00:35.200 is to give you a shortcut. We want to boil 11 00:00:35.280 --> 00:00:37.799 down the core ideas, point out those pitfalls, and look 12 00:00:37.799 --> 00:00:40.159 at the modern ways of doing things. Hopefully help you 13 00:00:40.159 --> 00:00:42.960 write C plus plus code that's better, safer, more expressive. 14 00:00:43.320 --> 00:00:46.240 Expect some uh aha moments today. 15 00:00:46.320 --> 00:00:49.240 Absolutely becres he has this great skill, doesn't he, Taking 16 00:00:49.240 --> 00:00:52.799 these really dense technical topics and making them feel well, 17 00:00:52.840 --> 00:00:55.600 almost conversational. This book, it's not just rules. It really 18 00:00:55.640 --> 00:00:58.960 explores how C plus plus talks to memory at its heart. 19 00:00:59.000 --> 00:00:59.880 It's quite empowering. 20 00:01:00.000 --> 00:01:02.719 Actually totally agree. So let's start right at the beginning, 21 00:01:02.920 --> 00:01:06.640 the building blocks. What's the absolute most fundamental thing we 22 00:01:06.680 --> 00:01:09.760 need to get our heads around with C plus plus memory. 23 00:01:10.040 --> 00:01:12.400 Well, what's really interesting is how C plus plus even 24 00:01:12.400 --> 00:01:16.680 defines an object. You know, most people think classes. 25 00:01:16.599 --> 00:01:18.519 Strucks, right, yeah, that's what I think. 26 00:01:18.599 --> 00:01:21.000 But in C plus plus AC it's actually much broader. 27 00:01:21.319 --> 00:01:24.280 Even basic types like an int or a float they're 28 00:01:24.280 --> 00:01:25.439 considered objects too. 29 00:01:25.719 --> 00:01:29.000 Wait, really an int is an object? How does that work? 30 00:01:29.159 --> 00:01:32.439 It's about having certain properties to be an object. In 31 00:01:32.560 --> 00:01:36.200 C plus plus FAG, something needs an address in memory, 32 00:01:36.599 --> 00:01:40.000 it needs to take up some space non zero storage 33 00:01:40.359 --> 00:01:42.719 that has a lifetime, maybe a name, definitely a type, 34 00:01:42.959 --> 00:01:45.599 and a storage duration. In fact, you can actually write 35 00:01:45.760 --> 00:01:49.719 static assert sdd dot ice object vint and well it'll 36 00:01:49.719 --> 00:01:50.840 compile just fine. Huh. 37 00:01:51.000 --> 00:01:53.560 Okay, so even a simple nt has all these characteristics. 38 00:01:53.560 --> 00:01:54.359 That's foundational. 39 00:01:54.480 --> 00:01:56.439 It really is understanding that helps make sense of a 40 00:01:56.480 --> 00:01:57.200 lot of other things. 41 00:01:57.359 --> 00:01:59.680 Okay, so everything has its place, it's time and memory. 42 00:02:00.000 --> 00:02:04.200 Speaking of places, pointers they're everywhere in C plus plus 43 00:02:04.239 --> 00:02:07.959 C right, even if the book mentions kind of usingly 44 00:02:08.120 --> 00:02:11.439 that a strict definition is surprisingly hard to come by 45 00:02:11.919 --> 00:02:12.599 in the standard. 46 00:02:12.680 --> 00:02:17.759 Exactly. Pointers are incredibly powerful tools, but that power comes 47 00:02:17.800 --> 00:02:20.560 with risk. Put it arithmetic for example, you can write 48 00:02:21.039 --> 00:02:24.319 it q qles P plus three, no problem. But if 49 00:02:24.360 --> 00:02:27.840 P isn't pointing where you think it is, trouble, big trouble. 50 00:02:28.439 --> 00:02:30.919 Q could point to some arbitrary location. You could cause 51 00:02:30.960 --> 00:02:35.159 serious damage. And the responsibility for managing that power it 52 00:02:35.199 --> 00:02:38.479 always falls back on the C plus plus programmer. Always right. 53 00:02:38.680 --> 00:02:41.840 With great power, it comes great responsibility. As they say, okay, 54 00:02:42.000 --> 00:02:44.639 what about void? I see that sometimes in like lower 55 00:02:44.680 --> 00:02:45.479 level code. 56 00:02:45.240 --> 00:02:48.360 Ah void. Think of it as just a raw memory address. 57 00:02:48.599 --> 00:02:50.759 It tells you where something is, but not what it is. 58 00:02:51.280 --> 00:02:54.240 It has no type information attached. Any other pointer type 59 00:02:54.240 --> 00:02:56.599 can convert to void, but going back the other way 60 00:02:56.879 --> 00:02:59.919 usually needs an explicit cast, basically saying here's a location, 61 00:03:00.319 --> 00:03:02.159 but I make no promises about what's there. 62 00:03:02.520 --> 00:03:05.599 Got it. So beyond just what an object is, let's 63 00:03:05.599 --> 00:03:11.000 talk about its life in memory, lifetime, size, alignment padding. 64 00:03:11.560 --> 00:03:14.159 How does C plus plus manage lifetime? 65 00:03:14.680 --> 00:03:17.919 Lifetime is absolutely key. Automatic objects, the ones usually on 66 00:03:17.960 --> 00:03:21.919 the stack, have very predictable, deterministic lifetimes. They get created, 67 00:03:21.960 --> 00:03:24.719 they go out of scope, Boom, they're destructed. Static objects 68 00:03:24.759 --> 00:03:28.199 live for pretty much the whole program run. But dynamically 69 00:03:28.240 --> 00:03:31.719 allocated objects, the ones you create with new. Their lifetime 70 00:03:31.840 --> 00:03:34.960 is well when your program says so, and that's where 71 00:03:35.000 --> 00:03:35.759 things can go wrong. 72 00:03:35.879 --> 00:03:38.680 Ah okay, So if it's when your program says so, 73 00:03:38.680 --> 00:03:41.439 I'm guessing the classic mistake is forgetting to say it's 74 00:03:41.479 --> 00:03:42.840 over right, forgetting to delete. 75 00:03:42.840 --> 00:03:45.240 That's the number one pitfall. Absolutely, you call new, you 76 00:03:45.240 --> 00:03:48.199 get your object, it's constructor runs. But if you forget delete, 77 00:03:48.240 --> 00:03:51.560 the destructor never runs, and the memory it just leaks away. 78 00:03:51.599 --> 00:03:53.639 Resource leak, memory leak, bad news. 79 00:03:53.800 --> 00:03:56.800 Right. Okay, Now this next bit sounds really interesting. Size 80 00:03:56.840 --> 00:04:00.360 alignment and padding using size isn't always straightforward. 81 00:03:59.840 --> 00:04:01.840 No, so it often surprises people. This is a great 82 00:04:01.840 --> 00:04:05.159 aha moment. Let's take a simple class class X charcis 83 00:04:05.240 --> 00:04:06.439 short S and tn. 84 00:04:06.759 --> 00:04:11.280 Okay, a char a short an int, So like one 85 00:04:11.280 --> 00:04:13.560 by plus two bytes plus four bytes seven bytes. 86 00:04:13.599 --> 00:04:15.960 That's what you'd intuitively think, right, But if you actually 87 00:04:16.040 --> 00:04:19.000 check size of x, you'll probably find it's eight bytes eight. 88 00:04:19.240 --> 00:04:20.720 Where does the extra byte come from? 89 00:04:20.920 --> 00:04:24.720 Comes from? Padding bytes? Compilers often add these invisible bytes 90 00:04:24.720 --> 00:04:27.639 between members, So between C and S there might be 91 00:04:27.680 --> 00:04:31.360 a padding byte between S and N maybe two padding bytes. 92 00:04:31.680 --> 00:04:37.240 Why performance exactly? Performance CPU's access data much more efficiently 93 00:04:37.319 --> 00:04:39.920 when it's aligned on certain boundaries, like a four byte 94 00:04:39.920 --> 00:04:42.680 boundary for an ind So the compiler adds padding to 95 00:04:42.800 --> 00:04:45.000 ensure each member starts at an optimal address. 96 00:04:45.160 --> 00:04:48.199 Okay, that makes sense, But the book also mentions trailing 97 00:04:48.240 --> 00:04:50.279 padding bytes patting at the end of the object. 98 00:04:50.279 --> 00:04:53.879 Why ah, that's specifically for arrays of these objects. Remember, 99 00:04:53.959 --> 00:04:56.079 array elements have to sit right next to each other 100 00:04:56.120 --> 00:04:59.800 in memory contiguously. That trailing padding ensures that if array 101 00:04:59.839 --> 00:05:02.560 is properly aligned, then R one will also start on 102 00:05:02.600 --> 00:05:05.759 the correct alignment boundary, and so on. It's subtle, but 103 00:05:05.839 --> 00:05:07.920 crucial for array correctness and performance. 104 00:05:08.360 --> 00:05:10.959 Wow. Okay, so memory isn't quite as packed as you 105 00:05:11.040 --> 00:05:13.920 might think. This has got to affect how C plus 106 00:05:13.959 --> 00:05:15.920 plus copies and moves objects around. 107 00:05:15.959 --> 00:05:20.519 Surely, Oh, absolutely, Copy and move operations constructors assignment operators 108 00:05:20.839 --> 00:05:23.600 are deeply affected by this, especially when you write your 109 00:05:23.639 --> 00:05:27.279 own classes. For a really simple struct maybe like point 110 00:05:27.279 --> 00:05:31.079 two d just two floats, the compiler generated copy and 111 00:05:31.120 --> 00:05:33.800 move are usually fine, But if you have a class 112 00:05:33.839 --> 00:05:36.800 like say naive string, that manages its own raw memory 113 00:05:36.879 --> 00:05:39.759 like a character array, then the defaults are not. Okay, 114 00:05:39.959 --> 00:05:42.720 you absolutely need to write your own destructor copy constructor 115 00:05:42.759 --> 00:05:45.480 copy assignment. That's the classic rule of three and. 116 00:05:45.439 --> 00:05:47.800 The rule of five. If you add move operations, which 117 00:05:47.800 --> 00:05:50.360 is pretty standard now in modern C plus. 118 00:05:50.120 --> 00:05:54.040 Plus, precisely you need custom logic to handle copying or 119 00:05:54.079 --> 00:05:56.279 moving that raw memory correctly, Otherwise you end up with 120 00:05:56.560 --> 00:05:58.839 shallow copies, double deletes all sorts of problems. 121 00:05:58.879 --> 00:06:01.839 And the book mentions s TD dot exchange as a 122 00:06:01.879 --> 00:06:03.519 helper for writing move constructors. 123 00:06:03.839 --> 00:06:06.959 Yeah, std dot exchange is neat little utility. It basically 124 00:06:07.040 --> 00:06:09.639 lets you swap the resource pointer in your move constructor. 125 00:06:09.680 --> 00:06:12.839 More cleanly, it assigns a new value like null ptr 126 00:06:13.040 --> 00:06:15.439 to the source objects pointer and gives you back the 127 00:06:15.480 --> 00:06:18.680 old value the resource pointer, all in one go. Makes 128 00:06:18.720 --> 00:06:21.000 the code a bit tidier less error prone. 129 00:06:21.079 --> 00:06:24.279 Okay, and while we're on data layout, what about basic 130 00:06:24.680 --> 00:06:27.639 built in arrays raw rays? They're just sequences in memory, right, 131 00:06:27.800 --> 00:06:30.120 and pointer arithmetic is key there too, Exactly. 132 00:06:30.240 --> 00:06:34.639 Raw rays are contiguous sequences, and accessing RA is basically 133 00:06:34.639 --> 00:06:37.839 the same as writing R plus I. The crucial thing 134 00:06:37.959 --> 00:06:40.439 is that the plus i isn't just adding ie bytes. 135 00:06:40.480 --> 00:06:43.319 It's typed. It means add i times the size of 136 00:06:43.360 --> 00:06:45.800 one element. So if it's an array events, it adds 137 00:06:45.839 --> 00:06:48.319 i size of bytes. That's how it steps correctly from 138 00:06:48.319 --> 00:06:49.279 one element to the next. 139 00:06:49.360 --> 00:06:51.040 Right, it knows the size of the things in the 140 00:06:51.120 --> 00:06:52.000 array precisely. 141 00:06:52.079 --> 00:06:54.079 Oh. In an interesting side note, new and darro is 142 00:06:54.120 --> 00:06:57.720 actually allowed, you can dynamically allocate a zero sized array. 143 00:06:58.160 --> 00:07:01.439 Doesn't sound useful, but it can simple some generic code sometimes. 144 00:07:01.680 --> 00:07:04.920 Okay, we've got the building blocks. Now let's walk down 145 00:07:04.959 --> 00:07:08.040 what the book calls the perilous path things to be 146 00:07:08.160 --> 00:07:10.959 really careful with. It talks about different kinds of evil 147 00:07:11.000 --> 00:07:16.360 in C plus plus. What let's start with. IFNDR sounds ominous. 148 00:07:16.000 --> 00:07:21.199 IFNDR ill formed no diagnostic required, it's insidious. It means 149 00:07:21.199 --> 00:07:23.839 your code is technically broken according to the C plus 150 00:07:23.839 --> 00:07:26.839 plus standard, but the compiler isn't actually required to warn 151 00:07:26.879 --> 00:07:27.360 you about it. 152 00:07:27.800 --> 00:07:30.639 So it might compile fine, but just not work, or 153 00:07:30.720 --> 00:07:32.560 work sometimes. 154 00:07:31.959 --> 00:07:36.040 Exactly silent failures really hard to debug. The compiler might 155 00:07:36.120 --> 00:07:38.439 not have enough info compile time, or the standard just 156 00:07:38.480 --> 00:07:42.399 gives it a pass on issuing a diagnostic. Very dangerous, okay. 157 00:07:42.439 --> 00:07:45.480 And then the big one, undefined behavior UB everyone talks 158 00:07:45.480 --> 00:07:46.480 about ub ah. 159 00:07:46.600 --> 00:07:50.399 Yes, UB undefined behavior means the C plus plus standard 160 00:07:50.399 --> 00:07:53.680 places absolutely no requirement on what happens if your code 161 00:07:53.720 --> 00:07:56.319 triggers it. Anything could happen. It might crash, it might 162 00:07:56.360 --> 00:07:59.319 give the wrong answer, it might format your hard drive. Okay, 163 00:07:59.360 --> 00:08:02.000 probably not that last one, but technically the standard doesn't 164 00:08:02.000 --> 00:08:02.399 forbid it. 165 00:08:02.480 --> 00:08:05.439 So like dear referencing a null pointer or using an 166 00:08:05.519 --> 00:08:07.480 uninitialized variable, those are. 167 00:08:07.399 --> 00:08:12.360 The classic examples. Yes, dear referencing null, using uninitialized memory, 168 00:08:12.560 --> 00:08:16.639 accessing a raise out of bounds, signed integer overflow. The 169 00:08:16.680 --> 00:08:19.000 list goes on. If you hit UB, you are in 170 00:08:19.120 --> 00:08:21.759 serious trouble. As the book puts it, all bets are off. 171 00:08:21.800 --> 00:08:24.040 And the scary part is how compilers treat it. Right, 172 00:08:24.079 --> 00:08:25.199 they optimize around it. 173 00:08:25.279 --> 00:08:28.079 That's the really unsettling part. Compilers assume that correct C 174 00:08:28.160 --> 00:08:31.360 plus plus code never contains UB, so if they see 175 00:08:31.360 --> 00:08:34.200 potentially UB, they might just optimize assuming it can't happen. 176 00:08:34.360 --> 00:08:37.320 They might remove null checks because hey, you wouldn't dare 177 00:08:37.320 --> 00:08:41.279 reference null later, right. They might reorder operations or eliminate 178 00:08:41.440 --> 00:08:44.799 entire loops based on assumptions flowing from potentially UB. It 179 00:08:44.879 --> 00:08:46.759 leads to sometimes surprising effects. 180 00:08:46.879 --> 00:08:49.639 To put it mildly, wow, So UB isn't just It 181 00:08:49.720 --> 00:08:52.559 might crash. It's the compiler might silently break my code 182 00:08:52.600 --> 00:08:53.440 in weird ways. 183 00:08:53.320 --> 00:08:56.120 Precisely treat you b as a critical bug. Always don't 184 00:08:56.120 --> 00:08:58.720 rely on it working on your specific compiler version. 185 00:08:58.799 --> 00:09:02.759 Okay, IFNDR, what about the one definition rule the ODR. 186 00:09:03.080 --> 00:09:05.200 That sounds important, but maybe less evil. 187 00:09:05.440 --> 00:09:10.080 The ODR is crucial, but yeah, maybe less overtly evil, 188 00:09:10.519 --> 00:09:15.159 more subtly problematic if violated. It basically says that anything 189 00:09:15.200 --> 00:09:18.480 in your program, a function, a class, a template, a 190 00:09:18.559 --> 00:09:23.039 global variable must have exactly one definition in the entire program. 191 00:09:23.080 --> 00:09:26.200 And if you have two definitions, say in different. 192 00:09:25.919 --> 00:09:29.600 Files, then you're often in IFNDR territory again, or the 193 00:09:29.679 --> 00:09:32.960 linker might just silently pick one definition and ignore the other. 194 00:09:33.639 --> 00:09:36.840 This can lead to absolute chaos, especially with templates or 195 00:09:36.879 --> 00:09:40.799 inline functions defined slightly differently in headers included in different places, 196 00:09:41.000 --> 00:09:42.720 very hard to track down bugs. 197 00:09:42.519 --> 00:09:45.360 And implementation defined behavior. How does that fit in? 198 00:09:45.519 --> 00:09:50.000 That's different? Implementation defined means the standard allows different behaviors, 199 00:09:50.159 --> 00:09:53.120 but requires the compiler vendor to document exactly what their 200 00:09:53.159 --> 00:09:54.200 implementation does. 201 00:09:54.320 --> 00:09:57.440 So it's predictable on one compiler, but maybe not portable. 202 00:09:57.159 --> 00:09:59.600 Exactly, Like the size of NT or the result of 203 00:09:59.679 --> 00:10:02.879 right fifting a negative number. It's not inherently evil, just 204 00:10:02.919 --> 00:10:04.480 something to be aware of if you need your code 205 00:10:04.480 --> 00:10:05.679 to work identically everywhere. 206 00:10:05.799 --> 00:10:10.320 Okay, moving on to specific dangerous things point or maneuvers 207 00:10:10.960 --> 00:10:14.879 beyond just adding random numbers. The book mentions type punning. 208 00:10:15.279 --> 00:10:19.480 What's that type punning? It's essentially trying to subvert the 209 00:10:19.519 --> 00:10:22.279 type system. As the book says, you have memory representing 210 00:10:22.320 --> 00:10:24.960 one type, say a float, and you try to access 211 00:10:24.960 --> 00:10:27.519 it as if it were a different type, say an int, 212 00:10:27.799 --> 00:10:29.720 to reinterpret its raw bits. 213 00:10:30.120 --> 00:10:31.919 How do people usually try to do this? 214 00:10:32.159 --> 00:10:35.600 A common but usually illegal way in C plus plus 215 00:10:35.679 --> 00:10:38.559 plus S is using a union. You have a union 216 00:10:38.600 --> 00:10:41.720 with maybe float F and an N you're at to UDAF. 217 00:10:41.759 --> 00:10:43.399 Then you immediately try to read you in. 218 00:10:43.279 --> 00:10:45.559 And that's ub even though they share the same memory. 219 00:10:45.679 --> 00:10:48.600 Generally, yes, that's UBN C plus plus here. Reading from 220 00:10:48.639 --> 00:10:50.840 a union member that wasn't the last one written to 221 00:10:50.960 --> 00:10:53.480 is undefined unless you're dealing with what's called the common 222 00:10:53.559 --> 00:10:54.440 initial sequence. 223 00:10:54.519 --> 00:10:55.559 Common initial sequence. 224 00:10:55.639 --> 00:10:58.200 Yeah, it's a narrow exception. If two structs or classes 225 00:10:58.200 --> 00:10:59.919 in the union start with the same sequence of men 226 00:11:00.279 --> 00:11:02.279 types like both start with an innt followed by a char. 227 00:11:02.519 --> 00:11:04.320 You can write to one and then read that common 228 00:11:04.320 --> 00:11:07.679 sequence part through the other, but it's complex. Relying on 229 00:11:07.799 --> 00:11:09.879 union penning is usually asking for trouble. 230 00:11:10.120 --> 00:11:13.759 What about using std dot memppi. I've seen that used 231 00:11:13.799 --> 00:11:15.360 for reinterpreting. 232 00:11:14.639 --> 00:11:18.279 Bits, right, mechpapie is often suggested. It can be used, 233 00:11:18.360 --> 00:11:20.360 but you have to be careful. If you mempi the 234 00:11:20.360 --> 00:11:22.759 bytes of a float into some raw memory buffer and 235 00:11:22.759 --> 00:11:24.919 then immediately try to read that buffer using an INT, 236 00:11:25.159 --> 00:11:28.639 that's still you b why because mechpi doesn't magically start 237 00:11:28.679 --> 00:11:30.639 the lifetime of nnt object there. It might start the 238 00:11:30.720 --> 00:11:33.080 lifetime of a float if the conditions are right, but 239 00:11:33.200 --> 00:11:36.399 accessing it via ND violates type rules. 240 00:11:36.519 --> 00:11:38.759 So how do you use megpi correctly for this? 241 00:11:39.200 --> 00:11:41.399 The safe way is to magpie the bytes into an 242 00:11:41.399 --> 00:11:44.080 already existing object of the target type, so you'd have 243 00:11:44.120 --> 00:11:46.799 an invariable already and you may compile the float's bites 244 00:11:46.840 --> 00:11:49.600 into the memory location of that INT. That's generally okay. 245 00:11:49.799 --> 00:11:52.799 This is getting really low level. Are there specific types 246 00:11:52.840 --> 00:11:54.600 for messing with addresses as numbers? 247 00:11:54.679 --> 00:11:58.039 Yes, C plus plus provides std dot ntptr t and 248 00:11:58.240 --> 00:12:02.000 ftd dot untptr. These are integer types guaranteed to be 249 00:12:02.080 --> 00:12:04.279 large enough to hold a pointer value. You can cast 250 00:12:04.320 --> 00:12:06.840 a pointer to one of these, do some integer math, maybe, 251 00:12:06.840 --> 00:12:09.279 and then cast it back, But the book warns they 252 00:12:09.320 --> 00:12:13.679 are inherently fragile and non portable. Things like bait order 253 00:12:13.919 --> 00:12:17.759 indianness can bite you. If you're storing addresses as integers, 254 00:12:18.159 --> 00:12:20.759 you're really operating outside the safety of the type system. 255 00:12:21.519 --> 00:12:24.960 Use with extreme caution, usually only needed for very specific, 256 00:12:25.039 --> 00:12:26.080 low level tasks. 257 00:12:26.600 --> 00:12:30.200 Right, Okay, we've seen the dangers. Let's talk about tools 258 00:12:30.200 --> 00:12:33.120 for control. Casting spells as the book calls them. How 259 00:12:33.120 --> 00:12:36.799 should we think about casts? Are we lying to the compiler? 260 00:12:37.159 --> 00:12:39.679 That's a common misconception. Yeah, It's better to think of 261 00:12:39.759 --> 00:12:43.759 casts not as lying, but as adjusting the compiler's view. 262 00:12:44.080 --> 00:12:46.639 You're explicitly telling the compiler. I know you see this 263 00:12:46.720 --> 00:12:49.200 expression as type A, but I want you to treat 264 00:12:49.200 --> 00:12:52.240 it as type B for this specific operation. You're signaling 265 00:12:52.279 --> 00:12:52.759 your intent. 266 00:12:52.919 --> 00:12:55.279 Okay, makes sense. Let's go through the C plus plus 267 00:12:55.320 --> 00:12:58.639 name casts. First. Stato cast. The book calls it our 268 00:12:58.679 --> 00:12:59.600 best friend. 269 00:12:59.519 --> 00:13:02.200 And for good reason. Static cast is for well defined 270 00:13:02.320 --> 00:13:05.519 or reasonably safe conversions things the compiler could often do 271 00:13:05.559 --> 00:13:09.679 implicitly or standard conversions between related types like in to 272 00:13:09.799 --> 00:13:13.320 float or importantly, casting a pointer from a drive class 273 00:13:13.320 --> 00:13:15.480 to its public base class drive it base. 274 00:13:15.759 --> 00:13:18.919 Does stato caast ever change the actual memory address? 275 00:13:19.120 --> 00:13:21.480 Yes, it can. That's a key point. Ye. If use 276 00:13:21.519 --> 00:13:23.679 static cast to drive to a base in a multiple 277 00:13:23.720 --> 00:13:28.039 inheritance scenario, the address might actually change. The base subobject 278 00:13:28.080 --> 00:13:30.000 might not be located at the very beginning of the 279 00:13:30.080 --> 00:13:34.279 drived object and memory. Stata cast handles that address adjustment correctly. 280 00:13:34.399 --> 00:13:39.039 Okay, next dynamic cast, the book says it's assigned. Something's wrong. 281 00:13:39.519 --> 00:13:40.320 That's pretty strong. 282 00:13:40.440 --> 00:13:43.360 It often is assigned. Yeah. Yeah. Dynamic cast is used 283 00:13:43.360 --> 00:13:47.080 for navigating class hierarchies at runtime, typically casting down from 284 00:13:47.080 --> 00:13:49.679 a bates class point of reference to a drive class 285 00:13:49.679 --> 00:13:53.799 point of reference. It needs run time type information RTTI enabled, 286 00:13:53.879 --> 00:13:57.519 which adds overhead, and if the cast fails because the 287 00:13:57.559 --> 00:14:00.480 object isn't actually of the target drive type, it returns 288 00:14:00.559 --> 00:14:04.159 null ptr for pointers or throws std dot bad cast 289 00:14:04.200 --> 00:14:04.919 for references. 290 00:14:05.080 --> 00:14:06.639 So why is it assigned? Something's wrong? 291 00:14:06.759 --> 00:14:09.720 Because heavy reliance on dynamic cast often suggests your class 292 00:14:09.759 --> 00:14:12.279 design might be flawed. You might be better off using 293 00:14:12.360 --> 00:14:16.200 virtual functions polymorphism to achieve the desired behavior without needing 294 00:14:16.200 --> 00:14:18.840 to know the exact drived type at runtime. The book 295 00:14:18.879 --> 00:14:21.759 suggests its use implies a potentially perfectible interface. 296 00:14:22.120 --> 00:14:25.840 Got it, then const cast playing tricks with safety. 297 00:14:26.559 --> 00:14:29.960 Yeah. Constcast is the only cast that can remove cost 298 00:14:30.360 --> 00:14:34.200 or volatile. Its main legitimate use is often dealing with 299 00:14:34.279 --> 00:14:39.000 older APIs or libraries that weren't const correct. You might 300 00:14:39.039 --> 00:14:40.799 have a const object but need to pass it to 301 00:14:40.840 --> 00:14:44.360 a function that inexplicably takes a non constant pointer, even 302 00:14:44.399 --> 00:14:46.679 though you know the function won't actually modify it. But 303 00:14:46.759 --> 00:14:50.679 it's dangerous, extremely dangerous if misused. If the object you're 304 00:14:50.679 --> 00:14:54.000 casting away consts from was originally declared as cost, then 305 00:14:54.120 --> 00:14:56.759 actually trying to modify it through the constcast at pointer 306 00:14:57.000 --> 00:15:01.159 is undefined behavior. You're breaking a fundamental primt use it very, 307 00:15:01.360 --> 00:15:02.080 very sparingly. 308 00:15:02.320 --> 00:15:06.279 And finally, the most feared one reinterpret cast. Believe me 309 00:15:06.320 --> 00:15:07.360 a compiler. 310 00:15:07.000 --> 00:15:09.720 That sums it up perfectly. Reinterpret cast does a raw 311 00:15:09.879 --> 00:15:13.440 bit level reinterpretation between pointer types or pointers and integers. 312 00:15:13.720 --> 00:15:16.320 It tails a compiler forget types. Just treat these bits 313 00:15:16.360 --> 00:15:19.240 as if they were this other pointer type m key danger. 314 00:15:19.639 --> 00:15:23.080 It does no address adjustments. Remember how static cast might 315 00:15:23.080 --> 00:15:26.799 adjust the address for base classes. Reinterpret cast doesn't, so. 316 00:15:26.759 --> 00:15:28.799 If you reinterpret cast a derived to a base in 317 00:15:28.919 --> 00:15:30.799 multiple inheritance, you'll. 318 00:15:30.600 --> 00:15:33.120 Likely get the wrong addressed for the base subobject, and 319 00:15:33.200 --> 00:15:36.799 trying to use that pointer leads straight to undefined behavior. 320 00:15:37.279 --> 00:15:41.440 It's incredibly powerful for low level bit manipulation, but incredibly 321 00:15:41.559 --> 00:15:45.799 easy to misuse with disastrous consequences. Only use it if 322 00:15:45.799 --> 00:15:48.120 you absolutely know what you're doing at the bit level. 323 00:15:48.159 --> 00:15:49.679 Any other is worth mentioning quickly. 324 00:15:49.840 --> 00:15:53.399 The book also notes STD dot bitcast from C plus 325 00:15:53.399 --> 00:15:55.559 plus twenty, which is a safer way to do the 326 00:15:55.600 --> 00:15:59.759 type punting reinterpretation for object types copying bits safely, and 327 00:16:00.120 --> 00:16:03.399 STD do duration cast for working with chronotime durations, which 328 00:16:03.440 --> 00:16:04.720 is very useful and safe. 329 00:16:04.879 --> 00:16:08.440 Okay, And the last cast, the reviled one, the C 330 00:16:08.639 --> 00:16:11.799 style cast TX a prick. Why is it so bad 331 00:16:11.840 --> 00:16:12.759 in C plus. 332 00:16:12.480 --> 00:16:15.440 Plus h several reasons. One, it's hard to search foreign 333 00:16:15.519 --> 00:16:18.759 coode compared to the name C plus plus casts, two, 334 00:16:18.919 --> 00:16:22.320 and most importantly, it lacks intent. A C style cast 335 00:16:22.360 --> 00:16:25.440 tries to be smart and will attempt to sequence of conversions, 336 00:16:25.559 --> 00:16:28.559 often ending up doing a stata cast, a costcast, or 337 00:16:28.600 --> 00:16:31.080 even a reinterpret cast, depending on the types involved. 338 00:16:31.120 --> 00:16:33.200 So am I do a dangerous reinterpret cast when you 339 00:16:33.240 --> 00:16:34.679 didn't explicitly mean. 340 00:16:34.519 --> 00:16:38.600 It to exactly? It hides the potential danger. Using the 341 00:16:38.639 --> 00:16:41.879 specific C plus plus casts forced you to think about 342 00:16:41.879 --> 00:16:44.240 what kind of conversion you actually need and makes your 343 00:16:44.279 --> 00:16:47.639 intent clear to other readers and your future self. Avoid 344 00:16:47.759 --> 00:16:49.440 C style casts in modern C. 345 00:16:49.480 --> 00:16:52.799 Plus plus right clear intent is key. Okay, we've seen 346 00:16:52.799 --> 00:16:56.360 the tools the dangers. Now let's talk about taking responsibility 347 00:16:56.440 --> 00:17:00.759 C plus plus style RAII and smart pointers. The book 348 00:17:00.879 --> 00:17:03.360 really emphasizes the power of destructors here. 349 00:17:03.759 --> 00:17:06.839 Destructors are arguably the killer feature of C plus plus 350 00:17:06.839 --> 00:17:11.960 for resource management. They enable RAII. Resource acquisition is initialization, 351 00:17:12.440 --> 00:17:14.440 though as the book chekily points out, the name is 352 00:17:14.440 --> 00:17:16.839 a bit misleading. It's really more to do with destructors 353 00:17:16.839 --> 00:17:20.599 than constructors. How So, the core idea is you acquire 354 00:17:20.640 --> 00:17:23.279 a resource like memory, a file handle, a lock in 355 00:17:23.319 --> 00:17:27.279 an object's constructor. That object now owns the resource. When 356 00:17:27.319 --> 00:17:29.519 the object's light time ends, usually when it goes out 357 00:17:29.559 --> 00:17:32.599 of scope, its destructor is automatically called, and the destructor's 358 00:17:32.680 --> 00:17:34.119 job is to release the resource. 359 00:17:34.400 --> 00:17:37.240 Ah. So acquisition is tied to object initialization, but the 360 00:17:37.279 --> 00:17:38.559 magic happens at destruction. 361 00:17:39.000 --> 00:17:44.240 Precisely. This automatic cleanup is why some C plus plus luminaries, 362 00:17:44.319 --> 00:17:47.240 as the book calls them, say, the most beautiful instruction 363 00:17:47.359 --> 00:17:50.359 in C plus plus is the closing brace that marks 364 00:17:50.359 --> 00:17:52.559 the end of a scope triggering destructors. 365 00:17:52.640 --> 00:17:56.000 Because it guarantees cleanup even if errors happen exactly. 366 00:17:56.880 --> 00:18:01.359 RAII makes code naturally exception safe. If an exception is thrown, 367 00:18:01.400 --> 00:18:04.519 the stack on wines, scopes are exited, and the destructors 368 00:18:04.559 --> 00:18:07.960 of local objects are still called, ensuring resources aren't leaked. 369 00:18:08.240 --> 00:18:10.160 It's incredibly powerful and robust. 370 00:18:10.279 --> 00:18:13.599 This leads perfectly into smart pointers, doesn't it. Raw pointers, 371 00:18:13.640 --> 00:18:17.000 as we said, don't convey ownership clearly who's responsible for 372 00:18:17.039 --> 00:18:17.640 the delete. 373 00:18:17.839 --> 00:18:21.039 That's the fundamental problem raw pointers pose for resource management. 374 00:18:21.480 --> 00:18:24.720 Smart pointers solve this by encoding ownership semantics directly into 375 00:18:24.799 --> 00:18:27.319 the type system. They wrap a raw pointer and manage 376 00:18:27.359 --> 00:18:29.279 its lifetime according to specific rules. 377 00:18:29.400 --> 00:18:32.599 Let's start with std dot unique ftr std. 378 00:18:32.319 --> 00:18:37.400 Dot UNIQFTR represents exclusive ownership. It's the single clear last 379 00:18:37.519 --> 00:18:41.079 user of a resource. Only one unique FTR can own 380 00:18:41.079 --> 00:18:44.319 a particular object at any time. It's very lightweight, typically 381 00:18:44.359 --> 00:18:48.480 the same size as a raw pointer. Zero runtime overhead Crucially, 382 00:18:48.519 --> 00:18:51.799 it's noncopyable. You can move ownership from one uniquapture to another, 383 00:18:51.839 --> 00:18:54.599 but you can't have two pointing to the same resource, so. 384 00:18:54.599 --> 00:18:56.519 It enforces that single owner idea. 385 00:18:56.680 --> 00:18:59.400 What else it handles a raise correctly if you use 386 00:18:59.440 --> 00:19:02.079 unique toture, and you can provide custom deleters if the 387 00:19:02.119 --> 00:19:04.519 resource isn't managed by a simple delete like closing a 388 00:19:04.519 --> 00:19:07.880 file handle. It's generally your first choice for managing dynamic memory. 389 00:19:07.920 --> 00:19:11.279 Okay, exclusive ownership, what if you need shared ownership? 390 00:19:11.359 --> 00:19:14.440 That's where std dot shared GTR comes in. It's designed 391 00:19:14.440 --> 00:19:16.759 for scenarios where multiple parts of your code need to 392 00:19:16.759 --> 00:19:19.319 share ownership of a resource and the last owner is 393 00:19:19.359 --> 00:19:23.640 not known a priori think complex data structures or maybe 394 00:19:23.680 --> 00:19:24.839 asynchronous callbacks. 395 00:19:24.880 --> 00:19:25.759 How does it manage that? 396 00:19:26.000 --> 00:19:29.519 It uses reference counting internally. It keeps track of how 397 00:19:29.559 --> 00:19:32.599 many shared ptr instances are currently pointing to the same 398 00:19:32.680 --> 00:19:36.240 resource via a shared control block. When a shared ptr 399 00:19:36.319 --> 00:19:38.920 is copied, the count goes up. When a shared PDR 400 00:19:39.000 --> 00:19:41.759 is destroyed or reset, the count goes down. When the 401 00:19:41.839 --> 00:19:44.519