Even though we're almost done with the initial platform layer, the Q&A last night suggests that it would be useful to have a thread containing other platform equivalents for the win32-specific stuff Casey demonstrates. At the very least, it might be useful to point folks to solid resources.
For example, in stream 021 Casey showed us how to dynamically load and unload the game code on win32 using LoadLibrary, FreeLibrary, and GetProcAddress. The equivalent functionality on OS X (and any POSIX-compliant system, really) exists in the following functions:
| void* dlopen(const char* path, int mode);
int dlclose(void* handle);
void* dlsym(void* handle, const char* symbol);
|
These are pretty well documented both on the web and on most systems' man pages, and they function more-or-less identically to the Windows equivalents. Apple also has a pretty useful document describing the usage of these functions
here.
Like Windows, OSX gives you a away to run certain code when your library is loaded or unloaded. I've always heard these referred to as image initializers and finalizers, and they are discussed
here. The upshot is that you can tag functions with a special compiler attribute to make this happen:
| __attribute__((constructor))
static void some_initializer_function() {
// your code
}
__attribute__((destructor))
static void some_finalizer_function() {
// your code
}
|
You can have multiple initializers and multiple finalizers. Initializers run in the order the compiler sees them, and finalizers in the reverse order. I don't know that we'll ever use this -- Casey has suggested we'll avoid this kind of OS-dependent thing in the game code -- but there you go.
Finally, to get started creating dylibs (the OS X dll equivalent) using clang, you do this:
| clang++ -dynamiclib [other compilation switches] file.cpp -o libfile.A.dylib
|
There are other dylib-specific options, but that will get folks going. You can learn more
here for OS X.