Another way of supporting multiplatform
Posted: Wed Aug 31, 2016 3:14 am
Hello, I've recently been getting ready to work on my first multiplatform project for DC and PC, and I'm not too sure of which way I should support multiplatform.
The obvious and maybe naive way would just be a bunch of preprocessor directives on all the function definitions and whatnot for conditional compilation, but this easily gets messy very quickly and is probably the worst way of doing it.
Another way I could think about it is creating separate static libraries for each platform, so the main project code should be platform agnostic because the implementations are handled by linking with the correct library. The drawback I see is that when you're developing, you're likely going to have to update the library very often, so you'll have to keep rebuilding the library and then rebuild the code with the new libraries. And you kind of have two codebases, one for the library implementations and then one for the actual project.
I thought of another method, but I'm not sure if it's a great solution.
First you would have a general platform.h file #defining the platform that is being built for.
Then you'll have your generic, platform independent main project code like
And then you'll have
and finally
You're still using the preprocessor, but it's only once per file at the beginning to include the correct implementation.
And since you're using static functions in the implementations, there are no naming conflicts, and based off which implementation was included, you'll call the same function which will resolve to different implementation.
So essentially the platform independent functions are just wrappers for the implementation.
The possible drawbacks I see is that there is no guarantee they will be optimized with tail recursion, so the extra function call will set a new stack frame and obviously it will bring in overhead and will be slower. There is no guarantee it will be inlined either.
Thoughts?
The obvious and maybe naive way would just be a bunch of preprocessor directives on all the function definitions and whatnot for conditional compilation, but this easily gets messy very quickly and is probably the worst way of doing it.
Another way I could think about it is creating separate static libraries for each platform, so the main project code should be platform agnostic because the implementations are handled by linking with the correct library. The drawback I see is that when you're developing, you're likely going to have to update the library very often, so you'll have to keep rebuilding the library and then rebuild the code with the new libraries. And you kind of have two codebases, one for the library implementations and then one for the actual project.
I thought of another method, but I'm not sure if it's a great solution.
First you would have a general platform.h file #defining the platform that is being built for.
Then you'll have your generic, platform independent main project code like
Code: Select all
/* graphics.c , platform independent code */
#ifdef _PLATFORM_DC_
#include "graphics_dc.c"
#else
#include "graphics_pc.c"
#endif
void drawString(const char* str, short x, short y)
{
/* Theoretically this should be optimized using tail recursion, or will be inlined */
drawString_impl(str,x,y);
}
Code: Select all
/* graphics_dc.c , DC specific implementation */
static void drawString_impl(const char* str, short x, short y)
{
/* ... */
}
Code: Select all
/* graphics_pc.c , PC specific implementation */
static void drawString_impl(const char* str, short x, short y)
{
/* ... */
}
And since you're using static functions in the implementations, there are no naming conflicts, and based off which implementation was included, you'll call the same function which will resolve to different implementation.
So essentially the platform independent functions are just wrappers for the implementation.
The possible drawbacks I see is that there is no guarantee they will be optimized with tail recursion, so the extra function call will set a new stack frame and obviously it will bring in overhead and will be slower. There is no guarantee it will be inlined either.
Thoughts?