epic chad project 💪💪 thanks for sharing it with us

As a C newcomer, thx for that gigachad advice

You should probably still push the string_views to a tree-like structure for fast lookups

@@maksymiliank5135 the whole json document is stored in a tree, the string_views are just used for identifiers and stuff like that

I am a virgin and I use "Player p;"

for real 💪💪💪💪

cant leak anything if everything is stored on the stack with a 1000 element array!

if you really need a lot of objects of a type and have to use the heap, i would just consider making a whole class to handle the memory alocation and deletion there and it would act just like the regular object, it's easier imo edit: here's how the class would look like: template class HeapObject { protected: T *ob; public: HeapObject() {ob = new T;} ~HeapObject() {delete ob;} void operator=(T a) {*ob = a;} /// other methods, i can't be bothered to give more examples, it's just here to show that you can do it T operator*() {return *ob;} };

@@atackhelikopter4303can even be an abstract class and the concrete ones will decide the implementations

exactly

exactly 💪💪

well I don't actually use shared pointers like ever :))

@@lowlevelgamedev9330 shared pointers cause more problems than they solve in MOST cases so that's good. Unique pointers, however, are an improvement on using the new keyword in every single way so definitely use make_unique instead of using the new keyword if you end up needing to manage your own memory allocation, like when storing large objects on the heap.

@@lowlevelgamedev9330you dont have to … its still recommended to avoid new

And does that help you with memory fragmentation in any way? no? then what do you earn from this? the point of this video is for using stack allocated variables or preallocated static buffers for data. The more static allocations you do, the less you will need to dynamically allocate stuff, the less of a performance hit for your program (less fragmentation and less time wasted waiting for the OS to reserve a chunk of memory for you...). If you need to dynamically allocate, then do so in buffers or large chunks so that you don't have to allocate every single instance one by one individually. It's that simple. Using make_shared and make_unique does not save you from those problems. First, you should try to understand what the heap even is and how it works...

@@tiranito2834 You grossly misunderstood my comment.

yes I know, but that is not my concern, my concern is to not have memory problems. 💪

Contiguous heap memory, stack memory isn't a big deal when you need dynamic size tbf if you get cache locality out of it.

The only overhead from a heap is the allocation itself. If you allocate the objects as an array you still get all the benefits of cache locality and fast memory access of the stack. And if the size never changes then you don't need to reallocate so using this memory is essentially free.

Is this the same like vector of pointers?

@@zanagi No, it's normal vector, but with different allocator (std::vector takes an allocator as second template argument). It basically allows you to preallocate memory block on stack and then suballocate from it. Allocations are fast and close in memory.

yeah I actually write my code like this now usually 💪, it just wasn't worth the effort changing that code there

So the resource loader would be on the heap? < kind of new to c++

RAII is the stack though, like anything you create on the stack is managed through RAII, unless its a primitive data type, it will call the constructor on initialization and destructor on leaving the scope, that is RAII.

yo this sounds dope, I approve 💪💪

@@Spartan322 I assume these are defined in some top level function (maybe even in main) and passed around to other functions as pointers/references so RAII will not trigger as often

@@maksymiliank5135 Doesn't matter, RAII is stack allocation and that's still the stack, the object itself may allocate on the heap, like smart pointers or vector, but all memory behavior of the object itself is on the stack and anything that doesn't allocate on the heap is stack allocated and also performs RAII.

Technically C arrays have the size encoded too, problem is they love to decay into generic pointers which can absolutely stab you in the back.

yo that is a good idea, yes 💪

@@lowlevelgamedev9330 nice!! I noticed your conventions seem clear, no bullshit, efficient !

well you know all the schools do that but you don't have to do the same in your code 💪💪 their example is just a simple didactic thing, I don't even use ecs in my games lol

lol that's how top gamedevs do it in game dev. If you look at top gamedev programmers that's what they talk about and they don't use unity they make unity :))

that is another story, and they crash because that is a mechanism made by the cpp standard library, to help you not forget to either detatch them or join them. If you make them using windows api I don't think it will crash

well I don't use destroyers in my coding style, except you know vectors and stuff have them, maybe I will make a video on it

@@lowlevelgamedev9330 oh ok.. that's fair.. yeah, vectors does the job automatically so.. its ok..

😂😂

You either used the vector wrong or one of the functions you passed it in mutate it accidentally. Either pass it as a const reference (no mutation possible) or as a reference (mutation possible).

@@sledgex9 I am sure I was not mutating, the vectors got passed as a "const &" since it was large The issue is that i noticed is that the entities within had different addresses for some reason, which was very strange to me

@@nazihboudaakkar8117 Unfortunately this kind of problem can't be diagnosed via a comment. All I can say is that vectors should work with no problems. Potentially a misuse was happening somewhere. C++ has many pitfalls you can fall into if you aren't experienced, unfortunately.

If you take a pointer to an item in a vector and then you add/remove things from the vector, it will invalidate the pointer because under the hood reallocation happened.

@@swansonair As I said earlier, I was passing the vector around as a const reference precisely to avoid that and to avoid needlessly copying the contents The issue got solved the moment i changed the entities to be on the heap, I clearly remember not touching anything (besides refactoring things to use the unique_ptr) and It felt sooo awkward But yeah, it was probably a bug on my part

idk just visual studio tells me, maybe it is the productivity powertools extension that I have but I think it is just a visual studio feature

@@lowlevelgamedev9330 ok thanks 👍

That's provided by a Linter/LSP like Intellisense or clangd. (Finding the size of a structure of class.) Just use the (sizeof) keyword/function. -It's not hard to do the math yourself if you know the size of element the class is holding.- -Lets say you have a "Position2D" or "Point2D" class, it obviously needs to numbers to represent the coordinates, so 2 integers/floats (4 bytes * 2 elements).- -You might also want a constructor, in this example we'll treat them like function pointers, which on a 64-bit architecture is 8 bytes (a.k.a. a long pointer.)- -That's 16 bytes, not including the default class functions that modern C++ provides.- Finding the padding is near impossible to do programmatically as it's determined by the compiler. (This is why clangd and Sonar Lint suggest you state the padding of each element in a structure.) This is all from my understand(ing), I might be wrong so it's best to do your research.

@@somedudenamedanthony why tf you wrote all that. I goggled it, I update visual studio. Will test it later

that doesn't really sound good :))) and I also don't get how what you are describing has to do with the heap

@@lowlevelgamedev9330 if i use the stack, the size for structs and classes will be fixed, like: struct A {}; struct B { A a; int bar; }; So, ignoring the class optimization thing that some compilers do, and considering that A and B are on different headers and .cpp files respectively, if I change A to this: struct A { int foo; }; For the .cpp file of B, it still thinks that A has not changed, but A has changed, so A.foo becames the same as B.bar, making some really weird bugs and eventually leading to UB. My fix is to defined the heap allocator for each class inside the .cpp files and wrap foo and bar with getters and setters

I mean 1 is an oversimplification, if you have a simple system you do that or raii, but for a complicated system it won't look as clean

1. Just use smart pointers

so for the first thing, for example there are 5 players each one with a skin, and they can change. The index won't be invalidated, there are always 5 players, the skin can. That was the case that I was thinking about. If the index can get invalidated you would make sure to check for that of chourse. Also for the second thing I was thinking about sending the gpu id directly, like sending the opengl id, but it doesn't matter, the speed is the same roughly but I mentioned that it can be even faster to make my point very clear.In practice it boils down to how the compiler optimizes it and it is the case that for this thing it can be slightly faster or slower but very small difference

No, none of those actions leak any memory. It it the job of the OS to ensure that all memory from a process is reclaimed, if it didn't do that your memory would be gone in no-time (a program crashed and couldn't free its memory? Another 20MB never to be recovered! Nah...). So when a program terminates, either normally or forcefully (like with taskmgr), the OS will reclaim any memory that the process had not yet freed. Therefore, freeing when you are about to terminate your program is pointless, you're doing work that the os is going to do anyway, and when the os does it, it quickly cleans all your memory in one go instead of slowly one object at a time, which is what your own code has to do. All of this is also why it is okay to prototype code with leaks, it's not possible to eat away at the memory in between re-compiles, stopping the exe wipes away all leaks.

yes as the other comment suggested the os will clear everythingvery easily. Also most programs have leaks so it would have been a disaster if it didn't 😂😂

@@saniancreations I'm still in college (so I'm still a learner), we did plenty of tasks with memory allocation in C, and they told us to always clear the memory after we stopped using it. If you don't deallocate before the program ends and you run it with fsanitizer or Valgrind it will tell you that you have memory leaks

@@raykoranteng4667 That's because the expectation is that a memory leak is a bug in your program that had it been left running, would be unrecoverable memory without termination.

@@raykoranteng4667 Memory leaks are a problem so long as your application is running. When your program stops, all the leaks go away. If you have a program that runs for a long time or it performs a repeated operation, then not freeing memory is an issue because the memory usage accumulates over time, slowly growing bigger and bigger. _That_ is what you want to avoid. Most external diagnostic tools indiscriminately look at _all_ allocations, marking anything that is never freed as a leak. But not everything that isn't freed will cause your program to infinitely grow. For example, doing a one-time allocation at start-up and using it for the duration of the program will not grow your memory footprint over time. The only moment you need to free it is at the end, and in that case the OS can do it for you. I like to image leaks as actual water: A single droplet is okay. Not a leak. A glass of water is okay. Still not a leak. I can have a whole swimming pool in my house and that is still fine, because I deliberately put it there and it has a finite amount of water in it. But a _leak_ is a hole in your program, water pours out the hole indefinitely, until your house is flooded. That's a problem. But, "not freeing" is something you need to be careful with. If you _think_ you only allocate something once, but that code gets executed _again_ every so often through a weird edge-case, then you still have a leak on your hands, then your usage _will_ grow over time. So as a rule of thumb it is generally recommended to free all memory, just to be safe and to prevent stupid mistakes. In practice, for many small programs that have a clear beginning and end, not freeing memory is actually fine, it gets some memory to do a job, then it terminates and all the memory is cleaned up no-problemo. Pouring some water on the floor isn't a big deal if your house is about to get demolished. But if you have a large loop that can run an unknown number of iterations, you could end up pouring a thousand+ buckets of water on the floor, and you'll drown before the demolition crew gets there.

well people just allocate for no reason that's why

yes you got it 💪💪 advanced cpp is usefull for things like std::vector but its just too complicated to write that every day

what :) who uses cpp for backend. Cpp is used for gamedev very often

@@lowlevelgamedev9330 by Backend I mean Core of the engine not the cream part of a Game. Ofcourse you might have a F 35 but who uses it to go to grocessory store. Just use a LMEV

hi

how are you

Fully agree, for me its the same

well the point is not to have leaks so I don't care that vector is also heap, I just care that it doesn't leak like an unique pointer. Also yes the vector is 100% guaranteed to be contiguously.

I do use vectors, just because cpp has a feature it doesn't mean I have to do it. There are modern languages like zig that have no private variables or no exceptions

@@lowlevelgamedev9330 Right and one day zig will replace C. I enjoy your videos for the record they are awesome and well done. But please understand something on this level of advise. There are two programming languages. There is C, and there is C++. There is no such thing as C/C++ programming language. These tricks for memory leaks and all that is all C language stuff and not C++. This causes confusion to new comers who want to learn C++. If you going to use C++ but code in C style then just code in C. If there is a feature of C++ you like then use it properly. This makes the codebase all over the place and introduces code rot. Zig for the record is awesome and I cannot wait for its 1.0 release!

​@@romangeneral23 Sorry, but what makes this code "C style" rather than C++ style? Using automatic resource lifetime management with things like the stack, vector, unique_ptr, etc is very much a C++ thing and one C can't do and it's community has resisted adding. If you mean making classes and/or using inheritance, it is by no means C++ style to force those into a design without a reason. Same with exceptions. Same with new. Same with every other feature. I think you have the misconception. C++ is very much _not_ about forcing you into a particular style or design, but about giving you tools to meet the needs of your particular application. Nothing about the language forces you to use something you don't need.

well yes but that means I don't have leaking problems, what were you expecting, getting rid of leaks magically?

I think it depends on the programming language, for example, C and C++ always had problems with memory allocation and pointers. But newer languages have other big issues. So you have to find the best fit and dive into it.

@@rodrigomontebello I firmly believe that C is the reason pointers are confusing. In assembly they're not that hard to grasp

@@williamdrum9899 people are confused at pointers because they only learn what it does, not why it does that. so they dont understand why would they use them

ekamc

um I didn't really understood your comment but windows without question will free all the resources and it will do it quickly :))

My main point is that there is no valid reason to use the new keyword outside of a constructor, and even then you should tread carefully. And also no windows does not consistently free on exit. I've had, as recently as today, programs crash and stay resident and not boot because of that..

But to clarify exactly what I said, using the standard template library's unique_ptr type generates the exact same code as T:: operator new assuming you do not copy... And if you do copy, you are probably introducing bugs by not implementing a reference counter

yeah function pointers within structs is all you need actually

well it's normal. Procedural is both how people think and also how the computer thinks so idk who is thinking that functional programming is good :))

The limits of your language are really the limits of your world. And also, one youtuber is not a representative of "we" (assuming you mean programmers in general) and it certainly is not a representative of something we should be doing by itself, I see comments like this in almost any video where someone is using something even remotely close to what other people used in the past, even if the thing itself evolved in some way, it is surely "funny".

@@lowlevelgamedev9330 I found oop useful in cases where where you are modeling stuff properties and behavior, like video games or controlling devices. But I avoid class polymorphism like inheritance as most hierarchies are just arbitrary design decisions that are often bad decisions. Rust "objects" are ok. Mostly I do procedural even in Python. Functional programming is great for processing data, specially in high level languages. Rust functional features for example are ok. Pure functional languages are not worth the pain, as their obsession with avoiding side-effects and immutability is stupid in practice.

can you have leaks in java? I didn't know that, if you have some details I would love to hear them so you can tag me on my discord 💪💪

@@lowlevelgamedev9330 Not unless the JVM GC has a memory leak. The GC ensures there are no memory leaks.

@lowlevelgamedev9330 it is a myth Java doesn't leak. You simply have to mess the references to an object by not deleting appropriately containers or other kind of faulty memory management kzfaq.info/get/bejne/g9Jdnb2a1bvegJ8.html

​@@Spartan322 I mean, "leak" in the sense that it is lost memory you can't have (usually), but you can still "leak" memory in some sense by not removing all references of it from memory (like having some pesky static delegate somewhere or etc, even if it is a sign of smelly code).

@@diadetediotedio6918 That's not a leak, you might be erroneously retaining a memory location for your application, but memory leaks are quite well defined and without a memory leak in the JVM GC, it literally cannot leak, if that is a leak then any runtime static data is always a memory leak which is nonsense, an existing reference you could still access is not a leak, a memory leak must lose all references in the program and thus can only be cleaned up by OS upon termination of the program. (as without that memory reference the program can no longer recognize locate that memory to be manually deleted)

have you ever waited for a program to close? it happened to me. So tell me why should I dealocate the memory for textures that I use for my entire game? That's just waisted work. It is true that it probably won't take long but you don't have any reason to do it either

@@lowlevelgamedev9330 because you're closing your program, you don't need the texture anymore

@@lowlevelgamedev9330 I mean if it takes that long to deallocate everything, you are almost guaranteed abusing malloc somewhat fierce with way too many small allocations. You have yourself shown strategies here to stop doing that. Sure you can just leave everything be on exit but that precludes the use of leak analysis tools and the like, which is not ideal.

​@@lowlevelgamedev9330 Exactly. The only reason one would consider deallocating everything at the end would either be for correctness sake or because of the possibility of running that code on a system that doesn't free memory after a process is closed. To date, there is literally not a single active operating system that works like this, so... you are 100% correct. Not deallocating things that are going to be static is pretty much standard in the industry and is guaranteed to work basically everywhere. I mean, after all, what exactly is the difference between allocating a static buffer at compile time and allocating a heap buffer during runtime at the start of your program? the OS follows the exact same steps when loading the program and assigning the memory segments to the address space of the program. The only difference is that one is a static buffer with a size known at compile time, and the other is a static buffer with a size known during runtime (useful for loading files that can be modified, such as textures or any other assets). Besides... when you deallocate, your program is going to take longer between all the sleeping that the OS is going to put it through while its deallocating the reserved memory. Just closing the process allows the program to shut down visually for the user and then the OS can do the cleanup afterwards without having to make the end user wait any time for the program to shut down. This is just a common practice in the games industry, and one of the few practices that are actually good. I can understand people not liking it because it feels dirty, but it is still correctly exploiting the inner workings of the systems where the code will run, so...

Not deallocating memory is fine. Not closing a file or socket is not fine.

😂😂😂😂 It's ok, last time I checked I was still a male so I don't think I will