ALWAYS think about LIFETIMES in C++! // Code Chill
Вставка
- Опубліковано 20 жов 2024
- To try everything Brilliant has to offer-free-for a full 30 days, visit brilliant.org/... . You’ll also get 20% off an annual premium subscription.
Patreon ► / thecherno
Instagram ► / thecherno
Twitter ► / thecherno
Discord ► / discord
Code ► github.com/Bog...
Hazel ► hazelengine.com
🕹️ Play our latest game FREE (made in Hazel!) ► studiocherno.i...
🌏 Need web hosting? ► hostinger.com/...
💰 Links to stuff I use:
⌨ Keyboard ► geni.us/T2J7
🐭 Mouse ► geni.us/BuY7
💻 Monitors ► geni.us/wZFSwSK
This video is sponsored by Brilliant.
Welcome to Code Chill! A new series/format where we chill and discuss code in a laid-back fashion. Let me know if you enjoyed and would like to see more! 👇
Don't forget you can try everything Brilliant has to offer-free-for a full 30 days, visit brilliant.org/TheCherno . You’ll also get 20% off an annual premium subscription.
love this format
kinda expected it to be longer lol but you were only dealing with the 1 class lol
my argument for the lifetime and the structure of the resource manager would be similar but with a slightly different pov: first you can't really know what you'll be doing 6 months or 1 year from now, i mean sure there are reasonable and unreasonable hypothesis, but we can say that if you made one game engine then the possibility of you working on another game engine is not zero; second point to me is reuse before expandability: what happens when you want to make a new game project and don't want to start from scratch "oh yeah, i did that thing, i can clone that architecture" and there you could remain screwed from the fact that you didn't implement lifetimes
I 100% appreciate the deep dives into a particular subject. More of this please, I love it.
I like this train of random thoughts of implementations and methods, good format, would love to see more of it.
The Init() and Shutdown() should do some checks:
You shouldn't create a new instance and leak memory if Init is called multiple times (without matching Shutdown).
A/ Check if Resource Manager is alive (the global pointer is already set) and just do nothing if it is.
B/ Use assert if it is considered a bug when it is called multiple times and you want to know about it and fix it.
In Shutdown I guess technically you can call delete on mullptr, so a check is not necessary in case A, but there should be an assert in case B (if calling Shutdown multiple times could be a bug: You copied a line instead of moving it, looking at the code you think you are shutting it down at one place, but it is already shut down and silently skips the other calls...)
To be even more compatible with the original design you could call Init form the get instance method if the pointer is null, instead of using an assert. But there should be some sort of (debug build) check there as well.
Big fan of making this a series! I learned a lot, and listening to your tangents is great.
Love this deep talk about some subject, Cherno. Mainly being about memory management/lifetime. I've been learning alot with your channel. Keep it up, please!
I like this format, I don't think is too deep with the concepts since it has been well explained. Keep it up mate!
I like this kind of videos where you actually code and share your ideas!
1:08 Haha, yes :). For this project I had to follow some requirements and one of them was to create an exception hierarchy.
You can in principle replace the singleton pattern with a namespace in C++. Don't need a class at all. It's then impossible to make two but you also don't have to do any magic to prevent making two. I like that pattern sometimes, but it does make automatic construction and destruction difficult. You're forced to use something like init/shutdown as you did here. Sometimes that's not really what I want, but other times it's ok.
You actually do need RAII for the resource manager in the case because of the try catch because if it throws an exception the resource manager will never get shut down
As it is written, the program will terminate on exception, and the OS will release process memory, so who cares?
@@tzimmermann That’s a fair point, but if you’re doing things out of habit like he is in that video that is a consideration to make
@@RetroAndChill Wouldn't it also work if you have a deconstructor that calls Shutdown(), so the shutdown method is 'just' for verbocity? The exception would then call the deconstructor, right? Not too keen on these kind of things though...
@@G1g4ntvltLP Yes that’s the idea, the second the object pops out of scope the destructor is called and the system is shut down. Ultimately the pattern makes it easier to not have to remember to free resources and help prevent memory leaks/double deletions
@@RetroAndChill I understand. I'd argue that solving problems you don't have is a very bad habit. If an exception reaches the entry point, you're toast anyway, and there is no such thing as an elegant and clean death. Say your last words in the standard output, and let the undertaker do his job.
Cherno, make a video talking about pre-allocating all game memory vs allocating dynamically as the game runs. In short, is fragmenting memory that bad that you should pre-allocate everything or can you get away with dynamic allocation just fine. That in a AAA or AA context.
Dynamic allocation is slow (order of hundreds of milliseconds per allocation) mostly due to operating system synchronization.
Pre-Allocation is slow only at program launch.
Memory fragmentation is not a valid concern because modern systems utilize lots of memory as well as hardware memory management units.
The best thing to do is allocate massive backing memory at startup and sub-allocate out of that usually using an arena allocator. If more memory is needed the just allocate another massive memory block and allow the allocator to choose which underlying memory block to allocate out of.
@@jerrys2292 "hundreds of milliseconds per allocation" is not even close to accurate for relatively small allocations. Ran a quick test malloc'ing 1MB, took under 1ms on my PC. 1GB took 87ms (obviously depends on the hardware so YMMV), but if you're measuring your allocations in GB you basically are allocating everything upfront.
@@gamesbycarter The key words that you repeated but failed to understand here are "per allocation". If you're allocating 1GB in 1MB chunks, then it will take significantly longer than if you allocate one single GB chunk. Your mileage will not vary on this, it's like a law in physics.
@@anon_y_mousse I see your point, but the way they phrased it implied a single allocation will take hundreds of milliseconds, which is horrifyingly inaccurate. I understand and agree that less allocations is better
In general you want to avoid frequent heap allocations in your hot path. Dynamic allocation is a bit slow (not as slow as some would think it is, though), and depending on your allocation / deallocation pattern you can indeed hurt performances by fragmenting the heap, in which case malloc will take an increasing amount of time to find a suitable spot for your data.
You have to be smart about it, and target the biggest offenders first. If you're writing a system that needs to allocate / free a lot of stuff each frame, like a CPU-side particle system, then of course you have to come up with some memory pooling strategy because it isn't viable to do otherwise.
In fact, depending on the lifetimes and sizes of your objects, various custom memory allocation strategies can take place. Read about memory arenas. Basically, you allocate a big slab of memory upfront for your application, and segment it in various ranges, each of which is managed by an allocator.
- You need to frequently allocate / free small objects of the same size -> pool allocator
- You need to push objects of different sizes in a contiguous fashion and can free everything in one go (command buffers come to mind) -> linear allocator
- You need something more generic but still fast -> maybe a TLSF allocator will do
etc.
Maybe you don't need something as sophisticated as a full-blown arena system, but it doesn't hurt to know about pooling and linear allocations.
Now, you need to actually measure stuff, before you take drastic decisions. The biggest issue is with identifying heap allocs that you don't directly control, with explicit new / delete. Using std::function / std::string much? Plus your compiler can in fact optimize out most small dynamic allocations, so instrumenting your release build (with debug symbols) is a must, to see what remains. If you're on Windows, then I believe Visual Studio can help you track heap allocs like it's no big deal. If you're on Linux like me, have fun (I had to write my own tool to hook malloc calls and export a call graph, existing tools were too slow for a runtime application).
I didn't know you could use the _inline_ like that. Very nice.
Cherno, thank you very much! This is a content I was waiting for so long. Please consider to continue the series and rewrite/(write from scratch) other modules of the game. It is very educational!
As someone who is having a very hard time learning C++ These Videos are a blast.
I keep asking in your comments of your videos the same question, as it's always something I get stuck on. How to put all the things together to make a simple game? I've seen plenty of videos talking about state management, and what I believe are over complicated ways to do things.
I'd just like to see a simple way to show scenes, transition/load them, but how they connect to the different systems that run inside the scene.
For example, say you are currently playing the game, you hit esc, it pauses the game, and shows a menu. You click the "Save and Exit to Menu" button, and it unloads the game scene, and shows the main menu scene. How does the system that handles that button click access the scene manager/stack to change the scene?
IDK if that's clear, but that's the kind of issues I run into when trying to even make a simple game.
You obviously need some way to access the "scene manager" which would just boil down to an active scene reference or pointer, a list if loaded scenes and a few functions to load/unload scenes as well as run the active scene.
To access the scene manager, you can use either globals/namespaced vars/funcs or a singleton class that is provided by a pointer or reference.
Scene transitions are a bit harder and depend on the kind of transition you want. If it is a simple transition like fade to black then you have the scene that is being replaced play the animation and then set the new scene to the desired next scene. If you want some transition from the current scene to the next scene to have both scenes active at the same time then it might be worth having some way to support subscenes, multiple active scenes or copy the entry area in the next scene to the current scene and play the transition in the current scene and only then swap. Each approach has their own pros and cons - subscenes would be more complex to implement across the board but more flexible whereas having multiple active scenes may be difficult to update (think both scenes thinking they have control over the player), or copying the area being labour intensive and requiring manually syncing them but being a much technically simpler implementation.
It's helpful to break it down to the most simple solution. At a minimum, a game needs a single way of processing user input and events, updating the game state, and drawing the updated state. That would be a single "scene". A system with multiple scenes would have different input/event handling, updating and drawing for each of its scenes. And the "scene manager" does nothing more than hold a reference to the active scene. It could be as simple as : activeScene = Game (or Menu, GameOver etc). And a "scene transition" is just changing that reference. After that it's just: activeScene.getInput(); activeScene.update(); activeScene.draw() and your game automatically runs the right code. Everything else, like transitions, managing multiple active scenes, asset loading, etc is just sugar on top.
I love this format of video as I'm re-learning c/c++ but am not new to development so like the more "nitty gritty" side of things.
Love this format. Would gladly see more just like it!
Great stuff ! Do you do live coding on streams or upload that on youtube? A full extensive coding show would be amazing for picking your brains on C++ and how you approach various problems. Would be super beneficial for many young devs !
hello cherno! do more of this style
The analogy of cleaning the house before wrecking it came up to my mind a fraction of second before you started saying the same thing! What a freaking coincidende! Well, great minds think alike I suppose 😅
I agree with you about the lifetime of the object being managed by explicitly calling Init and Shutdown. However, wouldn't it also be good if the RessourceManager pointer were private within the class?
just jumped from ur c++ vid to this and I was shocked how mature ur look has gotten lyk I dont know y i expected u to look exactly the same lol but u always kill it as always
Mr . Cherno I'm a great fan of your channel from India . And also I'm greatly passionate about C++ as well . But recently people are talking about replacing both C++ and C with Rust . And I'm at my beginning stage of my career. So I'm quite intimidated about choosing C++ as my programming language for a successful career . Please upload a video regarding the future of C++ , where will it go , where will it end up .
I would assume that this wouldn't be my only game and I would still need resource manager for all my games. If I have a sort of generic implementation which I can always bring in and further develop based on the new requirements. This case I don't need to reimplement it every time. I think Cherno's approach here is correct.
Loving this format!
Allocators are something that you should always think about especially with pmr.
Hi Cherno, can you please upload a video on how to test your C++ projects?
More of this, please!!!
I really liked this format :)
Cool format for the video.
Why not wrap the resource manager with a unique_ptr?
If you have a project structure, then have a project specific resource manager. Downside is that application layer resources would require an additional manager. Although, the project should be ignorant of the application layer.
I really disagree with the global declaration of the resource pointer. I feel it should have been a private static member of the class; pointer or not. I also don't like the Init()/Shutdown() pattern. I'd initialize the static member on class construction. Alternatively, one could initialize the static member on calls to Instance() if using a pointer. On first call, it would get allocated... Maybe using a unique pointer? In any case, I'd get rid of either Load() (in original call) or Init()/Shutdown() (in modified code). I see no benefit to it. I'd use RAII or instantiation through first call to Instance(), as mentioned above.
I always enjoy making my APIs reusable and easy to understand even when it doesn't need to, because i enjoy it😅
Love the format
Can you do a video about using very long-sized integer using GMP
Switching a singleton to a global is like stepping from shit into mud, really.
22:00 unique_ptr can solve that issue for you though. It has custom deleters. But I'm not convinced it should be on the heap in the first place.
Singleton ensures you have one instance of a class.
unique_ptr is about unique ownership, not unique instance.
Switching a singleton to a global seems like switch C++ to C. Memory management is another issue. Basically, I'm not convinced that memory management should necessarily be embedded into the class, because no one can predict exactly how this class will be used. It becomes harder to test, mock, and so on.
@@ilyashcherbakov4115 you might want to check the timestamp to see why I brought up the unique_ptr.
extern is the correct way to make a global variable
I agree! At minute +-17 he mentions `static` and `inline` but not `extern`. Declare the variable as normal in the `.cpp` file (the translation unit), then as `extern` in the header file. This is the "correct" (traditional) way.
any reason not to use a unique pointer to prevent dangling pointer?
Yes, but it's advanced, for example , managing a memory areana or optimizations of object memory layout or a constexpr capable version (not available rn)
RAII
@@patryk3772unique_ptr is a RAII smart pointer, you call the constructor through make_unique and the destructor is called via RAII rules
An unique_ptr has to be moved with std::move and it leaves the context of the class module, when you use it outside the class module. And as the init and shutdown methods are there, there is almost no danger of a dangling pointer. And there is no further abstraction with additional code which means more performance and less overhead. But that's only my humble opinion...
@@sascha9778 unique_ptr doesn't have any overhead.
can you make a common practices video with a bunch of essential tips from writing code to file names and so on
Keep it deep!
Encouraging the use of new and delete isn't great when we've been given smart pointers. Promote best practice instead? I guess you didn't want to muddy the waters by talking about smart pointers, but you kind of ended up there anyway with the System utility class!
Great stuff. Keep it up.
I like the new format with one priviso: I like to see code examples. So when you take a side turn to talk about something really cool, it would be nice to back it up with a minimal example code. You don't need to talk about this example code, you just give us a link to the repository and let us look at it. Kind of like homework where we have to figure out what is going on in context to the points you made. It doesn't have to be part of the code you are reviewing.
only a c++ programmer would have a christmas theme in his room in the middle of summer
Southern hemisphere...
When we abstract away the g_ResourceManager pointer into functions from the ResourceManager class, why is our pointer public then? Wouldnt it make more sense to make it private?
Nah, no reason whatsoever to change that. Just because you don't need singletons doesn't mean they aren't a valid pattern. You yourself noticed the downsides of your approach at the end. This isn't Zig or C where you should defer or goto cleanup but you should automatically manage that. So yes, RAII. But then the whole point of the global variable falls appart, since globals should have static lifetime. So no, bad idea to want to do cleanup through globals.
Here they are actually worse than globals, because you have lazy initialization (which is comparatively heavy), which has no business being lazy. So doing that is just "keep it simple"
wouldn't you get double free error if you accidentally call shutdown twice? rather put a nullcheck before deleting resources
In C++, delete is safe to call against nullptr. So as long as you are setting the var to nullptr, it's safe. clang-analyzer will actually give you a style notice if you wrap your deletes in nullptr checks.
I dont like your new format... I LOVE IT! Keep on doing this! Best regards from Germany.
Peache & Love, Sascha ☮❤
can you make a tutorial on building Hazel on clion?
Hahaha ))) The main function is the friend, I don't know how you came up with it😅
I personally don't think setting something to null or passing around null is a good idea, like ever, which is also why I prefer to use stuff like optional. I mean this case is basically an enclosed system so I don't know how I would do it with the least amount of complexity, but I guess I would probably work with dependency injections instead of singletons or globals.
? Like templates?
@@w花b Yeah, there is a std::optional in the standard library, so I just use that
Yaya a follow up
I was waiting for you to take those filenames out of the system and make the resource manager generic. I guess thats part 3.
Plus there was zero multithreading protection.
Why run a cleanup process at the end of the program? in DEBUG at least, cleaning up all resources will inform you if some of them were not released, or other usage lifetime bugs where something is loaded but never released. This could point to memory leaks that you at least should be aware of, even if they are benign. Maybe all the resources the cleaner references are known, well and good, skip that in release.
You should do a tutorial on Virtual File Systems :)
C++ is the one language where exceptions make sense lol. They're borked in Java, C#, python and their friends.
Never liked to use exceptions. Moreover, I've never encountered exceptions in any commercial software I worked on. Often RTTI is off.
@@Stariy_Pirat You're either working in _extremely_ constrained environments or you're just wrong.
The one thing I'd totally disagree with here is to leave it to the OS to do *any* resource cleanup, even memory. Do it all in your program at the end of execution, because it's not nearly as slow as you think it is, especially if you use arena allocators more and do fewer singular allocations of random objects. However, the RAII idea is a great one that I use myself all the time.
You say you totally disagree but you haven't offered any arguments. The fact that it might be "not nearly as slow as you think" isn't itself a reason to do it.
@@ax13h Well, specifically hardware resources that require special initialization and shutdown procedures, which was mentioned in the video. But if you meant in the specific case of memory, despite my statement applying generally, then I'd say if you have a problem with deallocating, then once more I say use arena allocators. Ideally you should be using them anyway for all of your memory allocation needs when doing massive quantities of object cycling as you would in a game.
brb... just updating my CV to say 'C++ Artist' 😂
Does anyone know his Visual Studio theme?
Why you do not use unique_ptr?
So if we don't need to release resources because the OS will free them by us when the app terminates, why do memory leaks exist?
Example: every frame you create an object and don't free it, let's say it is 8mb (like a full hd rgba uncompressed texture). Then, the memory of your program goes to 32g after 4000 frames, which is like less than 1.5min, and then you're out of RAM an are dead) so, mem leaks on the cpu side are all local to the running instance of your program.
If you have a program that's been running for a long time it will eventually reach an insane level of memory usage and will get slower and slower
Something something rust something something
What happened to the raytracing series?? D:
Getting rid of singletons are always a good thing. see Peter Muldoons excellent presentations pointing out the why and the how. Singleton really is unnecessary, it's just a thing vail over a global variable. You can program as if you have a singleton for simplicity, but it rarely needs to be it.
More plz. :)
Honestly the way I'd rewrite the ResourceManager, is to basically have it expose an api that allows to get a resource. So basically only one public method "Get()" (and no Load() method), and what Get does is basically tries to return the texture that you need based on the path, and internally it checks if that resource has been asked for already. If not, it loads the resource into memory, caches it inside an internal data structure and then returns it. Next time if the same resource is asked for, it immediately returns it from its cache.
What this also means is that there's no need for any code in main or the static Load() function at all in the first place. You'd then only need to call the get function at the exact place where you need that texture, and the resourceManager automatically handles all the loading and makes the Get() function more efficient. On top of removing all that unnecessary code at the beginning of the program.
There are reasons to preload, also with your idea you can’t tie a resource to a specific “scene” for unloading
@@UhGoomba that has nothing to do with my idea of course. If a scene or project has a resource manager as a member object then textures can be unloaded just fine.
There are reasons for preloading indeed and if necessary they can keep that function after profiling.
What happened to 'Ray Tracing' sereies! I am waiting for the new one!
Netflix and chill? Nah code and chill 😄
Yeah but singleton pattern designs for systems makes those systems easily reusable in other projects and software.
do 4 more projects to complete the signs "C" "H" ... :)
SFINAE please in the C++ chanel
What if brainfuck vulkan bindings?
I think I'll add that to my next implementation. Thanks for the idea.
I don't see any real gains in the changes you made. You just highlight that there are 100s of ways to do anything in C++ and none of them are the 'right' way.
Australians... the wear sweaters in July, weird people.
honestly can’t tell if this is a joke or not lol
@@Luka-lm1pr it's winter in Australia
Yeah because it's winter in the southern hemisphere. Summer in the northern hemisphere.
@@Careem-zk3nj yes, luka knows that, that's why he commented
better than before stick to it explanation thing and more coding
The 3:34 explanation is nice, but all you ended up doing is changing a singleton to a global. I feel like you always get hung up on some kind of detail, and then you never end up looking at the actual interesting parts of the code. I don't think this warranted a 23 minute video.
I honestly think this is worse than a singelton…
If you want to improve it just create a Game or Application class and have it own the resource manager.
Makes it scoped and the ownership clear. Doesn’t need to be heap allocated.
Really no reason for it to be neither global nor a singelton…
Use Rust that's how it could be solved
I was homeless, did drugs, went into prison, where I got to know God. He changed my life. Now I have a home, a wife and a lovely year old daughter (zoe), and a stream of income that gats me $47,000 weekly. Plus a new identity - a child of God, Hallelujah!!!🇺🇲❣️♥️❤️
Please how do I go about it, am still a newbie on investment trading and how can I make profit?
YES!!! that's exactly her name (Mrs Elizabeth Regina Nelsen) so many people have recommended highly about her and I'm just starting with her from Brisbane Australia🇦🇺
Wow. I'm a bit perplexed seeing Elizabeth Regina Nelsen been mentioned here also Didn't know she has been good to so many people too this is wonderful, I'm in my fifth trade with her and it has been super
I'm a long term investor, I withdrew my profits of over £61,000 during the covid-19 pandemic.
After I raised up to $225k trading with her I bought a new House and a car here in the states also paid for my son's surgery (Oscar). Glory to God shalom..
Most C++
Is these four:
1.C
2.objects
3.templte
4.constexpr
Bad video. There was no reason at all to move away from the singleton pattern to this global pointer. The best solution here is the singleton or dependency injection.
Dependency injection in engine development is crazy talk. More work for the cpu, more pointless work for the programmers.
I think you should explain your reasoning
You should develop your opinion a bit more. This video is specific to C++, which means rather low level programing. In this case, being aware of the classes lifetime is very important, especially since there is no garbage manager or whatever
Sounds like Java or c# opinions. Global pointers don't need wrapping
I would personally go for something one may call dependency injection, but not with virtual functions, but this is not necessarily a worse pattern, given that you make proper use of namespaces.
Global variables have advantages, like that they're not guaranteed to be there safe, like static fields (meaning no atomic operations if you don't need it), that simply makes it faster and keeps it off the stack, so you can have other stuff there.
If you allocate it on the heap, like with this video, I don't see the advantage as much though...
Rust joined the chat 🦀
Sorry, but globals are so much worse than singletons
I'm fourth 😂
You might like Rust a LOT.
first comment
nvm im second 😓