I'm currently doing the rpg part of an engine without worrying about rendering or external libraries because I'm learning C++, and I'm doing a single cpp and lots of header files. It's a matter of preference and of use. I think an engine is more prone to be a header library. You can add as many cpp files as you want when making an actual game and easily import your engine to whichever part of your game needs it. Although it's a few weeks of work so I don't know if I'll have to refactor yet
One big benefit of splitting the code is build times. Unless you do a full rebuild, the only .cpp files that have to be compiled are those that were modified, either directly or because an included header changed (one reason why implementation should be in .cpp files and not directly in the header, of course if there is only one .cpp file that can include them, it doesn't matter, since now every tiny change anywhere will force a full rebuild).
@@TheTrienco I did hear about that. I'll probably start doing it when introducing input control, rendering, physics if any, gameplay loop and similar stuff. As of now I'm doing pure C++ programming for core systems that are not really that big on their own, so I think I can keep going for a bit. I do see the appeal for a full scale project though
@@sechmascm For smaller tools it often doesn't matter. I have a habit of starting off projects with "just trying" stuff and dumping it all in one file. By the time you get to the point of "I really have to get structure into this mess" it takes 10x longer to sort it all out and is a painful experience to untangle it all.
The only part I don't like about not cleaning global/static resources is now the need to cherry pick resources when running sanitizers or any other leak analyzers / memory profiler (for example, -fsanitize=address,undefined and valgrind). I like sanitizers reports showing 0 leaks. If only the language had a way to state intentional leaking... For me, the problem is not "to clean or not to clean", but how expensive is your cleaning procedures. If your static cleanup takes 10s, probably you're calling thousands and thousands of free's or close's and you probably are not allocating rationally. The actual mistake for me is that you're not polling those resources which would make cleanup cheap.
"Where does he live".. Australian I believe
Southern Hemisphere bro. It's winter there now!
remember: Cherno dont know how varargs works
he just made much more mad code from this LOL
now we have asmonfuckinggold in c++ too wtf
This guy is exactly what I needed on my second monitor
yeah, but this one is around 5x dumber.
Useful content ❤
I'm currently doing the rpg part of an engine without worrying about rendering or external libraries because I'm learning C++, and I'm doing a single cpp and lots of header files. It's a matter of preference and of use. I think an engine is more prone to be a header library. You can add as many cpp files as you want when making an actual game and easily import your engine to whichever part of your game needs it. Although it's a few weeks of work so I don't know if I'll have to refactor yet
One big benefit of splitting the code is build times. Unless you do a full rebuild, the only .cpp files that have to be compiled are those that were modified, either directly or because an included header changed (one reason why implementation should be in .cpp files and not directly in the header, of course if there is only one .cpp file that can include them, it doesn't matter, since now every tiny change anywhere will force a full rebuild).
@@TheTrienco I did hear about that. I'll probably start doing it when introducing input control, rendering, physics if any, gameplay loop and similar stuff. As of now I'm doing pure C++ programming for core systems that are not really that big on their own, so I think I can keep going for a bit. I do see the appeal for a full scale project though
@@sechmascm For smaller tools it often doesn't matter. I have a habit of starting off projects with "just trying" stuff and dumping it all in one file. By the time you get to the point of "I really have to get structure into this mess" it takes 10x longer to sort it all out and is a painful experience to untangle it all.
I hate code reviews. It is nothing more than arrogant opinion vs arrogant opinion.
Having more files doesn't make it a complicated game
I learned opengl from Cherno
The only part I don't like about not cleaning global/static resources is now the need to cherry pick resources when running sanitizers or any other leak analyzers / memory profiler (for example, -fsanitize=address,undefined and valgrind).
I like sanitizers reports showing 0 leaks. If only the language had a way to state intentional leaking...
For me, the problem is not "to clean or not to clean", but how expensive is your cleaning procedures.
If your static cleanup takes 10s, probably you're calling thousands and thousands of free's or close's and you probably are not allocating rationally. The actual mistake for me is that you're not polling those resources which would make cleanup cheap.
Very hard to understand what you say when you talk overlapped with him.