I completely agree with the idea of knowing how things work behind the scene! Please make videos about: 1- Move semantics 2- Exception handling 3- V-table 4- Some videos about Template Metaprogramming Keep it up man!
Yes! Including when to change the syntax of the language with the preprocessor and when to leave it alone. Changing the syntax of C++, was how my first language worked. The code for it is now gone though. That was before working on PNF, but just barely. So, I was age 15.
You look exhausted speaking about this. Don't put too much on yourself. We love your content and you're doing an incredible job. Take care of yourself so you can keep making such great work and enjoying it!
I began my learning c++since I was 15 years old, which was 18 years ago (I'm 33yrs). And I'm your side on this one, I do not see all this fuzz about not using smart pointers. Also, I want to thank you a lot for this whole series, I have complete it today and it has been by far the best c++ course/series that I have seen in my life! (even paid ones). You are exactly the teacher or friend that I always want it. Most people that I have meet in all this years have always demonised something without any good reason, but as a Game Developer (that's why I'm), I should say that you speak the real truth here and that's how you need to teach anyone. Basically tell the people how to learn the basics at it's core. I even believe that the deepest you go, the better you understand what it's above it. The more I know C++... I want to go deeply into C or even assembly, because you understand better. That's the way to go with low level programming languages I believe. Thank so much for all his series!
I think once you know enough of a language to be comfortable (or even a little early), would be important to program assembly of an old processor, because assembly is truly how computer works. And there is a lot of emulators online for old processors with few instructions, so it is easier to program these. I think assembly is what can teach people about why people use certain terms on datas, programming paradigms and etc... Like, "how to make a float"? I also recommend to get a DOS emulator and use Borland C++... It is basically C with classes indeed, haha... Also, the 'int' is a short, and if you declare 'for (int n...', the 'n' will keep alive after the 'for' scope. Eventually you come across a C library and it is good to know what C is doing.
I just wanted to say, I've been learning C++ from a lot of resources lately and even though I use all of them and there's a ton of knowledge spread across the Internet you're so far the best one I came across - clear, in-depth, concise. Keep up the great work!
Totally agree, I believe it's very important to know how stuff work behind the scenes because when things break/don't work as expected, having that knowledge is what distinguishes a good programmer from an average one :)
I started learning C++ from your videos. I'm 57 years old and have wanted to learn C++ for about 20 years, but never got around to it. I'm now up to the point where I'm working my way through Win32 GUI programming and the enormous mess that that entails. Mixing Win32 C-style code along with C++ code would have been a LOT more difficult without the knowledge I got here, and specifically, the low level knowledge of what the system is doing is a godsend. Not many people even mention the things you talk about, such as linking, memory fragmentation, scope etc.
Im studying physics in germany right now and one of my classes is programming. I started with python and in the following class (Introduction in software engineering) we will use c++. I wanted to prepare myself for the class and thererfor am watching your series. I feel like I could already write the tests of our exams, without the semester having started yet(we shall see when that happens, due to the current circumstances). With this comment I wanted to show you that you are helping people around the world with your channel and it is greatly appreciated! Thank you for your time and effort and as you mentioned this is your channel, teach the way you think is the best! Great channel, great person and great series! (I watched every single video(71/84) at least once and am looking forward to all the other content on your channel!
The STL is SO powerful, but very rarely taught. It also makes you appreciate the language much more, at least in my case. Video on that would be great! Thanks for the great content
This channel focuses on bare c++ which is great because it clears a lot of misunderstanding of the language and how you use it, but there are already too many videos and documentation on data structures and algorithms. I don't expect him to make a series on that topic, but once you really get a grasp on the language, covering algorithms and any other topic is really just a walk in the park. Either way, it's pretty cool.
15:00 You really hit the nail on the head with this closeout statement. My boss, IT guy, and C++ Professor said the same things. They compared it to leaving the door open in your house or having someone come wipe your nose for you. You should understand the underlying constructs before you learn the tools that allow you to shortcut.
A few thoughts. First, 100% agreed that raw pointers SHOULD be taught, whether before or after smart pointers is up for debate, but there will be times a unique pointer or smart pointer (whether the ones in memory or writing your own/using something out of boost). That's how you become a master of your tools. Second, on your point about one off apps, you are more comfortable writing with raw pointers probably because that's what you learned first, and maybe what you've done more but I haven't seen your code (beyond this series and the OGL series) so I don't know. That makes it an interesting consideration that perhaps even on those you SHOULD use smart pointers simply to make it so you are more comfortable with them so that you always choose the "logical" choice for which to use in all applications, not simply "oh this is production code? default to smart pointers unless a reason comes up not to."
Agreed on this ... The only reason I'm looking at these videos because you go in depth with everything (C style and C++) - Sometimes you use Structs sometimes classes, sometimes you use Const char* x instead of std::string etc ... the whole aim of this is going towards mastering the language really and really understand how things work behind the scene. Cheers Cherno !
As someone with some previous programming experience going through this series, I actually heavily appreciate the fact you showed us lower level constructs instead of telling us the best way to do things only, it's important to understand how the abstractions we're working with were built, not only just for the understanding, but also if we want to build something similar ourselves. This series gets some unwarranted flack on places such as Reddit, you did a great job with it and I'm glad I have this course to learn from.
Folk, after doing this for more years than I care to admit to, I find that these types of discussions tend to shed more heat than light. In the end, however you write your memory management code and however you use it, so long as it doesn't crash and you clean up after yourself, then you've done your job. Period. Anything beyond that is preaching.
I find it hard to agree to what you are saying. Most of the times when we write code it will be read, used and changed by other people. Our goal when writing code is to write code that is clear, hard to make mistakes with and hard to introduce bugs into. Using smart pointers over raw new/delete (and in general utilizing RAII for resource management) removes an entire category of mistakes your peers can make while working with the code you provided. Given that our job isn't done when our code is merged, I disagree with your conclusion.
This logic can be reduced to "if it works, it's good". Maybe overly reductive but it highlights the flaw in the logic whenever we shine a light on legacy and disastrous projects which do, in fact, have working code, but calling it "good" couldn't be further from the truth.
Absolutely agree. It is stupid to write cumbersome code out of pride so you can say you are a pure hearted C programmer. Not all of your code need to be highly optimized and super fast. Sometimes your code has to be fast, and sometimes the programmer has to be fast. These newer features might slow your code down but definetly speed you up as a developer, and it is important to know when it is worth it to go the long route and optimize for performance. That being said the best way to know when to use what, is by having a deep understanding of how things work on the lowest level. Which is why you definetly should teach normal pointers in every C++ course.
I learned Opengl ( at least the fundamentals) from him in a week, i work of course, but as a hobbyist I am also ready to learn more about game structure
I absolutely love knowing how everything works at the underlying level of it all, and your videos have been a genuinely enlightening experience and I've never been so excited to get more into programming in my life before. As for the smart vs raw pointers thing, "There is a time and place for everything". People saying you should only use the best and safest and fastest code in a tiny sandbox test project is like saying you should never use debug build mode because it's slow. Be reasonable, people.
I generally use raw pointers in one and only one situation, as private class internals for custom data structures. In such cases I make sure that the pointer is fully managed by class in question. Not that such custom classes are commonly used, but there are cases when a custom class of this nature can be very useful. For example, normally I'd probably use STL these days, but there can be cases in which a specialty class is useful. The two exceptions to this rule are when dealing with libraries / frameworks that require them (Qt uses them extensively, but it written in such a way as to manage them for you). The other, very rare, case is when I need a very small function to process a C string in some way, such as to quickly hash it, in which case the function takes the pointer as a parameter and isn't using it long. I've had fun and learn a whole lot (including some humility) working on my own libraries, but there are only a few niche cases where I think I'd actually use them -- but I make no apologies for using raw pointer in it, after all STL stuctures do the same.
The reason why I value the channel and your teaching methods is as you've said to understand what's going on under the hood. To me it serves no purpose to learn sugar coated syntax alone, if for no other reason than to understand legacy code, and secondly to help problem solve coding issues. A fantastic series of which i'm greatly appreciative of. Thanks.
At 10:10 is a nice explanation of why the design of Rust is so good. In Rust, the default way, the lazy way of doing things is using the smart pointers. You need to jump through hoops, put in extra effort if you want to use raw, C style pointers, and if you do so, your code will look less clear. In Rust code with smart pointers looks cleaner than code with raw pointers. Also, in general when you are programming in Rust, the default lazy ways of doing things are what is correct majority of the time and you need to jump through hoops in order to write unsafe C style code. You see this same story with dealing with null as well. The only way to have something like a null in Rust is to use an Option (like optional in C++) or to write your own Optional. Yes, you can unwrap an Option unsafely, but you need to consciously do so, you can't forget to check for null. Also, this makes it explicit in the code where dealing with the null case has happened.
I totally understand where you are coming from. I had a professor who forced us to only use C++ pointers and manage our own memory. I like having that option to choose smart pointers or native pointers depending on the given scenario. Thanks for the insight 👍
i agree with you. if one want to be good, then he needs to know how it works, pretty much on all the things he used. cannot be scared by raw ptr or smart ptr. The only thing we need is to understand what they are and when to use them.
The problem is that many people tend to turn good advice into religion. Then they forget the reasoning behind the advice and follow it dogmatically. Telling a beginner to avoid raw pointers and use smart pointers instead is generally good advice. But that doesn't mean that raw pointers must be avoided at all costs. C++ is a large tool box and if you know the purpose and limitations of your tool, it's totally fine to use it. Unfortunately, there are a lot of those C++ related religions -> "Don"t use STL containers for games" "OOP is dead" "Raw pointers are evil" "Don't use singletons" "Don't use macros" ... and many more. While all those are or were based on some good reasons, you should never trust these statements blindly. Know the reasoning behind them and then decide which tool is the best for your use-case.
Hi, Min 8:58. I wanted say that using raw pointers IS NOT STUPID AT ALL. If the software is well designed there is no need to use smart pointers. Furthermore, if the developer is a beginner or if the project is a prototype or where the requirements of project are still not clear then it makes sense. I like this channel. Regards.
I don't think the need of smart pointers has to do with bad software design. Sometimes you require dynamic objects, and if so, someone needs to own it.
I agree with you 100% Cherno. You give a full understanding of how c++ works. Its not your responsibility to insure other peoples logic is sounds. You are giving a strong base of information to make the coding decision that are ultimately up to the programer.
100% agree with what you said here. I can sense that you are trying to teach and really want the viewers to understand the fundamentals instead of showing off your knowledge of C++.
I'd say for one to be able to appreciate the value that smart pointers add to the quality of the software, one has to go through the journey of using and managing the raw pointers. We've made it a guideline in our project not to use raw pointers. I'd anyday let go a bit of performance for more stable, maintainable, scalable, working software. It's just one less thing to worry about so you can focus on other things better.
Totally agree, you'v got to know your basics right. Then only you'll be able to understand how things work internally. Just want to congratulate on this channel and I loved every single video in this c++ series and the way you teach every concept. I am new to this whole programming world. Gotta go a long way................! Thanks Cherno.
Well I am but a beginner in c++ and what amazed me most about this language is how close it is to assembly language and memory management unlike what I’ve worked with before and I absolutely love it so I think raw pointers are what good to start people in c++
In my experience in C the main causes for memory leaks are weird return points, mostly from error checking. This can become very hard to deal with properly when you have a complicated function that has different things allocated and freed in different parts of the program. Personally I am way more comfortable with raw memory management and things of that nature than I am with the more advanced abstractions in C++.
That's because you haven't tried them enough. The best programmers in the world can't help but create memory leaks with C pointers. With smart pointers the only way to screw up memory management is if you have circular referencing (or if you have a reference to an object and you screw up the lifetimes. This mistake can happen in C as well though).
I'm a student attending university at the moment with a class coming up that, supposedly, will rely a lot on C++. I've only been taught how to use C and Java in the past, so I wanted to use this summer to hone in on the core values of good C++ programming before jumping into another school quarter, which is usually way too quickly paced to help learn the fundamental, deep interworkings of programming languages, like what you've decided to focus on in this series. I'm also training to enter the games industry, and until stumbling across this series, I haven't been taught the various methods and tools that can be taken advantage of to optimize applications, the very concepts that will enable me to work with teams to create complex, inspiring games that take advantage of everything their hardware has to offer. I greatly appreciate this series as well as it's discussion-centric videos, like this one, that bring into question the practices and disciplines we need to keep in mind when educating ourselves and others. Thanks a ton.
You asked for opinions so... If you "just want to try something out" then use shared_ptr and pass by value, which is how you use raw pointers most of the time anyways. But that's besides the point. The smart pointers offer exception safety in terms of RAII and reinforce that programming paradigm. Once you start going down the new/delete approach, you'll probably start taking shortcuts elsewhere and end up falling into try/catch (or not even doing that) to cleanup your "just try it" program. If you want to write C, then you might as well add the whole goto out_free and out_unlock fun while you're at it; which is what destructors do for us in C++ (and I only have to write it once!). We are what we do, try not to create anti-pattern habits for yourself. The most powerful and fundamental things C++11 did for us IMHO is the standardized memory model, fixing std::allocator, and move semantics. If you don't start thinking in terms of move semantics and scope based management then you are capping your potential as modern c++ designer. Otherwise you should probably consider switching gears to Java or golang and enjoy being a victim of a mark and sweep based memory managed language, but you will write more code. Great video. Thanks.
Just another person way too afraid of raw pointers. A good programmer should be able to deal with raw pointers and manually automate the deletion (like in destructors for example).
You need more likes. Your presentation of usually esoteric dry detail is clear, entertaining, simple and teaches so much in a short time. You have a gift.
agree! raw pointers should be taught even in real industrial project, they are not used often. Raw pointers r super helpful to touch the memory concept which is crucial in programming especially C++ ! Raw pointers should only play in terms of beginner study, but in work, avoid raw pointers as much as you can.
One main advantage of using smart pointers is exception safety. If an exception is thrown before you call delete, then it will not get freed and thus leak. Smart pointers guaranteed to clean up memory always.
This series has made my C++ game alot better! I sincerely hope you haven't stopped it :) Id like to know more about topics like binding and scoped locks together with using a mutex.
@TheChernoProject I think something that can help in this discussion is talking more in depth about memory management. I don't know that I've ever heard the exact phrase "be a man and manage your own memory", directed to me or to others, but I get what your saying. The thing is, depending on your knowledge of different programming techniques, "manual memory management" can mean different things to different people. For example, some, not exclusive to but very common to the OOP way of doing things, think of manual memory management as "new new new new new...", each object gets its memory allocated throughout the program and then when you no longer need that object the programmer has to call "delete delete delete delete delete..." to clean up. They see dealing with that as a pain, and they are quite right if this is their only picture of manual memory management, wouldn't it be nice if it just got rid of its self when I am through with it. And so they come up with all sorts of ways to deal with automating this problem, this brings us to garbage collection, reference counting being just one of several different methods of garbage collection. The thing is, there are trade offs not only with running a garbage collector, but also with structuring your program such that you allocate tiny pieces of memory for each individual object. Some of these include: lag when the garbage collector is calculating what to free, frequent cache misses because your memory is potentially spread out all over your RAM. In languages that that don't give you a choice and you must use a garbage collector, one trick people use is to pool their objects and reuse them, so GC does not kick in as often, hopefully, but if you think about it, how much different is this from managing your memory yourself? (although pooling can still lead to cache problems if it is stored in a different order than it is used in, a sort of fragmenting) Another way to manage your memory manually is to create custom allocators and use them in your program. Most of these boil down to allocating a huge chunk of memory up front, and then using it as you need it (but as I will mention later you can have allocators that grow in size), the behavior of the allocator being custom to your needs. For example you might have some data that you know will always be around in your program, it will never get bigger or smaller or go away, you could have a simple allocator that just gives you a pointer to the "top of the stack" and lets you put more stuff on top. No worries about needing to delete, when the program ends the whole thing is freed. Maybe you have data that changes but is really only needed in the current frame (in the context of a game engine), temporary data, like when concatenating filename strings or doing other busy work. You could create a similar linear allocator that you simply reset the "free pointer" to the start of the allocator when ever you want to clear, and then you write over the old data. (I hope my explanation is clear enough) It's simple to use, requires no computation to figure out if the memory is garbage, great. But what if I have some memory that I don't know the size of, or the size could grow or shrink, and the memory is going to be sticking around for a while so I don't want to have it get all fragmented with unused empty spaces? Well depending on your problem you could use an ordinary linear alloctor and just ask for the most memory you will ever need, but that will not always fit the problem well. You could make another allocator that works kind of like a linked list of chunks of memory. Whenever you ask for memory it could check its free list for a large enough piece, give it to you if it has one, or ask the OS if it needs more. When you remove stuff from that allocator it would free up the chunk, making it available for when you request more memory. Notice that the first allocator, for the most part is just calling "new" (for sake of explanation), for each thing, and you don't need to call any sort of "delete" command at all. The second allocator is actually very similar to the first implementation wise, but you only call delete once every frame to bulk delete temporary data. The final allocator is more like your classic, create--->use--->destroy, kind of thing. The benefit being that you don't need to always request to the OS to get memory and get lag spikes. (but sometime its unavoidable) You could also make some weird allocators for situations like: "It would be great if I had enough memory for this, but if I run out its not a big deal, its not the end of the world, I will use what I have." For things like storing particle system data, or maybe even image texture storage, where the system will then need to unload textures that are not currently on screen and load new textures when they are needed or something. And maybe it talks to the rendering system and says "nope you don't need one more variation of the grass texture, the priority is to render the player's new hat right now" I am far from being a professional on this topic and there are likely many better ways to actually implement what I have stated here. One thing I hope I have made clear is, that "manual memory management" need not necessarily be concerned with remembering to free data. And also that non OOP methodologies can take advantage of different kinds of memory allocators more effectively than a strict object hierarchy model. There are other ways to solve these problems other than garbage collection, but it is a different work flow and frame of mind. And many in the "use allocators" camp would likely be against smart pointers because of the simple fact that smart pointers are just wrappers, and are not really doing what we want them to do in our use case. So we make our own "wrappers" as it were. Anyway I do find your videos of good quality and helpful, and your point of view interesting. Keep it up.
you already helped me to bring my programmingskills on a new level, it helped me alot especialy the memoryparts. Not because i had problems to understand them, i just didnt knew when to use this or this. You made my overall understanding clearer than ever before in a shorter amount of time, ever before..
It is good to know the pros and cons of raw vs shared pointers and doubt your lessons would be as effective if you followed the rules at expense of educational clarity or your productivity. I learn a lot from your natural programming style. Thanks for the free content, really helping me learn cpp
Love the videos you do and the way you talk about stuff. Not only is it educational, but also very easy to follow. I've recommended you to many of my classmates who have a hard time learning c++. Would also like to see a video about OOP vs ECS. I know there are many out there but it would be interesting to hear your thoughts about it and how you would go about handling the many ways there are in an ECS. Keep up the good work!
- I find that knowing what's happening under the hood is the key to problem-solving and optimization. - I love new inventions that make our life easier and safer (including no code system) - Languages and frameworks and paradigm are tools, not religion
So excited about the error handling video. I've recently been trying factory functions that return a smart pointer instead of exceptions and quite enjoying it.
I agree with knowing what is going on behind the scenes, otherwise you may be having the wrong idea of how thigs work and it can make it difficult to find where the real error is, in a certain case. And well, for me it also allows you to decide which approach is better in a specific case, depending what you are programming. People usually tell me that I explain too much, they say that I start explaining from the beginning of the universe, just to answer a question like: "why does my application suddenly brokes, but not all the time, just sometimes? Maybe because C++ is so old that it fails sometimes...", and the answer could be something as easy as: your for loop is out of bounds, it should be < 4, not
I grew up with old school C++ so I'm the opposite and having difficulty wrapping my head around smart pointers. I mean I get the concept and understand it, but there's several smart pointers with subtle differences. Throwing them into my program also yielded various errors which were confusing so I just backed out and stuck to raw pointers. When i catch a break I'll try to sit down and figure them out but the last thing I want to do is introduce smart pointers throughout my program and then things begin to break and my program doesn't work anymore, and I'm left trying to figure things out including which smart pointer to use.
Just using unique_ptr for owning cases as Peterolen suggests is perfectly fine (actually close to ideal IMO) and raw pointers as you're used to for non-owning cases. If you're working with C APIs or old C++ APIs, pay careful attention to the `release` method which allows you to take the memory management out of the smart pointer and transfer elsewhere (making the smart pointer no longer manage its memory). Actually, if people never learned about `shared_ptr` and `weak_ptr`, the world would probably be better off. Just `unique_ptr` is all you should need unless you're a truly exceptional case.
I know what is undefined, but I am interested to see, how professional developers make a program robust to not invoke undefined behavior. There is also a special case with division: INT_MIN / -1 is undefined, but ignored most of the time. Because most platforms use twos complement, there is no value to -INT_MIN. Eg. int8_t ranges from -128(-2**7) to 127(2**7-1) -> 256 different values can be stored; 128 negative integers, zero and 127 positive integers; it cannot store 128. Also, as you know from math class, x/0 is also undefined. However your platform may wrap around overflown values; if you specificly want to add two values with wrapping, use the unsigned integer types. So UINT_MAX+1 is ok and simply results in 0. The unsigned integer types are defined in all arithmetic operations, with the exception of division by zero.
@Peterolen There are also some interesting talks on the CppCon channel. Eg. making unsigned integer arithmetic undefined leads to additional optimization opportunities.
You can't control how others perceive you or what they do with what you teach. It's their responsibility to do their due diligence and make sure they are writing good code. I agree that teaching the "dangerous" fundamentals is good, people should know how things work from the ground up. I'm not sure how you would even be able to understand memory safety if you didn't know how raw pointers worked.
Raw pointers are still fine in many contexts … I like the Sutters Mill GOTW blog about this … use smart pointers when ownership is important, but fine to pass and use raw pointers when the context does not involve ownership. Combination of both is fine and when done properly tells intent of ownership IMO. If I see a raw pointer or reference passed to a function I know the intent is that nothing inside shall try to own it and the caller agrees to “keep it alive” until returning, etc.
You want to automatically free memory without any runtime overhead and catch potential segfaults and race conditions at compile time? RUST. I know, it might not be as suitable for game dev yet but I heard some people say that learning to use it also makes you a better c++ programmer. I also love the ecosystem, compiler and package manager!
@@abd0-omar420 Obviously, more than ever. Everything I liked about it 4 years ago got improved A LOT since then. Edit: Also, while it still seemed like a niche back then, nowadays basically every large tech company uses rust to some extend and plan to use it more in the future. While there are of course immense code bases in other languages that already exist and need to be maintained, whenever something is being rewritten or a new project is started, it is usually done in rust. Here's a nice little video about that: th-cam.com/video/oY0XwMOSzq4/w-d-xo.html
This is excellent point as to why it is in fact important to teach about raw pointers. Any one who works on code in any sort of professional way will encounter raw pointers and will need to know a) what they are, and b) how to deal with them, same with c style casting vs c++ style casting (from the previous video). the c++ if obvy better and should be used, but there will be an awful lot of code you may have to deal with that will use c style casting.
Always there are disputes about whether to use modern C++ stuff or old ones and there are people who strongly believe that we have to use modern C++ and never touch old things for example we never should be using const char* to represent string and we should be using std::string or we never should be using raw pointers and all of that kind of stuff and the funny part is that this people even don't know how actually C++ works behind the scene and when they encounter any problem, they don't have any idea about how they can solve it because they haven't understood basic and important things and they just have learned how to put different syntax together to work. if they know those things that they panic about them they can simply solve the problem. "I AGREE WITH YOU CHERNO". we should learn things basically even we don't use them.
I could see only a couple reasons for using "raw" pointers. 1. You're using Qt's memory management system. 2. You've implemented your own parent-child object memory management system similar to Qt's. When you get down to it, really, only point 1. makes sense. But maybe point 2. could work if you're writing your own libraries.
Qt is so archaic in its design but it does have a smart pointer library of its own, like QScopedPointer, with a `take` method that functions similarly to scoped_ptr::release. I think it makes a lot of sense to use those more even in Qt for a language like C++ that can throw exceptions all over the place. Unfortunately they're not used so often in the official examples.
I'm working through this C++ series in May 2020, so that's 2.5+yrs after this video in particular was recorded (I believe most of them were recorded in 2017/2018). It's clear that The Cherno is frustrated here, but I don't know the context in which it was recorded at the time, so I'm not clear on why (other than picking up from the video that some criticism has been levelled at him from somewhere). Tbh, I'd simply say Cherno should do his own thing. It's great that he's trying to incorporate feedback from viewers, but when it comes down to it, we're getting this stuff for free, so the way I see it we as "freeloaders" can simply take what's offered and be grateful, or not (and go elsewhere). The only caveat is that it's nice to think that topic content suggestions might be considered and result in videos on those topics. But generally, while I appreciate Cherno no doubt wants to grow his channel and thus please people to make that happen, you can't escape the old truism about not being able to please all the people all of the time...
I'd imagine the frustration is from he's been doing the raw pointers for like a decade and probably how he was taught. You're going to find raw pointers out in the world so you have to know how to use them and how to properly free memory. the declaration and initialization of smart pointers looks gross compared to the raw pointers. I have several books from 2007 to 2019 none of which mention smart pointers....From a learning the basics standpoint it probably is better to learn raw pointers then learn that there are these things called smart pointers that are "better practice".
I am coming from the c# world... I have actually seen UNSAFE code written in c#. it is possible to use raw pointers in c#, however it will not compile unless you use the UNSAFE keyword. It was used because performance was needed and the safe array structure was far to slow for the emulator's memory
The "unsafe" keyword is rather silly. It should be called "unmanaged", which is what it really is Also, writing "unsafe" code in C# is perfectly normal. A very, very large portion of the C# API uses unsafe code for performance.
I come from the C world, so I'm very comfortable w raw pointers. However, I work on software architecture and design on long lived projects, so I'm trying to do more w smart pointers to support maintainability. Thanks for your insights.
In my opinion, almost every feature in C++, if not every feature, has its use. I think it's not really a matter of "only use raw pointers" or "only use smart pointers", but rather use your brain and figure out in which scenarios you should use what. Same goes for other modern C++ features, really.
If you dont like raw pointers and have no interest knowing about heap allocation, stick to python. If you want speed, its worth it to learn how to manage memory.
Thank you for these videos man. I expect to hear you talk about Lvalues, Rvalues, Move semantics and more topics about multithreading such as mutexes, race conditions
In my honest opinion is that you should use smart pointers even in little sandboxes because it should be second nature for one to use smartpointers for things and not use raw pointers. The only reason to use raw pointers is if one has to be backwards compatible.
Saying that you shouldn’t even learn about raw pointers is like saying you shouldn’t even learn arithmetic, because you can just use a calculator. It’s an important fundamental part of computer science. Now, using raw vs smart pointers is up to the user in my opinion. But learning about raw pointers, and how to use them should definitely be an major part of any CS students education. (Edit): I do prefer using raw pointers just because it’s easier for me to think through. But if I do use smart pointers I generally prefer to write my own
*sighs* using raw vs smart pointers is IMO not up to the user: owning -> smart pointer; not owning -> raw pointer and you also should not use your own. the c++ stl is a standard library for a reason...
You should use whatever is convenient for you or whatever would be best in the current situation. Forcing yourself to use only one thing could be not only inconvenient but it could also make your code inefficient.
Use smart pointers only when you need to create or transfer the ownership of an object. Otherwise, stick to raw pointers. No need to complicate things. :)
C++ Programmers should favor automatic Resource Management and Release to manual to ensure that cleanup is done. Even if you do not forget to delete your pointers there are ways to bypass standard return channels (exceptions), and smart pointers are deallocated during stack unwinding. Its alot of extra code to make sure you explicitly delete pointers in every return channel.
first name, yuphin is talking about using raw pointers when there's no creation or transferring of *ownership* of an object happening. That's the recommended way.
I think it's good to teach raw pointers etc as other ways of dealing with stuff. But ultimately teaching the possibly the more "automated" way is probably for the better to get into head.
To be clear safety has little to do with pointers vs smart pointers. Safety is mostly about having a strong type system so that instructions (code) are not applied to the wrong data. Improper matching of code and data is far more dangerous than a memory leak as a memory leak (in the presence of correct type use) is defined behavior. Sure, dereferencing an invalid pointer has undefined behavior, and that's where pointers figure into safety, but in the grand scheme of things, incorrect use of types (which strong typing helps prevent) is a much larger surface area in a real world application.
@TheChernoProject I have a longer comment with my thoughts on this subject, but it does not appear to be publicly visible. Perhaps the youtube filter has false flagged it as spam or something??? I don't think I said anything wrong. If you read it let me know if anything in it is against your channel's rules if any.
Raw pointers confuse everyone disproportionately to other topics for any first-time learners of C/C++. It takes a while to get used to them even after you've initially understood them, maybe a few months of use/exposure before your comfortable, so I don't see any reason in enforcing use of smart pointers from the get go, they're useful but it's added mental complexity. Yes it might be good practice but it's probably a better way of putting a fresh learner off because a pointer wrapped in a class, which other versions, will be a lot harder to get used to. I'm also learning Java at the minute, and maybe it's because I'm coming from C++ but one of the things it's hard to get used to is the fact that Java takes care of so much for you that you can't see under the hood when you do want to, like in C++
I learned Java and C++ at the same time... So when I learned about memory management I wanted to get a lot of control just like I could in C++, and C++ is my favorite language ever since.
I completely agree with the idea of knowing how things work behind the scene!
Please make videos about:
1- Move semantics
2- Exception handling
3- V-table
4- Some videos about Template Metaprogramming
Keep it up man!
There is a new series coming from CrashToSmash Modern C++ . Hope that covers latest features
He's a game engine developer, Template Metaprogramming's mortal enemy.
Agreed and in that order of importance...appreciate this channel so much
Yes! Including when to change the syntax of the language with the preprocessor and when to leave it alone. Changing the syntax of C++, was how my first language worked. The code for it is now gone though. That was before working on PNF, but just barely. So, I was age 15.
@@267praveen can you mail me the url? i cannot find it on yt. thx
You look exhausted speaking about this. Don't put too much on yourself. We love your content and you're doing an incredible job. Take care of yourself so you can keep making such great work and enjoying it!
I began my learning c++since I was 15 years old, which was 18 years ago (I'm 33yrs). And I'm your side on this one, I do not see all this fuzz about not using smart pointers.
Also, I want to thank you a lot for this whole series, I have complete it today and it has been by far the best c++ course/series that I have seen in my life! (even paid ones). You are exactly the teacher or friend that I always want it. Most people that I have meet in all this years have always demonised something without any good reason, but as a Game Developer (that's why I'm), I should say that you speak the real truth here and that's how you need to teach anyone. Basically tell the people how to learn the basics at it's core.
I even believe that the deepest you go, the better you understand what it's above it. The more I know C++... I want to go deeply into C or even assembly, because you understand better. That's the way to go with low level programming languages I believe.
Thank so much for all his series!
Let me guess... you learned from Andre LaMothe.
man's doing free work better than paid teachers
I think once you know enough of a language to be comfortable (or even a little early), would be important to program assembly of an old processor, because assembly is truly how computer works. And there is a lot of emulators online for old processors with few instructions, so it is easier to program these.
I think assembly is what can teach people about why people use certain terms on datas, programming paradigms and etc... Like, "how to make a float"?
I also recommend to get a DOS emulator and use Borland C++... It is basically C with classes indeed, haha...
Also, the 'int' is a short, and if you declare 'for (int n...', the 'n' will keep alive after the 'for' scope.
Eventually you come across a C library and it is good to know what C is doing.
Bro is 38 now 🙏,
@@crooda3681 bro is an unc now🙏
I just wanted to say, I've been learning C++ from a lot of resources lately and even though I use all of them and there's a ton of knowledge spread across the Internet you're so far the best one I came across - clear, in-depth, concise. Keep up the great work!
Totally agree, I believe it's very important to know how stuff work behind the scenes because when things break/don't work as expected, having that knowledge is what distinguishes a good programmer from an average one :)
I started learning C++ from your videos. I'm 57 years old and have wanted to learn C++ for about 20 years, but never got around to it. I'm now up to the point where I'm working my way through Win32 GUI programming and the enormous mess that that entails. Mixing Win32 C-style code along with C++ code would have been a LOT more difficult without the knowledge I got here, and specifically, the low level knowledge of what the system is doing is a godsend. Not many people even mention the things you talk about, such as linking, memory fragmentation, scope etc.
Cool!
Im studying physics in germany right now and one of my classes is programming. I started with python and in the following class (Introduction in software engineering) we will use c++. I wanted to prepare myself for the class and thererfor am watching your series. I feel like I could already write the tests of our exams, without the semester having started yet(we shall see when that happens, due to the current circumstances). With this comment I wanted to show you that you are helping people around the world with your channel and it is greatly appreciated! Thank you for your time and effort and as you mentioned this is your channel, teach the way you think is the best! Great channel, great person and great series! (I watched every single video(71/84) at least once and am looking forward to all the other content on your channel!
Same
The STL is SO powerful, but very rarely taught. It also makes you appreciate the language much more, at least in my case. Video on that would be great! Thanks for the great content
Also, could you do a few episodes on Data Structures? Binary trees, Stacks, Queues, etc?
That’d be the best thing ever
Found anything good on Data Structures?
@@HermanWillems Try mycodeschool channel. The best series I found
This channel focuses on bare c++ which is great because it clears a lot of misunderstanding of the language and how you use it, but there are already too many videos and documentation on data structures and algorithms. I don't expect him to make a series on that topic, but once you really get a grasp on the language, covering algorithms and any other topic is really just a walk in the park. Either way, it's pretty cool.
15:00 You really hit the nail on the head with this closeout statement. My boss, IT guy, and C++ Professor said the same things. They compared it to leaving the door open in your house or having someone come wipe your nose for you. You should understand the underlying constructs before you learn the tools that allow you to shortcut.
A few thoughts.
First, 100% agreed that raw pointers SHOULD be taught, whether before or after smart pointers is up for debate, but there will be times a unique pointer or smart pointer (whether the ones in memory or writing your own/using something out of boost). That's how you become a master of your tools.
Second, on your point about one off apps, you are more comfortable writing with raw pointers probably because that's what you learned first, and maybe what you've done more but I haven't seen your code (beyond this series and the OGL series) so I don't know. That makes it an interesting consideration that perhaps even on those you SHOULD use smart pointers simply to make it so you are more comfortable with them so that you always choose the "logical" choice for which to use in all applications, not simply "oh this is production code? default to smart pointers unless a reason comes up not to."
thanks, exactly what I am saying.
And this is exactly why I use multiple resources to learn c++, now I can have a good idea of when and where to use raw vs smart pointers!
I strongly believe you are the best c++ resource on internet
Agreed on this ... The only reason I'm looking at these videos because you go in depth with everything (C style and C++) - Sometimes you use Structs sometimes classes, sometimes you use Const char* x instead of std::string etc ... the whole aim of this is going towards mastering the language really and really understand how things work behind the scene.
Cheers Cherno !
As someone with some previous programming experience going through this series, I actually heavily appreciate the fact you showed us lower level constructs instead of telling us the best way to do things only, it's important to understand how the abstractions we're working with were built, not only just for the understanding, but also if we want to build something similar ourselves. This series gets some unwarranted flack on places such as Reddit, you did a great job with it and I'm glad I have this course to learn from.
Folk, after doing this for more years than I care to admit to, I find that these types of discussions tend to shed more heat than light. In the end, however you write your memory management code and however you use it, so long as it doesn't crash and you clean up after yourself, then you've done your job. Period. Anything beyond that is preaching.
I find it hard to agree to what you are saying. Most of the times when we write code it will be read, used and changed by other people. Our goal when writing code is to write code that is clear, hard to make mistakes with and hard to introduce bugs into.
Using smart pointers over raw new/delete (and in general utilizing RAII for resource management) removes an entire category of mistakes your peers can make while working with the code you provided.
Given that our job isn't done when our code is merged, I disagree with your conclusion.
This logic can be reduced to "if it works, it's good". Maybe overly reductive but it highlights the flaw in the logic whenever we shine a light on legacy and disastrous projects which do, in fact, have working code, but calling it "good" couldn't be further from the truth.
Absolutely agree. It is stupid to write cumbersome code out of pride so you can say you are a pure hearted C programmer. Not all of your code need to be highly optimized and super fast. Sometimes your code has to be fast, and sometimes the programmer has to be fast. These newer features might slow your code down but definetly speed you up as a developer, and it is important to know when it is worth it to go the long route and optimize for performance.
That being said the best way to know when to use what, is by having a deep understanding of how things work on the lowest level. Which is why you definetly should teach normal pointers in every C++ course.
HE IS ALIVE!!!
You are back wow! exicted for game engine series.
Hype
Cherno reads this and he's like: "RIP"
I learned Opengl ( at least the fundamentals) from him in a week, i work of course, but as a hobbyist I am also ready to learn more about game structure
I absolutely love knowing how everything works at the underlying level of it all, and your videos have been a genuinely enlightening experience and I've never been so excited to get more into programming in my life before.
As for the smart vs raw pointers thing, "There is a time and place for everything". People saying you should only use the best and safest and fastest code in a tiny sandbox test project is like saying you should never use debug build mode because it's slow. Be reasonable, people.
I generally use raw pointers in one and only one situation, as private class internals for custom data structures. In such cases I make sure that the pointer is fully managed by class in question. Not that such custom classes are commonly used, but there are cases when a custom class of this nature can be very useful. For example, normally I'd probably use STL these days, but there can be cases in which a specialty class is useful.
The two exceptions to this rule are when dealing with libraries / frameworks that require them (Qt uses them extensively, but it written in such a way as to manage them for you). The other, very rare, case is when I need a very small function to process a C string in some way, such as to quickly hash it, in which case the function takes the pointer as a parameter and isn't using it long.
I've had fun and learn a whole lot (including some humility) working on my own libraries, but there are only a few niche cases where I think I'd actually use them -- but I make no apologies for using raw pointer in it, after all STL stuctures do the same.
The reason why I value the channel and your teaching methods is as you've said to understand what's going on under the hood. To me it serves no purpose to learn sugar coated syntax alone, if for no other reason than to understand legacy code, and secondly to help problem solve coding issues. A fantastic series of which i'm greatly appreciative of. Thanks.
At 10:10 is a nice explanation of why the design of Rust is so good. In Rust, the default way, the lazy way of doing things is using the smart pointers. You need to jump through hoops, put in extra effort if you want to use raw, C style pointers, and if you do so, your code will look less clear. In Rust code with smart pointers looks cleaner than code with raw pointers.
Also, in general when you are programming in Rust, the default lazy ways of doing things are what is correct majority of the time and you need to jump through hoops in order to write unsafe C style code. You see this same story with dealing with null as well. The only way to have something like a null in Rust is to use an Option (like optional in C++) or to write your own Optional. Yes, you can unwrap an Option unsafely, but you need to consciously do so, you can't forget to check for null. Also, this makes it explicit in the code where dealing with the null case has happened.
I totally understand where you are coming from. I had a professor who forced us to only use C++ pointers and manage our own memory. I like having that option to choose smart pointers or native pointers depending on the given scenario. Thanks for the insight 👍
i agree with you. if one want to be good, then he needs to know how it works, pretty much on all the things he used. cannot be scared by raw ptr or smart ptr. The only thing we need is to understand what they are and when to use them.
There is a good video called: don't help the compiler. You can use what you want but in most cases the compiler will make its own out of it
Gotta watch this. Thanks
Do move constructors & Lvalue Rvalue!
And Type deduction (decltype)
*please
Listen to Bo Qian on youtube. He explains advanced concepts in C++ very well.
The problem is that many people tend to turn good advice into religion. Then they forget the reasoning behind the advice and follow it dogmatically.
Telling a beginner to avoid raw pointers and use smart pointers instead is generally good advice. But that doesn't mean that raw pointers must be avoided at all costs. C++ is a large tool box and if you know the purpose and limitations of your tool, it's totally fine to use it. Unfortunately, there are a lot of those C++ related religions ->
"Don"t use STL containers for games"
"OOP is dead"
"Raw pointers are evil"
"Don't use singletons"
"Don't use macros"
... and many more. While all those are or were based on some good reasons, you should never trust these statements blindly. Know the reasoning behind them and then decide which tool is the best for your use-case.
Hi, Min 8:58. I wanted say that using raw pointers IS NOT STUPID AT ALL. If the software is well designed there is no need to use smart pointers. Furthermore, if the developer is a beginner or if the project is a prototype or where the requirements of project are still not clear then it makes sense. I like this channel. Regards.
I don't think the need of smart pointers has to do with bad software design. Sometimes you require dynamic objects, and if so, someone needs to own it.
I agree with you 100% Cherno. You give a full understanding of how c++ works. Its not your responsibility to insure other peoples logic is sounds. You are giving a strong base of information to make the coding decision that are ultimately up to the programer.
100% agree with what you said here. I can sense that you are trying to teach and really want the viewers to understand the fundamentals instead of showing off your knowledge of C++.
I'd say for one to be able to appreciate the value that smart pointers add to the quality of the software, one has to go through the journey of using and managing the raw pointers. We've made it a guideline in our project not to use raw pointers. I'd anyday let go a bit of performance for more stable, maintainable, scalable, working software. It's just one less thing to worry about so you can focus on other things better.
I'm a python programmer and learning c++ and learning about pointers and memory has helped me better understand how python works
Totally agree, you'v got to know your basics right. Then only you'll be able to understand how things work internally. Just want to congratulate on this channel and I loved every single video in this c++ series and the way you teach every concept. I am new to this whole programming world. Gotta go a long way................! Thanks Cherno.
raw types: use if you want to learn the concepts or create custom wrappers
wrapper types: use for all practical purposes
Well I am but a beginner in c++ and what amazed me most about this language is how close it is to assembly language and memory management unlike what I’ve worked with before and I absolutely love it so I think raw pointers are what good to start people in c++
In my experience in C the main causes for memory leaks are weird return points, mostly from error checking. This can become very hard to deal with properly when you have a complicated function that has different things allocated and freed in different parts of the program.
Personally I am way more comfortable with raw memory management and things of that nature than I am with the more advanced abstractions in C++.
That's because you haven't tried them enough. The best programmers in the world can't help but create memory leaks with C pointers. With smart pointers the only way to screw up memory management is if you have circular referencing (or if you have a reference to an object and you screw up the lifetimes. This mistake can happen in C as well though).
OMG YOU ARE BACK!!!!!!!!!!!!!!!!!!!!!!!!!
I HAVE BEEN WAITING SOOOO LONG THX FOR COMING BACK!!!!
The concept of programming is to automate things so yes automatic pointer gestion seems so logic !
The Best C++ tutor on TH-cam ..keep it up bro!
I'm a student attending university at the moment with a class coming up that, supposedly, will rely a lot on C++. I've only been taught how to use C and Java in the past, so I wanted to use this summer to hone in on the core values of good C++ programming before jumping into another school quarter, which is usually way too quickly paced to help learn the fundamental, deep interworkings of programming languages, like what you've decided to focus on in this series.
I'm also training to enter the games industry, and until stumbling across this series, I haven't been taught the various methods and tools that can be taken advantage of to optimize applications, the very concepts that will enable me to work with teams to create complex, inspiring games that take advantage of everything their hardware has to offer.
I greatly appreciate this series as well as it's discussion-centric videos, like this one, that bring into question the practices and disciplines we need to keep in mind when educating ourselves and others. Thanks a ton.
In my opinion you are teaching just right . And I believe you are not just another resource over internet , you are probably the best .
You asked for opinions so...
If you "just want to try something out" then use shared_ptr and pass by value, which is how you use raw pointers most of the time anyways. But that's besides the point. The smart pointers offer exception safety in terms of RAII and reinforce that programming paradigm. Once you start going down the new/delete approach, you'll probably start taking shortcuts elsewhere and end up falling into try/catch (or not even doing that) to cleanup your "just try it" program.
If you want to write C, then you might as well add the whole goto out_free and out_unlock fun while you're at it; which is what destructors do for us in C++ (and I only have to write it once!).
We are what we do, try not to create anti-pattern habits for yourself.
The most powerful and fundamental things C++11 did for us IMHO is the standardized memory model, fixing std::allocator, and move semantics. If you don't start thinking in terms of move semantics and scope based management then you are capping your potential as modern c++ designer. Otherwise you should probably consider switching gears to Java or golang and enjoy being a victim of a mark and sweep based memory managed language, but you will write more code.
Great video. Thanks.
Just another person way too afraid of raw pointers. A good programmer should be able to deal with raw pointers and manually automate the deletion (like in destructors for example).
@Sam Claus It is not just about efficiency, but about power of expression. C is timeless btw., unlike OOP paradigms.
@Sam Claus I don't leave room for error. Code is always perfect. Warning, high risk for brainwashing in the area of software development.
I fully agree with you - choosing c++ as a language means that your're willing or expected to be) to go down the nitty-gritty details.
You need more likes. Your presentation of usually esoteric dry detail is clear, entertaining, simple and teaches so much in a short time. You have a gift.
agree! raw pointers should be taught even in real industrial project, they are not used often. Raw pointers r super helpful to touch the memory concept which is crucial in programming especially C++ ! Raw pointers should only play in terms of beginner study, but in work, avoid raw pointers as much as you can.
One main advantage of using smart pointers is exception safety. If an exception is thrown before you call delete, then it will not get freed and thus leak. Smart pointers guaranteed to clean up memory always.
This series has made my C++ game alot better! I sincerely hope you haven't stopped it :) Id like to know more about topics like binding and scoped locks together with using a mutex.
@TheChernoProject
I think something that can help in this discussion is talking more in depth about memory management.
I don't know that I've ever heard the exact phrase "be a man and manage your own memory", directed to me or to others, but I get what your saying. The thing is, depending on your knowledge of different programming techniques, "manual memory management" can mean different things to different people.
For example, some, not exclusive to but very common to the OOP way of doing things, think of manual memory management as "new new new new new...", each object gets its memory allocated throughout the program and then when you no longer need that object the programmer has to call "delete delete delete delete delete..." to clean up. They see dealing with that as a pain, and they are quite right if this is their only picture of manual memory management, wouldn't it be nice if it just got rid of its self when I am through with it. And so they come up with all sorts of ways to deal with automating this problem, this brings us to garbage collection, reference counting being just one of several different methods of garbage collection. The thing is, there are trade offs not only with running a garbage collector, but also with structuring your program such that you allocate tiny pieces of memory for each individual object. Some of these include: lag when the garbage collector is calculating what to free, frequent cache misses because your memory is potentially spread out all over your RAM. In languages that that don't give you a choice and you must use a garbage collector, one trick people use is to pool their objects and reuse them, so GC does not kick in as often, hopefully, but if you think about it, how much different is this from managing your memory yourself? (although pooling can still lead to cache problems if it is stored in a different order than it is used in, a sort of fragmenting)
Another way to manage your memory manually is to create custom allocators and use them in your program. Most of these boil down to allocating a huge chunk of memory up front, and then using it as you need it (but as I will mention later you can have allocators that grow in size), the behavior of the allocator being custom to your needs. For example you might have some data that you know will always be around in your program, it will never get bigger or smaller or go away, you could have a simple allocator that just gives you a pointer to the "top of the stack" and lets you put more stuff on top. No worries about needing to delete, when the program ends the whole thing is freed. Maybe you have data that changes but is really only needed in the current frame (in the context of a game engine), temporary data, like when concatenating filename strings or doing other busy work. You could create a similar linear allocator that you simply reset the "free pointer" to the start of the allocator when ever you want to clear, and then you write over the old data. (I hope my explanation is clear enough) It's simple to use, requires no computation to figure out if the memory is garbage, great.
But what if I have some memory that I don't know the size of, or the size could grow or shrink, and the memory is going to be sticking around for a while so I don't want to have it get all fragmented with unused empty spaces? Well depending on your problem you could use an ordinary linear alloctor and just ask for the most memory you will ever need, but that will not always fit the problem well. You could make another allocator that works kind of like a linked list of chunks of memory. Whenever you ask for memory it could check its free list for a large enough piece, give it to you if it has one, or ask the OS if it needs more. When you remove stuff from that allocator it would free up the chunk, making it available for when you request more memory.
Notice that the first allocator, for the most part is just calling "new" (for sake of explanation), for each thing, and you don't need to call any sort of "delete" command at all. The second allocator is actually very similar to the first implementation wise, but you only call delete once every frame to bulk delete temporary data. The final allocator is more like your classic, create--->use--->destroy, kind of thing. The benefit being that you don't need to always request to the OS to get memory and get lag spikes. (but sometime its unavoidable)
You could also make some weird allocators for situations like: "It would be great if I had enough memory for this, but if I run out its not a big deal, its not the end of the world, I will use what I have." For things like storing particle system data, or maybe even image texture storage, where the system will then need to unload textures that are not currently on screen and load new textures when they are needed or something. And maybe it talks to the rendering system and says "nope you don't need one more variation of the grass texture, the priority is to render the player's new hat right now"
I am far from being a professional on this topic and there are likely many better ways to actually implement what I have stated here.
One thing I hope I have made clear is, that "manual memory management" need not necessarily be concerned with remembering to free data. And also that non OOP methodologies can take advantage of different kinds of memory allocators more effectively than a strict object hierarchy model. There are other ways to solve these problems other than garbage collection, but it is a different work flow and frame of mind. And many in the "use allocators" camp would likely be against smart pointers because of the simple fact that smart pointers are just wrappers, and are not really doing what we want them to do in our use case. So we make our own "wrappers" as it were.
Anyway I do find your videos of good quality and helpful, and your point of view interesting. Keep it up.
You are definitely one of the best C++ resources (in my humble opinion)
you already helped me to bring my programmingskills on a new level, it helped me alot especialy the memoryparts. Not because i had problems to understand them, i just didnt knew when to use this or this. You made my overall understanding clearer than ever before in a shorter amount of time, ever before..
It is good to know the pros and cons of raw vs shared pointers and doubt your lessons would be as effective if you followed the rules at expense of educational clarity or your productivity. I learn a lot from your natural programming style. Thanks for the free content, really helping me learn cpp
Love the videos you do and the way you talk about stuff. Not only is it educational, but also very easy to follow. I've recommended you to many of my classmates who have a hard time learning c++. Would also like to see a video about OOP vs ECS. I know there are many out there but it would be interesting to hear your thoughts about it and how you would go about handling the many ways there are in an ECS.
Keep up the good work!
- I find that knowing what's happening under the hood is the key to problem-solving and optimization.
- I love new inventions that make our life easier and safer (including no code system)
- Languages and frameworks and paradigm are tools, not religion
So excited about the error handling video. I've recently been trying factory functions that return a smart pointer instead of exceptions and quite enjoying it.
I agree with knowing what is going on behind the scenes, otherwise you may be having the wrong idea of how thigs work and it can make it difficult to find where the real error is, in a certain case.
And well, for me it also allows you to decide which approach is better in a specific case, depending what you are programming.
People usually tell me that I explain too much, they say that I start explaining from the beginning of the universe, just to answer a question like: "why does my application suddenly brokes, but not all the time, just sometimes? Maybe because C++ is so old that it fails sometimes...", and the answer could be something as easy as: your for loop is out of bounds, it should be < 4, not
Congratulations💍💍
I grew up with old school C++ so I'm the opposite and having difficulty wrapping my head around smart pointers. I mean I get the concept and understand it, but there's several smart pointers with subtle differences. Throwing them into my program also yielded various errors which were confusing so I just backed out and stuck to raw pointers. When i catch a break I'll try to sit down and figure them out but the last thing I want to do is introduce smart pointers throughout my program and then things begin to break and my program doesn't work anymore, and I'm left trying to figure things out including which smart pointer to use.
Just using unique_ptr for owning cases as Peterolen suggests is perfectly fine (actually close to ideal IMO) and raw pointers as you're used to for non-owning cases. If you're working with C APIs or old C++ APIs, pay careful attention to the `release` method which allows you to take the memory management out of the smart pointer and transfer elsewhere (making the smart pointer no longer manage its memory). Actually, if people never learned about `shared_ptr` and `weak_ptr`, the world would probably be better off. Just `unique_ptr` is all you should need unless you're a truly exceptional case.
This video only focused at pointers, can you also make a video about integer overflow and buffer overflow and other undefined behavior, please?
I can take the integer overflow one :
don't do INT_MAX++ or INT_MIN--
I know what is undefined, but I am interested to see, how professional developers make a program robust to not invoke undefined behavior.
There is also a special case with division: INT_MIN / -1 is undefined, but ignored most of the time. Because most platforms use twos complement, there is no value to -INT_MIN. Eg. int8_t ranges from -128(-2**7) to 127(2**7-1) -> 256 different values can be stored; 128 negative integers, zero and 127 positive integers; it cannot store 128. Also, as you know from math class, x/0 is also undefined.
However your platform may wrap around overflown values; if you specificly want to add two values with wrapping, use the unsigned integer types. So UINT_MAX+1 is ok and simply results in 0. The unsigned integer types are defined in all arithmetic operations, with the exception of division by zero.
@Peterolen There are also some interesting talks on the CppCon channel. Eg. making unsigned integer arithmetic undefined leads to additional optimization opportunities.
You can't control how others perceive you or what they do with what you teach. It's their responsibility to do their due diligence and make sure they are writing good code. I agree that teaching the "dangerous" fundamentals is good, people should know how things work from the ground up. I'm not sure how you would even be able to understand memory safety if you didn't know how raw pointers worked.
I watched all this series. Hit the like button all the way!
Good to see you back
Raw pointers are still fine in many contexts … I like the Sutters Mill GOTW blog about this … use smart pointers when ownership is important, but fine to pass and use raw pointers when the context does not involve ownership. Combination of both is fine and when done properly tells intent of ownership IMO. If I see a raw pointer or reference passed to a function I know the intent is that nothing inside shall try to own it and the caller agrees to “keep it alive” until returning, etc.
You want to automatically free memory without any runtime overhead and catch potential segfaults and race conditions at compile time? RUST. I know, it might not be as suitable for game dev yet but I heard some people say that learning to use it also makes you a better c++ programmer. I also love the ecosystem, compiler and package manager!
do you still use rust?
@@abd0-omar420 Obviously, more than ever. Everything I liked about it 4 years ago got improved A LOT since then.
Edit: Also, while it still seemed like a niche back then, nowadays basically every large tech company uses rust to some extend and plan to use it more in the future. While there are of course immense code bases in other languages that already exist and need to be maintained, whenever something is being rewritten or a new project is started, it is usually done in rust. Here's a nice little video about that: th-cam.com/video/oY0XwMOSzq4/w-d-xo.html
@@flyingsquirrel3271 Thank you so much for the replay it helped me a lot and I will be learning more about rust
@@abd0-omar420 Good luck! I hope you will enjoy it :)
I go in raw all the way....
Also I work on code that was written when those smart pointers weren't around haha.
This is excellent point as to why it is in fact important to teach about raw pointers. Any one who works on code in any sort of professional way will encounter raw pointers and will need to know a) what they are, and b) how to deal with them, same with c style casting vs c++ style casting (from the previous video). the c++ if obvy better and should be used, but there will be an awful lot of code you may have to deal with that will use c style casting.
Keep it up Cherno! We love you!!
Always there are disputes about whether to use modern C++ stuff or old ones and there are people who strongly believe that we have to use modern C++ and never touch old things for example we never should be using const char* to represent string and we should be using std::string or we never should be using raw pointers and all of that kind of stuff and the funny part is that this people even don't know how actually C++ works behind the scene and when they encounter any problem, they don't have any idea about how they can solve it because they haven't understood basic and important things and they just have learned how to put different syntax together to work. if they know those things that they panic about them they can simply solve the problem. "I AGREE WITH YOU CHERNO". we should learn things basically even we don't use them.
Please make tutorial of c# and java. Love the way you explain everything.
Thaaaanks man you are the best guys at explaining complicated and in-depth stuff in programming 🔥
Thank you so much for these videos!
I have respect for you in my heart u r a great teacher. 🙏🏻
I like the approach to assess the situation and use what fits best
I could see only a couple reasons for using "raw" pointers. 1. You're using Qt's memory management system. 2. You've implemented your own parent-child object memory management system similar to Qt's. When you get down to it, really, only point 1. makes sense. But maybe point 2. could work if you're writing your own libraries.
Qt is so archaic in its design but it does have a smart pointer library of its own, like QScopedPointer, with a `take` method that functions similarly to scoped_ptr::release. I think it makes a lot of sense to use those more even in Qt for a language like C++ that can throw exceptions all over the place. Unfortunately they're not used so often in the official examples.
I'm working through this C++ series in May 2020, so that's 2.5+yrs after this video in particular was recorded (I believe most of them were recorded in 2017/2018). It's clear that The Cherno is frustrated here, but I don't know the context in which it was recorded at the time, so I'm not clear on why (other than picking up from the video that some criticism has been levelled at him from somewhere).
Tbh, I'd simply say Cherno should do his own thing. It's great that he's trying to incorporate feedback from viewers, but when it comes down to it, we're getting this stuff for free, so the way I see it we as "freeloaders" can simply take what's offered and be grateful, or not (and go elsewhere). The only caveat is that it's nice to think that topic content suggestions might be considered and result in videos on those topics. But generally, while I appreciate Cherno no doubt wants to grow his channel and thus please people to make that happen, you can't escape the old truism about not being able to please all the people all of the time...
I'd imagine the frustration is from he's been doing the raw pointers for like a decade and probably how he was taught. You're going to find raw pointers out in the world so you have to know how to use them and how to properly free memory. the declaration and initialization of smart pointers looks gross compared to the raw pointers. I have several books from 2007 to 2019 none of which mention smart pointers....From a learning the basics standpoint it probably is better to learn raw pointers then learn that there are these things called smart pointers that are "better practice".
I am coming from the c# world... I have actually seen UNSAFE code written in c#. it is possible to use raw pointers in c#, however it will not compile unless you use the UNSAFE keyword. It was used because performance was needed and the safe array structure was far to slow for the emulator's memory
The "unsafe" keyword is rather silly.
It should be called "unmanaged", which is what it really is
Also, writing "unsafe" code in C# is perfectly normal. A very, very large portion of the C# API uses unsafe code for performance.
I come from the C world, so I'm very comfortable w raw pointers. However, I work on software architecture and design on long lived projects, so I'm trying to do more w smart pointers to support maintainability.
Thanks for your insights.
Preach teacher, thank u much. Keep doing what you're doing. Great job
I do love your way of teaching. I have learnt a lot.
In my opinion, almost every feature in C++, if not every feature, has its use. I think it's not really a matter of "only use raw pointers" or "only use smart pointers", but rather use your brain and figure out in which scenarios you should use what. Same goes for other modern C++ features, really.
Cool~I like to know everything behind the scenes
yup, i also like to be open to raw pointers in C++. Otherwise it will become java. C++ is C++ because of low level code with ways to not mess them up
If you dont like raw pointers and have no interest knowing about heap allocation, stick to python. If you want speed, its worth it to learn how to manage memory.
Thank you for these videos man.
I expect to hear you talk about Lvalues, Rvalues, Move semantics and more topics about multithreading such as mutexes, race conditions
In my honest opinion is that you should use smart pointers even in little sandboxes because it should be second nature for one to use smartpointers for things and not use raw pointers. The only reason to use raw pointers is if one has to be backwards compatible.
Completely pro teaching how things work under the hood! Keep your material just like that! And thanks!
Saying that you shouldn’t even learn about raw pointers is like saying you shouldn’t even learn arithmetic, because you can just use a calculator.
It’s an important fundamental part of computer science.
Now, using raw vs smart pointers is up to the user in my opinion.
But learning about raw pointers, and how to use them should definitely be an major part of any CS students education.
(Edit):
I do prefer using raw pointers just because it’s easier for me to think through.
But if I do use smart pointers I generally prefer to write my own
i doesnt study in university but with my whole experience i digged through i can agree
*sighs* using raw vs smart pointers is IMO not up to the user:
owning -> smart pointer; not owning -> raw pointer
and you also should not use your own. the c++ stl is a standard library for a reason...
Yaaaay! New vid on cpp, excited \_O_/
Thanks a lot for this series. 👍🏼
You should use whatever is convenient for you or whatever would be best in the current situation. Forcing yourself to use only one thing could be not only inconvenient but it could also make your code inefficient.
Use smart pointers only when you need to create or transfer the ownership of an object. Otherwise, stick to raw pointers. No need to complicate things. :)
Exactly ,and also what's wrong with stack ? I see so many people use pointers in places where they are not even necessary.
C++ Programmers should favor automatic Resource Management and Release to manual to ensure that cleanup is done. Even if you do not forget to delete your pointers there are ways to bypass standard return channels (exceptions), and smart pointers are deallocated during stack unwinding. Its alot of extra code to make sure you explicitly delete pointers in every return channel.
first name, yuphin is talking about using raw pointers when there's no creation or transferring of *ownership* of an object happening. That's the recommended way.
there is already a workaround for exceptions :D no problem dude
first name RAII IS about ownership(because resource management is about ownership).
I think it's good to teach raw pointers etc as other ways of dealing with stuff.
But ultimately teaching the possibly the more "automated" way is probably for the better to get into head.
Are there any benefits of using a raw pointer over a smart pointer?
I totally agree....Nice video...Nice message
To be clear safety has little to do with pointers vs smart pointers. Safety is mostly about having a strong type system so that instructions (code) are not applied to the wrong data. Improper matching of code and data is far more dangerous than a memory leak as a memory leak (in the presence of correct type use) is defined behavior.
Sure, dereferencing an invalid pointer has undefined behavior, and that's where pointers figure into safety, but in the grand scheme of things, incorrect use of types (which strong typing helps prevent) is a much larger surface area in a real world application.
3:00 you forgot to link those clips in the right corner
I can understand the "don't do it because someone might see" idea, but it's not about not using smart pointers, it's about proper memory management.
Totally agree as well bro!! Thank u very much!
@TheChernoProject
I have a longer comment with my thoughts on this subject, but it does not appear to be publicly visible. Perhaps the youtube filter has false flagged it as spam or something??? I don't think I said anything wrong. If you read it let me know if anything in it is against your channel's rules if any.
I've approved it, TH-cam marked it as "likely spam" 🙃
Thanks, I don't know what is in youtube's magical algorithms that would trigger this, could be anything. Whatever it is, seems pretty janky to me.
I'm learning c++ coming from c#. When I look at sample code or sdk code... I see lots of raw pointers.
Raw pointers confuse everyone disproportionately to other topics for any first-time learners of C/C++. It takes a while to get used to them even after you've initially understood them, maybe a few months of use/exposure before your comfortable, so I don't see any reason in enforcing use of smart pointers from the get go, they're useful but it's added mental complexity. Yes it might be good practice but it's probably a better way of putting a fresh learner off because a pointer wrapped in a class, which other versions, will be a lot harder to get used to.
I'm also learning Java at the minute, and maybe it's because I'm coming from C++ but one of the things it's hard to get used to is the fact that Java takes care of so much for you that you can't see under the hood when you do want to, like in C++
I learned Java and C++ at the same time... So when I learned about memory management I wanted to get a lot of control just like I could in C++, and C++ is my favorite language ever since.