Well, one thing he did say is he doesn't trust anyone. People drop projects eventually, companies change management or ownership and so on, so the use of third party libraries in that sense can bite you.
You should make your own tools from time to time as it will give you some experience in creating modular code that can be reused for other projects and insight into what goes into making libraries. For third party libraries that are written with the explicit intent to be used by others, they go through testing and continually get bug reports from the community to fix.
One of the benefits to using a third party library is not having to learn everything on your own. SFML for instance, makes it super simple to create a window, render graphics to the window and even create and manage socket connections. All Windows/Linux/etc API calls are encapsulated in SFML classes and the sf namespace. Last I checked they are stuck using C++03 standards/idioms to support the most compilers and code bases, but C++ standards/idioms nonetheless.
In order to avoid using third party libraries, you will need to learn all the things that a third party library would have supplied had you gone that route; creating and managing a window and it's message loop, setting up/initializing the graphics library ( OpenGL, Direct3D, Vulkan, etc ), creating and managing network resources, handling packets, multi-threading and so on.
He's technically not even following his own rules exactly if he even uses any of the C standard library. He surely isn't writing assembly code to make his own printf functions or rewriting his own memory allocators. First party would be code you wrote and third part would be code someone else wrote, so wouldn't the standard library also be a third party library? Yeah, the language has been around for 40+ years, but you can't be an absolutist unless you wrote your own standard library from scratch using ASM or something even closer to the metal, like the code for the processor you are running on.
Yeah, I'm nitpicking here, but it just shows how absurd it is to say "never use third party libraries".
If anything, use the third party libraries on a few projects. While you are learning new things, start replacing it with your own implementations. Heck, the chili framework is third party and he has repeatedly said learn on it then replace with your own. Third party libraries are there to help, not screw you over hopefully. You probably won't have to worry about a company dropping support and leaving you with your pants down. You will have the code on your machine and unless they start requiring licensing fees for the use of their code, you can modify or replace what you need. Not only that, you probably won't be switching libraries mid project anyway, so when the project ends just use another library or write your own from there.
Code: Select all
#define internal static
internal void
Win32DisplayBufferInWindow(win32_offscreen_buffer *Buffer,
HDC DeviceContext, int WindowWidth, int WindowHeight)
{
StretchDIBits(DeviceContext,
0, 0, WindowWidth, WindowHeight,
0, 0, Buffer->Width, Buffer->Height,
Buffer->Memory,
&Buffer->Info,
DIB_RGB_COLORS, SRCCOPY);
}
I like the grouping of the StretchDIBits() functionc all, with the exception of DeviceContext being up on the same line as the call to the function:
Code: Select all
// I personally tend to miss the linkage specifier and return type if it's not on the same line as function name.
// Also, if you are going to make the param list vertical, might as well make them all vertical
internal void Win32DisplayBufferInWindow(
win32_offscreen_buffer *Buffer,
HDC DeviceContext,
int WindowWidth,
int WindowHeight )
{
// This may seem inconsistent with previous comment, but I can't see putting 0, on their own lines, especially since
// they contextually are grouped with the width and height params.
StretchDIBits(
DeviceContext,
0, 0, WindowWidth, WindowHeight,
0, 0, Buffer->Width, Buffer->Height,
Buffer->Memory,
&Buffer->Info,
DIB_RGB_COLORS,
SRCCOPY );
}
Also, spacing is key, which is something else he pointed out. I always put a space after the opening parenthesisand before the closing parenthesis: DoSomethingWith( myVar );
Actually, I have VS setup to do this for me when I type a closing brace } or copy/paste my code.
Don't worry about the details, code how you want, learn your own style and don't let the minutia get in the way. You'll find what works for you and it may not be what others like or agree with. I was on a kick of using Hungarian notation which prefixes member variables with lower case m_, global vars with g_ and the like. Some find it useful to avoid naming collisions so they can reuse the simpler name without the g_ or m_ prefix as a local function variable;
const float radius = m_Radius; . Not everyone likes it. Recently, I have started prefixing function parameters with an underscore for the same reason, so I can reuse the simpler name for locals. Others go the other way round, prefixing their member variables with the underscore. I have also tried underscoring long names instead of using camel case, yes it's descriptive but ugly.
int some_really_long_descriptive_name_for_an_int
int someReallyLongDescriptiveNameForAnInt
Ok, neither one looks nice, with the underscore one looking only slightly better. What I realized though by doing it was my variable name length grew larger than needed. I felt more free to describe what the variable was and did in the name instead of just a label for what it was in context.
float dot_product_result_between_light_direction_and_surface_normal = dot_product( light_direction, surface_normal );
float lightIntensity = dot_product( lightDirection, surfaceNormal );
Ok, maybe I didn't really write out something like that, because I'll be damned if I'm going to write that out each time thereafter when I want to use it, but the idea is there, especially if I didn't know a technical name for it like "light intensity" lol.
Just showing that you can be fluid with your coding style until you land on something you really dig. If you do get into a team project, professional or otherwise, it's always a good idea to get everyone on the same page with coding styles. Keeps the project coherent and readable and makes it look like it was written by one person and not hacked together.
If you think paging some data from disk into RAM is slow, try paging it into a simian cerebrum over a pair of optical nerves. - gameprogrammingpatterns.com