Learn C++ - Cross-platform Development

#Introduction

Modern applications rarely live on a single platform. A service might run on Linux servers, desktop clients on Windows and macOS, all the way to mobile devices. C++ is very well suited for portability — its standard library is the same on all platforms — but there are still areas that differ: file systems, networking, and threading.

Episode 20 teaches you how to write C++ that runs on many platforms: portability principles, conditional compilation for platform-specific code, cross-compilation to target different architectures, and choosing vendor-neutral libraries and dependencies so you don't get locked into one ecosystem.

#Writing Portable Code

#Start with the Standard Library

The first step toward portability: use the standard library as much as possible. std::filesystem, std::thread, and std::string work identically on GCC, Clang, and MSVC. Differences appear when using operating system APIs like fork (Linux) or Winsock (Windows) — confine those APIs to a thin abstraction layer.

Implicit contracts also need attention: the size of int is generally 4 bytes, but long differs between Windows (4 bytes) and 64-bit Linux (8 bytes). For binary data, use the explicit types std::int32_t from <cstdint> so the size is certain on all platforms:

cat > portabel.cpp <<'EOF'
#include <cstdint>
#include <iostream>
 
int main() {
    std::int32_t nilai = 100000;
    std::int64_t besar = 5000000000LL;
    std::cout << sizeof(nilai) << " " << sizeof(besar) << "\n";
}
EOF
g++ -std=c++20 portabel.cpp -o portabel
./portabel

std::int32_t and std::int64_t guarantee the same byte size on every platform — crucial for the binary files and network protocols covered in episodes 9 and 13.

#Watch Out for Platform Differences

Small things that often trip you up: newlines in Windows text files are \r\n while Linux uses \n; paths use \ on Windows and / on Linux; and some threading functions behave slightly differently. Use std::filesystem::path to handle paths, and open text files in the appropriate mode when needed.

#Conditional Compilation

#The Preprocessor for Platform Differences

Compilers define platform macros: _WIN32 on Windows, __linux__ on Linux, __APPLE__ on macOS. Conditional compilation selects the right code during preprocessing:

cat > platform.cpp <<'EOF'
#include <iostream>
 
#ifdef _WIN32
const char* SO = "Windows";
#elif defined(__APPLE__)
const char* SO = "macOS";
#elif defined(__linux__)
const char* SO = "Linux";
#else
const char* SO = "Unknown";
#endif
 
int main() {
    std::cout << "Sistem operasi: " << SO << "\n";
}
EOF
g++ -std=c++20 platform.cpp -o platform
./platform

The block #ifdef _WIN32 is processed only on Windows, #elif defined(__APPLE__) only on macOS. The compiler rejects code in inactive branches — so errors in other platform code only appear when building on that platform. The CI build matrix from episode 19 catches these early.

#Abstraction in a Thin Layer

Conditional compilation spread across many #ifdefs makes code hard to read. Confine it to a single abstraction layer: a header that exports platform-neutral functions, backed by several implementation files that the build system selects. CMake picks the files according to the platform with if(WIN32) and if(UNIX) — cleaner than macros everywhere.

#Cross Compilation

#Building for Another Target

Cross compilation builds an executable for a platform or architecture different from the building machine — for example, building an ARM binary for a Raspberry Pi on an x86 machine. The key is the toolchain: compilers, libraries, and headers for the target. With CMake:

cat > toolchain-arm.cmake <<'EOF'
set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR arm)
set(CMAKE_C_COMPILER aarch64-linux-gnu-gcc)
set(CMAKE_CXX_COMPILER aarch64-linux-gnu-g++)
EOF
cmake -S . -B build-arm \
    -DCMAKE_TOOLCHAIN_FILE=toolchain-arm.cmake
cmake --build build-arm

set(CMAKE_CXX_COMPILER aarch64-linux-gnu-g++) uses an ARM compiler to produce ARM binaries, and CMAKE_TOOLCHAIN_FILE tells CMake the whole target setup. The resulting binary runs on ARM devices, not on the building machine.

#Cross Compilation Considerations

Cross compilation requires target libraries installed separately — x86 libraries can't be used for ARM builds. Use a sysroot, a directory containing the target system's files. Docker and containers help a lot here: run the build in an image with the target toolchain installed.

#Library Portability

#Vendor-neutral Dependencies

Choosing portable libraries determines how easily code moves between platforms. The standard library and header-only libraries like nlohmann/json are almost always portable. Libraries that depend on specific OS APIs need their platform support checked. Boost and asio broadly support Windows, Linux, and macOS.

Abstraction libraries hide platform differences behind a single API: fmt for formatting, spdlog for logging, and GoogleTest for testing. All are portable and vendor-neutral — they don't bind you to a specific compiler ecosystem:

set(CMAKE_CXX_STANDARD 20)
find_package(fmt CONFIG REQUIRED)
target_link_libraries(app PRIVATE fmt::fmt)

find_package(fmt CONFIG REQUIRED) looks for the installed fmt library, and target_link_libraries(app PRIVATE fmt::fmt) links it. Instead of writing your own, using portable libraries already tested on many platforms drastically reduces maintenance burden.

#Conclusion

Here's what to take away:

• The standard library is the foundation of C++ portability.
• <cstdint> types like std::int32_t guarantee fixed sizes on all platforms.
• _WIN32, __linux__, and __APPLE__ select code during preprocessing.
• Confine platform differences to an abstraction layer, not scattered #ifdefs.
• Cross compilation uses a toolchain file and sysroot for a different target.
• Choose portable, vendor-neutral libraries so you don't get locked into an ecosystem.

In the next episode, episode 21, we'll discuss embedded and high-performance systems — C++ for embedded and real-time applications, memory constraints and deterministic behavior with RTOS integration, embedded code profiling and low-level optimization, as well as deployment for firmware and hardware.