C++: Platform dependent types - best pattern [closed]

You should use a configuration script able to perform platform checks and generate the appropriate compiler flags and/or configuration header files.

There are several tools able to perform this task, like autotools, Scons, or Cmake.

In your case, I would recommend using CMake, as it nicely integrates with Windows, being able to generate Visual Studio project files, as well as Mingw makefiles.

The main philosophy behind these tools is that you do not test again the OS itself, but against features that might or might not be present, or for which values can vary, reducing the risk that your code fails to compile with a "platform non supported" error.

Here is a commented CMake sample (CMakeFiles.txt):

# platform testsinclude(CheckFunctionExists)include(CheckIncludeFile)include(CheckTypeSize)include(TestBigEndian)check_include_file(sys/types.h  HAVE_SYS_TYPES_H)check_include_file(stdint.h     HAVE_STDINT_H)check_include_file(stddef.h     HAVE_STDDEF_H)check_include_file(inttypes.h   HAVE_INTTYPES_H)check_type_size("double"      SIZEOF_DOUBLE)check_type_size("float"       SIZEOF_FLOAT)check_type_size("long double" SIZEOF_LONG_DOUBLE)test_big_endian(IS_BIGENDIAN)if(IS_BIGENDIAN)  set(WORDS_BIGENDIAN 1)endif(IS_BIGENDIAN)# configuration fileconfigure_file(config-cmake.h.in ${CMAKE_BINARY_DIR}/config.h)include_directories(${CMAKE_BINARY_DIR})add_definitions(-DHAVE_CONFIG_H)

With that, you have to provide a config-cmake.h.in template that will be processed by cmake to generate a config.h file containing the definitions you need:

/* Define to 1 if you have the <sys/types.h> header file. */#cmakedefine HAVE_SYS_TYPES_H/* Define to 1 if you have the <stdint.h> header file. */#cmakedefine HAVE_STDINT_H/* Define to 1 if your processor stores words with the most significant byte   first (like Motorola and SPARC, unlike Intel and VAX). */#cmakedefine WORDS_BIGENDIAN/* The size of `double', as computed by sizeof. */#define SIZEOF_DOUBLE @SIZEOF_DOUBLE@/* The size of `float', as computed by sizeof. */#define SIZEOF_FLOAT @SIZEOF_FLOAT@/* The size of `long double', as computed by sizeof. */#define SIZEOF_LONG_DOUBLE @SIZEOF_LONG_DOUBLE@

I invite you to go to the cmake website to learn more about this tool.

I'm personally a fan of cmake, which I'm using for my personal projects.

One way to do this is put the OS specific headers into different directories and control which directory is found by passing that directory to the compiler via the -I flag.

In you case you just would have

#include "defs.h"

There is nothing inherently "bad" about using the preprocessor. It was created for a reason, and conditional compilation/inclusion like this is one of the things that does rather well.

The key is to keep your code readable. If you end up having a lot of #ifdef WIN32 blocks in your code, or if you find yourself doing this in a large number of files, here are a few tips to clean up your code a bit.

1) Move your conditional inclusion into a separate file. Your source files will simply #include <defs.h>, and move your conditional inclusion block into defs.h (even if that's all that is in that file).

2) Let your makefile determine which file to include. Again, your source files will simply #include <defs.h>. Your makefile will detect the current platform and add -iwin32 or -ilinux to the compiler options string as appropriate. This is the approach that I typically take. You can do the platform detection work inside the makefile or during the configuration stage (if you are dynamically-generating your makefiles). I also find this option easiest in terms of adding support for a new platform at a later date; it seems to minimize the number of changes that need to be made.

3) If you are building on a Linux system (implying that any Win32 code will be generated by a cross-compiler), you can have your build scripts create a symbolic link to the appropriate header file directory. Your code can reference the directory as #include <platform\defs.h> and let the makefile or configure script worry about symlinking the correct folder.