Speaker 1: Welcome to the deep dive. You know, for a lot
Speaker 1: of people, C plus plus has this reputation maybe a
Speaker 1: bit intimidating, right, like this super powerful tool that's also
Speaker 1: well kind of complex.
Speaker 2: It definitely has that aura sometimes. But the reality is
Speaker 2: this isn't some dusty old language.
Speaker 1: No exactly, it's constantly evolving, getting smarter really for today's challenges.
Speaker 2: Absolutely, it's vibrant, it's living, built on this rock solid foundation.
Speaker 2: And for this deep dive, we're cracking open professional C
Speaker 2: plus plus. Think of it like our treasure.
Speaker 1: Map, and where are the guides pointing out the gold?
Speaker 1: Specifically for you, the learner.
Speaker 2: That's the plant. We're pulling out the essentials about modern
Speaker 2: C plus plus from this material.
Speaker 1: Yeah, tracing its journey right from the beginnings to the
Speaker 1: latest features, navigating that big standard library.
Speaker 2: Consider this your express route. We want you to get
Speaker 2: what's significant, what's exciting and C plus plus but without
Speaker 2: getting totally bogged down.
Speaker 1: We're hunting for those aha moments, the practical stuff you
Speaker 1: can actually use.
Speaker 2: Okay, so let's kick off with just how much C
Speaker 2: plus plus has grown. It's pretty striking. Ah So, well,
Speaker 2: you look at the C twenty three standard speck it's
Speaker 2: what under eight hundred pages pretty lean? Okay, Then you
Speaker 2: look at C plus plus twenty three over two thousand pages.
Speaker 1: Whoa, that's a lot more.
Speaker 2: It's not just pages, right, It shows this massive expansion
Speaker 2: in what C plus plus can do. Features piled on features,
Speaker 2: it really cements it as a true superset of C.
Speaker 1: Okay, let's unpack that. The story is C plus plus
Speaker 1: started as C with classes.
Speaker 2: More or less, that was the kernel. Yeah, brings C's
Speaker 2: power together with object oriented thinking.
Speaker 1: And it sounds like it's been on a constant growth spurt,
Speaker 1: evers men's fixing some of C's old issues along the way.
Speaker 2: Precisely, there's share history, some familiar syntax if you know C,
Speaker 2: but the paths have really diverged, and they keep diverging,
Speaker 2: which means even if you know C or Java or
Speaker 2: C sharp, maybe even praython, you've got to stay aware.
Speaker 2: Modern C plus plus has its own unique syntax, new
Speaker 2: features popping up all the time, always something new, right.
Speaker 1: Which leads is perfectly into exploring some of those modern features.
Speaker 1: That new syntax. Now, I saw something about needing a
Speaker 1: special compiler switch to even use the latest stuff.
Speaker 2: Ah. Yes, if you're using GCC the compiler, you'll likely
Speaker 2: need STDC plus plus two B.
Speaker 1: C plus plus two B.
Speaker 2: Yeah, that's the flag right now to unlock C plus
Speaker 2: plus twenty three features. It'll probably become STDC plus plus
Speaker 2: twenty three eventually once things are fully finalized, but for now,
Speaker 2: that's your key to the cutting edge.
Speaker 1: Interesting, and one of those cutting edge things seems to
Speaker 1: be how we even bring in the standard library.
Speaker 2: Something about modules, Yeah, that's a pretty fundamental shift. C
Speaker 2: plus plus twenty three introduces this idea of a standard
Speaker 2: named module. It's just called std.
Speaker 1: Okay.
Speaker 2: The long term goal is you'll just write import std
Speaker 2: and boom, you get the whole standard library, much cleaner,
Speaker 2: more efficient than the old hashtag include way.
Speaker 1: Sounds great, but.
Speaker 2: Compiler support for that single STD module is still well, it's.
Speaker 1: Early days, ah so for now.
Speaker 2: For now, you'll probably still need to import individual bits,
Speaker 2: like if you want the new print functions, you do
Speaker 2: import print.
Speaker 1: Notice the difference. No angle brackets for the main module
Speaker 1: import std, but you use them for specific headers import print.
Speaker 2: Got it. So moving towards cleaner imports, but we're not
Speaker 2: quite there yet. It's still a bit like hashtag include,
Speaker 2: but with import.
Speaker 1: Pretty much for the time being. Okay, now the real
Speaker 1: basics numbers, characters, int, double char, has anything changed in how.
Speaker 2: We declare those The types themselves, the fundamental ones are
Speaker 2: the same, but how you initialize them. Modern C plus
Speaker 2: plus really pushes for uniform initialization using curly braces, so.
Speaker 1: Like int ii eleven instead of into ee eleven exactly.
Speaker 2: And the nice thing is that syntax works consistently everywhere
Speaker 2: for all types and all sorts of situations. It helps
Speaker 2: avoid some old weird ambiguities.
Speaker 1: Makes sense. Consistency is good.
Speaker 2: And we also have newer character types like chart char sixteenth,
Speaker 2: chart thirty two. Handling different unicode encodings properly super important Nowadays.
Speaker 1: Bedifort initialization sounds more predictable, easier to read. Now I
Speaker 1: saw some other let's say, unusual syntax, something with double
Speaker 1: square brackets. Fall through.
Speaker 2: Yes, fall through, that's an attribute you use it inside
Speaker 2: switch statements. Okay, well, you know how in C plus
Speaker 2: plus C if you forget a break in a case,
Speaker 2: execution just falls through to the next one.
Speaker 1: Yeah, that can cause nasty bugs.
Speaker 2: Right, but sometimes you want it to fall through, so
Speaker 2: fall through is like putting up a big sign saying, compiler,
Speaker 2: I meant to do this, no bug here makes the
Speaker 2: intent super clear.
Speaker 1: Oh okay. Explicitly saying I know there's no break and
Speaker 1: that's okay makes sense for clarity. What about I think
Speaker 1: they called it this spaceship operator.
Speaker 2: That's weird, the spaceship operator. Officially, it's the three way
Speaker 2: comparison operator. It's fantastic.
Speaker 1: Why is that?
Speaker 2: Because it does all six comparisons less than, greater than,
Speaker 2: equal to, not equal to, less greater than or equal
Speaker 2: all in one go. Really, how it returned turns a
Speaker 2: special result, often a type like strong ordering. The value
Speaker 2: tells you if the first thing is less, greater or
Speaker 2: equal to the second, okay, And it's smart for things
Speaker 2: like floating point numbers where you have magnan not a number.
Speaker 1: Which isn't really lesser greater than anything exactly.
Speaker 2: The spaceship operator can return a partial ordering for those
Speaker 2: acknowledging they aren't strictly comparable. It's a game changer for
Speaker 2: writing generic comparisons. Plus, the compiler can often autogenerate all
Speaker 2: six comparison operators for you if you define just this
Speaker 2: one less code fewer mistakes.
Speaker 1: Wow, okay, one operator all the info even handles trippy
Speaker 1: stuff like nan powerful now functions. I saw a note
Speaker 1: about empty parameter lists. Any change there.
Speaker 2: Yeah, small simplification in C plus plus A if a
Speaker 2: function takes no parameters, just use empty parentheses void my function.
Speaker 1: No need for void inside the parentheses like in some
Speaker 1: older SEA styles.
Speaker 2: Nope, not needed. But crucially you still must use void
Speaker 2: for the return type if the function doesn't return any thing.
Speaker 1: Got it empty for no input, void return for no output.
Speaker 1: Simple enough? What about text? We still stuck with those
Speaker 1: tricky C style character arrays?
Speaker 2: Thankfully no. Modern C plus plus gives us STD dot string.
Speaker 2: You get it from the string header and that's better
Speaker 2: because oh it's miles better, easier, safer. You can assign text,
Speaker 2: join strings, access characters easily, all without the manual memory
Speaker 2: management headaches of char It basically EXE a built in type.
Speaker 1: Now anyone who's undered a null terminator bug will appreciate that. Yeah, okay,
Speaker 1: so C plus plus is clearly more than just a
Speaker 1: better see it's properly object oriented. Quick refresher, what's the
Speaker 1: core idea there? In modern C plus plus? Go right?
Speaker 2: Oop object oriented programming. It's a shift from just thinking
Speaker 2: about sequences of actions. You think about objects.
Speaker 1: And objects are.
Speaker 2: They bundle data? They're attributes and the functions or methods
Speaker 2: that work on that data. In C plus plus A,
Speaker 2: the blueprints for these objects are classes.
Speaker 1: Okay, and where do we define these classes? Now? With
Speaker 1: modules and all.
Speaker 2: Often you'll define them in modern interface files. These usually
Speaker 2: have a dot CPPM extension. Then you explicitly export the
Speaker 2: module and the class definitions you want others to use.
Speaker 1: So the dot CPPM file is like the public facing
Speaker 1: design exactly.
Speaker 2: Imagine a module airline ticket. Inside you export class airline ticket.
Speaker 2: It would have public stuff functions like calculate price end
Speaker 2: dollars or get passenger name, things.
Speaker 1: You can call from outside right, and.
Speaker 2: It would have private members. The internal data like in
Speaker 2: passenger name or number of miles hidden managed internally. That's encapsulation,
Speaker 2: bundling data and functions, controlling access.
Speaker 1: Public private classic oop. Got it. When we create one
Speaker 1: of these airline ticket objects, how do those private data
Speaker 1: members like number oh miles get their starting values?
Speaker 2: Modern C plus plus has in class initializers. Write in
Speaker 2: the class definition you can give a data member a
Speaker 2: default value oh neat Yeah, Like in an employee class,
Speaker 2: you could write in salary seventy five thousand right there.
Speaker 2: If you create an employ object without specifying a salary,
Speaker 2: it gets that default. If a basic type doesn't have one,
Speaker 2: it usually gets zero. Initialized helps ensure objects start in
Speaker 2: a known state.
Speaker 1: Setting defaults right where you declare them. Seems handy. Okay,
Speaker 1: let's tackle a topic that sometimes makes people nervous. Pointers
Speaker 1: and references. How do they fit into modern C plus
Speaker 1: plus sac has that changed much?
Speaker 2: Coiners are still around, definitely needed for low level stuff
Speaker 2: or interacting with C libraries, but modern C plus plus
Speaker 2: really encourages minimizing manual pointer use, especially for memory ownership.
Speaker 1: Right less direct fiddling with memory addresses exactly now.
Speaker 2: With constant pointers, there's a useful rule. Const applies to
Speaker 2: what's immediately to its left. If there's nothing left, it
Speaker 2: applies to their right. It constan applies left unless it's
Speaker 2: at the very beginning. So in const ptr means a
Speaker 2: pointer to a constant integer. You can change where ptr points,
Speaker 2: but not the in value via ptrh And.
Speaker 1: In const ptr, yeah.
Speaker 2: Const is to the left of ptr. So it's a
Speaker 2: constant pointer to a non constant integer, you can change
Speaker 2: the NS value, but you can't make ptr points somewhere else.
Speaker 2: And in constant ptr both constant pointer to a constant
Speaker 2: integer can't change the in value, can't change where the
Speaker 2: pointer points. That finer control helps right safer code.
Speaker 1: Constant plies left. Okay, that's a good knemonic. What about references?
Speaker 1: They feel similar to pointers, but different they are different.
Speaker 2: Think of our reference as an alias, just another name
Speaker 2: for an existing variable. When you say nten x, refix
Speaker 2: x ref is x.
Speaker 1: The key thing.
Speaker 2: Once a reference is initialized, it cannot be changed to
Speaker 2: refer to a different variable. Ever, you can change the
Speaker 2: value of the variable it refers to if it's not
Speaker 2: a constant reference, but the referance itself is.
Speaker 1: Stuck and references to constant like.
Speaker 2: Constant in treface. Some ind they're simpler in a way
Speaker 2: because the reference itself is implicitly constant regarding what it
Speaker 2: refers to, and you can't change the value through it.
Speaker 1: Okay, So when do you pick a pointer versus a reference?
Speaker 1: In modern code?
Speaker 2: It mainly for dynamic memory you get from new you
Speaker 2: need a pointer to hold that address. Also, if you
Speaker 2: need something that might be null and optional value pointers
Speaker 2: can be null, ptr references.
Speaker 1: Can't, and polymorphism yep.
Speaker 2: Storing different derived types via a base class pointer in containers.
Speaker 2: But the big thing about ownership modern C plus plus
Speaker 2: is avoid raw pointers for owning memory. Use smart pointers instead.
Speaker 2: We'll get to those so smart.
Speaker 1: Pointers handle the ownership when our reference is the better choice.
Speaker 2: Often for function parameters, if you need to guarantee the
Speaker 2: function gets a valid object. References are great because they
Speaker 2: can't be null and if the function might modify the
Speaker 2: object and it's not a constant reference. They often lead
Speaker 2: to cleaner syntax too.
Speaker 1: It's like a variable as a house. A reference is
Speaker 1: a nickname for the house. A pointer is the address
Speaker 1: on a piece of paper. You can change the address
Speaker 1: to point to a different house.
Speaker 2: That's a great analogy. References are bound to one house.
Speaker 2: Pointers can be retargeted.
Speaker 1: Smart pointers definitely sounds like the way forward from memory. Okay,
Speaker 1: zooming out best practices for writing good C plus plus code.
Speaker 2: Overall several things. One use getters and setters, accessor and
Speaker 2: mutator methods, even to access data members within the same.
Speaker 1: Class, really even inside the class.
Speaker 2: Why it gives you a layer of abstraction maybe later
Speaker 2: you need to add validation or change how the data
Speaker 2: is stored internally or log access. Using methods means you
Speaker 2: can change the implementation without breaking how other parts of
Speaker 2: the class use the data.
Speaker 1: Ah, future proofing makes sense. What else?
Speaker 2: Clear code structure? Breakdown functions? Seriously, if a function does
Speaker 2: three different things, it should probably be three functions. Makes
Speaker 2: it easier to read, test, maintain single responsibility principle.
Speaker 1: Basically, smaller focused functions. Got it right. What about naming
Speaker 1: things variable names? I've seen debates about prefixes like M
Speaker 1: for members.
Speaker 2: Yeah, that's a bit contentious. Prefixes like M or G
Speaker 2: or ptr. Some find them helpful, but the modern trend
Speaker 2: is often against them. Why they can hurt maintainability. If
Speaker 2: you change a variables type or scope, you have to
Speaker 2: remember to change the prefix everywhere miss one and the
Speaker 2: name becomes misleading. Better to choose names that clearly describe
Speaker 2: the variable's purpose, not just its type. The compiler knows
Speaker 2: the type.
Speaker 1: Focus on purpose, not type hints in the name. Okay, okay.
Speaker 1: We also said references are often safer than rob pointers.
Speaker 1: Any common mix ups there, especially with function calls.
Speaker 2: Yeah, A big one is thinking that seeing an ampersand
Speaker 2: in a function call automatically means the original variable will
Speaker 2: be changed, or that no ampersand means it won't be changed.
Speaker 2: That's not true, not necessarily. You have to look at
Speaker 2: how the parameter is declared in the function's definition. Is
Speaker 2: it TN non constant reference consts TNT non constant pointer
Speaker 2: const T Only the const versions guarantee no modification through
Speaker 2: that parameter. The call site syntax alone doesn't tell the
Speaker 2: whole story.
Speaker 1: Okay, crucial distinction. Look at the function declaration, not just
Speaker 1: the call. Got it shifting gears? Planning? How important is
Speaker 1: designing stuff before writing c P plus plus code?
Speaker 2: Hugely important, especially for bigger projects. It's like needing blueprints
Speaker 2: before building.
Speaker 1: A house avoids chaos exactly.
Speaker 2: Design helps define how parts interact, who's responsible for what,
Speaker 2: how requirements are met. Without it, you risk missing connections,
Speaker 2: missing chances for code reuse, picking inefficient solutions. It's the
Speaker 2: big picture and it's documentation.
Speaker 1: But what about agile ideas like working software over comprehensive documentation.
Speaker 2: Good point, It's a balance. Agile doesn't mean no documentation.
Speaker 2: You still absolutely need up to date design docs for
Speaker 2: the key architectural stuff. Essential for the long run.
Speaker 1: Okay, finding that balance? What are some core design principles
Speaker 1: C plus plus dev should really internalize.
Speaker 2: Two huge ones, abstraction and reuse abstraction?
Speaker 1: First, what's the essence.
Speaker 2: Designing so users of your class or function interact via
Speaker 2: a clear interface without needing to know the messy internal details.
Speaker 2: Like the chessboard example. Earlier you make moves, you don't
Speaker 2: need to know if the board is totor or does
Speaker 2: an array or pointers or whatever implementation hidden?
Speaker 1: Hide the complexity behind a clean interface and reuse.
Speaker 2: Just like the baking analogy, you don't build an oven
Speaker 2: every time you bake a cake. Right reuse means actively
Speaker 2: looking for existing code libraries, frameworks, your own pass code
Speaker 2: that does what you need. Saves massive time and effort,
Speaker 2: usually leads to more robust code because it's already tested.
Speaker 2: Don't reinvent the wheel if a perfectly good one exists.
Speaker 1: Makes total sense. But how do you choose what to reuse?
Speaker 1: Picking the right library?
Speaker 2: Say good question? First, Really understand its capabilities and its limitations.
Speaker 2: Read the docs, study the API. If you can look
Speaker 2: at the source, talk to people. Definitely ask other devs
Speaker 2: who've used it. What are the strengths, weaknesses, any traps.
Speaker 2: Get the core idea, then think about your specific needs.
Speaker 1: Understand it fully, read the manual, ask around solid advice now.
Speaker 1: The source mentioned a mental shift moving from procedural thinking
Speaker 1: to object oriented thinking. How does that usually happen?
Speaker 2: Often there's an aha moment. Programmers start seeing how data
Speaker 2: and the functions that act on it naturally belong together
Speaker 2: in well classes.
Speaker 1: At lays they're grouping things.
Speaker 2: Yeah, some might refactor existing procedural code bit by bit,
Speaker 2: turning related stuff into classes. Others might dive straight into
Speaker 2: an O design for a new project. The source notes
Speaker 2: two main approaches using classes selectively we're convenient or building
Speaker 2: the whole system around interacting objects from the start. No
Speaker 2: single right path, but understanding the benefits is key.
Speaker 1: A spectrum then from tactically used to full adoption. What
Speaker 1: about going too far the other way? Designing classes that
Speaker 1: are too general?
Speaker 2: Ah, the overly general class. That's usually a bad sign.
Speaker 2: Trying to make one class handle too many unrelated things like.
Speaker 1: The media organizer example, photos, music, movies, journals all in one.
Speaker 2: Class exactly, It ends up confusing, hard to understand, hard
Speaker 2: to use generic properties like data a performed method that
Speaker 2: does wildly different things. It's better to have specific classes,
Speaker 2: each representing one clear concept.
Speaker 1: One class to rule them all usually rules none of them.
Speaker 2: Well, gotcha? How do classes relate to each other? The
Speaker 2: source mentioned has.
Speaker 1: A and is a fundamental relationships, has a is composition
Speaker 1: or containment. One class holds an instance of another as a.
Speaker 2: Member, like car has an engine.
Speaker 1: Perfect example. The engine is a component is inheritance. A
Speaker 1: derived class is a specialized version of a base class.
Speaker 1: Sports car is a car. It gets all the car stuff,
Speaker 1: maybe adds more specific things.
Speaker 2: Has a for components, is a for specialization. Clear? What's
Speaker 2: the main win from using inheritance code reuse?
Speaker 1: Primarily the derived class automatically gets the base class members
Speaker 1: and functions, no need to rewrite common stuff. It works
Speaker 1: best when the base class defines a common interface maybe
Speaker 1: abstract the derived classes implement.
Speaker 2: You need to be careful. Yeah, if a derived class
Speaker 2: ends up overwriting or changing most of its parent stuff,
Speaker 2: maybe inheritance wasn't the right fit. There is a relationship
Speaker 2: should feel natural?
Speaker 1: Makes sense. The source also mentioned multiple inheritance C plus
Speaker 1: plus allows.
Speaker 2: That it does. A class can inherit directly from more
Speaker 2: than one base class. The example was maybe an animal base,
Speaker 2: then hierarchies for size, diet movement. A dog bird could
Speaker 2: inherit from dog like and bird like bases.
Speaker 1: Sounds potentially complicated.
Speaker 2: It can be, especially with the diamond problem. If a
Speaker 2: class inherits from two classes that both inherit from the
Speaker 2: same grandparent class, you get ambiguity. Which grandparent member do
Speaker 2: you use? C plus plus has mechanisms like virtual inheritance
Speaker 2: to solve it, but yeah, it adds complexity, needs careful handling.
Speaker 1: The diamond problem something to watch out for. Okay, beyond
Speaker 1: reuse and abstraction any other key design principles C plus
Speaker 1: plus dev should keep front.
Speaker 2: Of mind definitely clear code structure. Like we said, usable
Speaker 2: interface is intuitive for others to use, balancing generality versus specificity.
Speaker 2: Don't make it too complex by trying to handle everything,
Speaker 2: but don't make it so specific it's inflexible and all
Speaker 2: to principles five core OO design guidelines for maintainable flexible code.
Speaker 2: We won't dive deep into solid now, but they're worth learning.
Speaker 1: Lots to think about for good design. The source used
Speaker 1: a cool analogy for the strategy pattern interchangeable parts like
Speaker 1: a car and its engine. Can you expand on that?
Speaker 2: Yeah, that illustrates it well. Instead of hard coding engine
Speaker 2: logic inside the car class, the strategy pattern says, define
Speaker 2: a separate engine interface or base class. Maybe have gasoline
Speaker 2: engine electric engine.
Speaker 1: Implementations, and the car just holds one.
Speaker 2: Right, the car class holds a pointer or reference to
Speaker 2: some kind of engine. This makes it super flexible. You
Speaker 2: can swap engine types easily, maybe even at run time,
Speaker 2: without changing the car class itself, just like real cars.
Speaker 2: Modularity adaptability design for swappable parts makes software more flexible.
Speaker 1: Okay. Template programming now the huge C plus plus feature
Speaker 1: design considerations there.
Speaker 2: Templates let you write code parameterized by type. Think std
Speaker 2: dot vectorant and std dot vector double. Same vector code.
Speaker 1: Works for both once, use it for many types.
Speaker 2: That's the core idea. Create generic classes or functions that
Speaker 2: work with different data types without duplicating code. It can
Speaker 2: get really advanced, but even basic templates give huge wins
Speaker 2: for reuse and flexibility, like a single sort template sorting,
Speaker 2: ince double strings, anything comparable. We'll dig into writing custom
Speaker 2: templates later.
Speaker 1: Generic code adapting to types powerful stuff. Now shifting to
Speaker 1: safety and robustness. How do we design C plus plus
Speaker 1: code to be reliable?
Speaker 2: It's about proactively building in checks and safeguards. How do
Speaker 2: you use signal errors instead of just magic numbers or
Speaker 2: error codes? Modern clus plus has better tools like what
Speaker 2: std't at optional for values that might be absent, forces
Speaker 2: the caller to check, or exceptions for more serious errors
Speaker 2: the current code can't handle. Let someone else catch and
Speaker 2: deal with it. We'll cover exceptions more soon. The main
Speaker 2: thing is anticipating problems and handling them gracefully, not just crashing.
Speaker 1: Be proactive, use the right tools like optional or exceptions.
Speaker 2: Got it? The source also distinguish between internal contracts and
Speaker 2: external APIs what's the difference?
Speaker 1: Important distinction. An internal interface is the contract between parts
Speaker 1: of your own code, how your modules talk to each other.
Speaker 1: An API application programming interface is the public contract for
Speaker 1: other developers, maybe outside your team or company, to use
Speaker 1: your library or product.
Speaker 2: So APIs need more care.
Speaker 1: Much more people rely on public API staying stable. Breaking
Speaker 1: changes can wreck other people's code, so careful planning documentation,
Speaker 1: maybe talking to users is crucial before exposing an API.
Speaker 1: Internal interfaces allow a bit more flexibility since you control
Speaker 1: all the pieces. Think household rules versus city laws.
Speaker 2: Internal rules versus public laws. Good analogy. Okay, let's dive
Speaker 2: into something that often trips people up, dynamic memory management.
Speaker 2: What's the modern guidance.
Speaker 1: Strong advice Avoid low level manual memory stuff as much
Speaker 1: as you possibly can.
Speaker 2: Steer clear of raw pointers, owning memory allocated with new
Speaker 2: avoid old C functions like malik and free. Instead, lean
Speaker 2: heavily on safe C plus plus features and the library like.
Speaker 1: Std dot string, std dot vector.
Speaker 2: Exactly and crucially smart pointers for dynamically allocated objects. Let
Speaker 2: the language and library manage the memory for you.
Speaker 1: Minimize the manual juggling. Rely on RAII. What's RAI again? Quickly?
Speaker 2: Resource acquisition is initialization tie a resources lifetime memory file
Speaker 2: handles sockets to an object's lifetime. Object created, acquire a
Speaker 2: resource and constructor. Object destroyed goes out of scope, maybe
Speaker 2: due to exception, release resource and.
Speaker 1: Destructive, so automatic cleanup pretty much.
Speaker 2: The destructor is guaranteed to run when the object's lifetime ends.
Speaker 2: If the destructor releases the resource, like calling delete on
Speaker 2: memory allocated in the constructor, leaks become virtually impossible. It's
Speaker 2: fundamental to modern C plus plus rid.
Speaker 1: RAI resource life tied to object life robust.
Speaker 2: So why is avoiding manual management so vital? What's the
Speaker 2: big danger?
Speaker 1: Memory leaks the absolute classic C plus plus nightmare.
Speaker 2: All memory with new, but you forget or fail to
Speaker 2: delete it later, that memory just sits there, allocated but unusable.
Speaker 2: Accumulate enough leaks, Your program eats, memory slows down, gets unstable,
Speaker 2: maybe crashes. The source had that simple leaky function. Example
Speaker 2: new int then return poof memory orphaned.
Speaker 1: A slow death for your app. So if you must
Speaker 1: use new.
Speaker 2: The absolute rule, every new needs a matching delete. And
Speaker 2: if you use new to allocate an array you new delete,
Speaker 2: you absolutely must use delete. Mismatching new delete or new
Speaker 2: delete is undefined behavior bad news, stack arrays by the way,
Speaker 2: or manage automatically no delete needed or allowed. The danger
Speaker 2: is the heap the free store managed with.
Speaker 1: Rematches, delete, new, matches delete, got it, But modern C
Speaker 1: plus plus pushes us away from that. How do RAII
Speaker 1: classes like vector and the smart pointers.
Speaker 2: Help STD string, std dot vector They are RAII internally
Speaker 2: they manage their own dynamic memory. When a vector object
Speaker 2: goes out of scope, its destructor runes and automatically frees
Speaker 2: the memory it was using. You don't touch new or
Speaker 2: delete yourself for its contents.
Speaker 1: The object handles its own cleanup. Nice and smart pointers.
Speaker 2: They bring RIII to any dynamically allocated object their classes.
Speaker 2: Wrapping a raw pointer.
Speaker 1: Like std dot uniquetr.
Speaker 2: Right uniqueptra means exclusive ownership. Only one uniquepture owns the object.
Speaker 2: When that uniqu capture eyes, the object gets deleted. Simple
Speaker 2: clear ownership.
Speaker 1: And std dot shared ptr.
Speaker 2: Allows multiple owners. It keeps a reference count. The object
Speaker 2: is only deleted when the last shared ptr pointing to
Speaker 2: it goes away. Useful when ownership is naturally shared.
Speaker 1: Automatic deletion via RAI rappers exactly.
Speaker 2: The source even showed using shared ptr with a custom
Speaker 2: deleter to manage a C style file handle from fopen
Speaker 2: when the last shared ptr went away. The custom delet
Speaker 2: called f close automatically, very flexible for managing all sorts
Speaker 2: of resources, especially from older APIs, though C plus plus
Speaker 2: filestreams do this automatically too.
Speaker 1: Smart pointers seem incredibly useful for safer C plus plus PI. Okay,
Speaker 1: we've hit a lot modern features op safer memory management.
Speaker 1: When we continue, we'll go deeper into classes inheritance, modules
Speaker 1: versus headers, templates, and then tackle a huge C plus
Speaker 1: plus standard library containers, algorithms, io exceptions, and more. Stick
Speaker 1: around for part two of our deep dive into professional
Speaker 1: C plus plus buy