Coding Layout For Platform Independence|
I like coding for platform independence, I won't try to sell it's laurels here,
there are plenty of others who would do a better job than I. The next step after
deciding to code for platform independence is to decide how your going to
structure your code to make this work. I've seen much source code that is
littered with #ifdef WIN32 etc that, to me make code look ugly. I decided to do
it in a way that left all my code devoid of pre-processor macro's.
For example I have created a class to handle my video interface. Normally you
would create Video.h and Video.cpp, then divide up each function with
pre-processor macros to seperate the platform epended code from each OS within
every function. I use a different method. I create files like this Video.h,
Video Win32.cpp, Video Linux.cpp. Then I ensure that no platform specific code
is in the interface so the headers are all platform independent. To ensure that
no platform specific code is in the header I find a similar data type and use
that, often this means storing void pointers to platform specific classes.
The CVideo class in win32 should store a HWND. Since other operating systems
wouldn't use a HWND I just used an unsigned int to hold the window handle. Then
when I want to get and use that handle in win32 code I just cast it back to a
HWND likewise in other OS's that use window handles, they cast to the
appropriate type. The disadvantage here is that you need to know at least a bit
about how other platforms work before deciding on how your going to store your
data. For example imagine supporting a platform that didn't support window
In MSVC the project will include the correct implementation(cpp) file, in Linux
the makefile again would reference in the it's appropriate implementation file,
leaving headers clean to be called by any part of the project without any
knowledge of the internal workings of the implementation. Your interface
completely hides the platform implementation.
As a side note or those wanting an extra layer of protection against incorrectly
included files you could add this to your source files:
# error Incorrectly included file. This file should only be included in
This will catch source files meant for exclusive use on other OS's during
compile time. To me there isn't a terribly large reason to do this as it would
be pretty obvious why errors are occuring in Video Linux.cpp in a win32 build.
Still, the error is explicit a good thing at 3am.
I can't say that I have all the answers but my workspace already has 370 files
in it would be a lot uglier if I didn't rely on standards like this.
The zip file viewer built into the Developer Toolbox made use
of the zlib library, as well as the zlibdll source additions.