Best (cleanest) way for writing platform specific code

Question

Say you have a piece of code that must be different depending on the operating system your program is running on.
There's the old school way of doing it:

#ifdef WIN32
   // code for Windows systems
#else
   // code for other systems
#endif

But there must be cleaner solutions that this one, right?

Answer 1

The typical approach I've seen first hand at a half-dozen companies over my career is the use of a Hardware Abstraction Layer (HAL).

The idea is that you put the lowest level stuff into a dedicated header plus statically linked library, which includes things like:

• Fixed width integers (int64_t on Linux, __int64 on Windows, etc).
• Common library functions (strtok_r() vs strtok_s() on Linux vs Windows).
• A common data type setup (ie: typedefs for all data types, such as xInt, xFloat etc, used throughout the code so that if the underlying type changes for a platform, or a new platform is suddenly supported, no need to re-write and re-test code that depends on it, which can be extremely expensive in terms of labor).

The HAL itself is usually riddled with preprocessor directives like in your example, and that's just the reality of the matter. If you wrap it with run-time if/else statements, you comilation will fail due to unresolved symbols. Or worse, you could have extra symbols included which will increase the size of your output, and likely slow down your program if that code is executed frequently.

So long as the HAL has been well-written, the header and library for the HAL give you a common interface and set of data types to use in the rest of your code with minimal hassle.

The most beautiful aspect of this, from a professional standpoint, is that all of your other code doesn't have to ever concern itself with architecture or operating system specifics. You'll have the same code-flow on various systems, which will by extension, allow you to test the same code in a variety of different manners, and find bugs you wouldn't normally expect or test for. From a company's perspective, this saves a ton of money in terms of labor, and not losing clients due to them being angry with bugs in production software.