See what's going on with flipcode!




This section of the archives stores flipcode's complete Developer Toolbox collection, featuring a variety of mini-articles and source code contributions from our readers.

 

  Coding Layout For Platform Independence
  Submitted by



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 handles.

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:

(Win32 Example)

#ifndef _WIN32
#       error Incorrectly included file. This file should only be included in
Win32 projects.
#endif 

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.

 

Copyright 1999-2008 (C) FLIPCODE.COM and/or the original content author(s). All rights reserved.
Please read our Terms, Conditions, and Privacy information.