What I do to never have to worry about memory leaks!

in my C json parser I allocate memory only once, and it is while reading the files content, so then everything else that might need to access it's contents, like, we have a variable `"kind": "Person"`, instead of doing a copy of that memory, I just do a string view. so basically I just store the pointer to the start of the section I need from the string, and the length of it. I didn't did this in my first prototype, and for tokens I allocated 1024 bytes for each lexeme, but I figured out - mhh, maybe having a fixed limit on that is kinda stupid, and allocating 1024 extra bytes for each token is a bit of an over kill - so by doing a string view, I allocate 1 pointer + 1 size_t, so we just allocate 12 bytes in total :D ( this depends on the size of size_t in your computer and the size of a pointer, but it is still way better than allocating 1024 bytes ) so remember guys, never allocate memory if you don't need to, neither in the stack or the heap, just allocate as much memory as strictly needed for your program to work!

1:30 the virgin "Player *p = new Player();" vs the chad "Player p;"

that's the neat part: you don't

Since you are using containers to store your entities, your entities are on the heap (cuz the elements of a container are allocated on the heap), so you are not using stack memory at all. Besides this, nice advice!

4:21 you can probably get rid of the call to `new` in you filedata var. Make use of the appropriate overloaded constructor to create an std::vector initialized with X elements of unsigned char zero initialized aka std::vector<unsigned char> fileData(fileSize). And the use it like this "file.read(fileData.data(), fileData.size());". This takes advantage of the fact that a vector is guaranteed to use contiguous memory to store its elements.

std::pmr::vector my beloved

2:40 let me introduce you to std::make_unique() and std::make_shared(). Almost never use the `new` operator to initialize a smart pointer.

To be honest, avoiding the heap for any programming at all is a great rule of thumb. The edge cases where you'd actually need the heap are pretty few and far in between.

Almost every component of my ECS is living on the stack 😅 .. who needs names or endless strings, user input is limited, e.g. player name is max. 24 characters. Expect for textures, sound and other assets ... .. there are living in the resource loader, loaded once, freed at the end. The only things that are RAII, are my Scenes/Levels, with init(), enter(), exit() ... Methods ... The Scene itself lives in a "Context" variable (held in the Scene manager). When switching scenes, the scene either gets "disabled" or uninit/init. Everything else lives in the ECS registry/world, the scenes queries the components there need.

2:21 don't use raw arrays. Use std::array instead. They encode the size in them. Also the compiler would be able to make it as if you used a raw array. Aka zero overhead.

It boggles my mind how many people keep insisting that you need to often deal with memory management in C++, like in almost every case I've observed, if you're managing memory directly, you should be using a container of some sort, or you should be using the stack. There are even only a limited set of reasons to deal with a raw pointer directly without managing it. Ownership semantics with smart pointers even support dynamic arrays now, so why would you never not use them? Probably because people don't bother the learn C++ and just keep doing things the C way.

Just the thing I needed in my current development phase. Thanks for all the great tips, I'm really enjoying your videos.

your channel has been invaluable to my coding hobbies, thank you!

Anyone have a link to an explainer on why heap allocated memory may be accessed slower? I thought access times after allocation/the first access would be just as fast as stack allocated memory.

using containers is just like using new/malloc, cuz they all allocate memories on the heap (besides themselves on the stack)

I wrote a renderer with C++/Vulkan for 2D cad stuff and even in 2-3k lines of code I use new all of 3 times to allocate some command pool objects. Don't need new that often.

So basically code C++ like how you code in C, only use C++ features if necessary, and avoid unnecessary use of heap

What would you then suggest when you have a situation where class A has a member B, but which it doesn't want to initalize straight on A construction, as perhaps it has to do something else first. One could then just let B have an empty constructor and use an Init method but this then goes against RAII, so it seems to me like the only two options in this case is break RAII or use a unique_ptr

Totally agre on 1:30. Some seems to use alloc & pointers way too much even when not needed - just KISS! (Keep It Simple, Stupid)

Allocating on the heap is fine. What matters is whether you can predict how much memory you'll need. If you can't, then you won't be able to manage your memory because you don't have a good concept of what it's doing. If you can, then it's simple to just free it all at once way later when you're done with it. As long as you're not interleaving tons of mallocs and frees you won't get into trouble, and that's to say nothing of what's possible when you realize malloc is garbage and you can easily do syscalls yourself. This is the true meaning "of don't allocate more than you need to", advice that's been misconstrued greatly over the years.