The last thing Casey does (in the Q&A) in Day 029 is split handmade.h into handmade.h and handmade_platform.h, the latter being a pure-C file that contains all of the game layer stuff required for the platform layer to communicate with it. It seemed like there was some practical impetus for doing so, but I don't understand what it was. He mentioned something about people requesting it in order to port to other platforms.

What was the advantage of splitting out the platform-related stuff into its own file? What was the advantage of making handmade_platform.h pure C?

Also - I noticed that the #include handmade.h in win32_handmade.cpp wasn't changed to #include handmade_platform.h until day 039.

Thanks.

Nimbok
What was the advantage of splitting out the platform-related stuff into its own file? What was the advantage of making handmade_platform.h pure C?

The idea is that we always compile the game code as C++ into a shared library (.dll on Windows, .so on linux, .dylib on Mac (I think) ) and the platform executable will load this code. The communication between the two part (executable and library) is a tiny part of the code and by putting that in it's own file we defined a clear "interface" for what needs to be supported by the platform.

I'm not 100% certain about the pure C part as I've never called C or C++ code from another language. But my understanding is that, C++ function name mangling isn't the same on every compiler, while the C one is. And according to the previous wikipedia article, some other language compilers can "understand" the C name mangling and so it's easy to call C functions from those languages. Maybe someone more knowledgeable can confirm or infirm that ?

Thanks, mrmixer. That helps me understand a bit better. It looks like Casey said people were specifically asking for something that could compile cleanly in C if you were trying to write a platform layer in something that couldn't compile in C++ code. I missed this when reviewing the video because it was tacked on to the end of the prior section. The name mangling compiler behavior in C++ not being consistent is also an excellent point.

Somewhat related question from Day 024 (@51:06):
Casey mentions that people working on porting to other platforms were running into trouble due to the stub functions in the header file. He said that "the stub functions (GAME_UPDATE_AND_RENDER and GAME_GET_SOUND_SAMPLES) being in the header means that if they have multiple translation units that all include the header file, the thing gets defined multiple times." I understand that the stubs are a function definition, but doesn't the one definition rule only concern multiple definitions within a single translation unit? Why would there be a conflict here?

In One Definition Rule on wikipedia, in the second item of the summary it says:

In the entire program, an object or non-inline function cannot have more than one definition; if an object or function is used, it must have exactly one definition. You can declare an object or function that is never used, in which case you don't have to provide a definition. In no event can there be more than one definition.

If you think about it it's logical: the translation units produce object files that will be link together, and if there were several definition for the same function signature, the linker wouldn't know which one to use.