预处理宏C跨平台的基石条件编译是C/C处理平台差异最古老也最直接的手段。它在预处理阶段就决定了哪些代码进入编译、哪些代码被丢弃因此运行时完全没有性能开销。条件编译的核心是预定义宏——编译器在预处理阶段自动定义的宏开发者无需手动#define即可使用。然而预定义宏体系并不统一。GCC定义__GNUC__Clang为了兼容GCC也定义__GNUC__但同时定义__clang__MSVC定义_MSC_VER。判断当前编译平台需要综合多个宏// 编译器检测#ifdefined(__clang__)// Clang 编译器Apple Clang 也在此列#elifdefined(__GNUC__)||defined(__GNUG__)// GCC 编译器#elifdefined(_MSC_VER)// MSVC 编译器#endif// 操作系统检测#ifdefined(_WIN32)||defined(_WIN64)// Windows32位或64位#elifdefined(__APPLE__)#includeTargetConditionals.h#ifTARGET_OS_IPHONE// iOS#elifTARGET_OS_MAC// macOS#endif#elifdefined(__linux__)// Linux#elifdefined(__FreeBSD__)// FreeBSD#endif// 架构检测#ifdefined(__x86_64__)||defined(_M_X64)// x86-64#elifdefined(__aarch64__)||defined(_M_ARM64)// ARM 64位#elifdefined(__arm__)||defined(_M_ARM)// ARM 32位#endif预定义宏的分类与可靠性编译器宏宏含义可靠性__clang__Clang/LLVM编译器Clang及AppleClang都定义__apple_build_version__Apple的Clang构建版本仅AppleClang定义用于区分LLVM官方Clang__GNUC__GCC主版本号GCC和Clang都定义Clang伪装为GCC 4.2__GNUG__同__GNUC__但仅C模式用于区分C/C_MSC_VERMSVC版本号仅MSVC定义也包含Intel C的MSVC模式__INTEL_COMPILERIntel C编译器仅Intel编译器__MINGW32__MinGW环境MinGW GCC定义__CYGWIN__Cygwin环境Cygwin GCC定义关键注意Clang伪装GCC。因为大量的跨平台代码和历史遗留代码用#ifdef __GNUC__来判断Unix风格编译器Clang为了不破坏这些代码假装自己是GCC。因此检测编译器时必须先检测Clang再检测GCC#ifdefined(__clang__)// Clang 特定代码#elifdefined(__GNUC__)// GCC 特定代码#elifdefined(_MSC_VER)// MSVC 特定代码#endif操作系统宏宏含义适用平台_WIN3232位和64位WindowsWindowsMSVC和MinGW都定义_WIN64仅64位Windows64位Windows__APPLE__Apple平台通用macOS, iOS, tvOS, watchOS__linux__Linux内核Linux__FreeBSD__FreeBSDFreeBSD__ANDROID__AndroidAndroid NDK__unix__Unix系统大多数Unix变体__MACH__Mach内核macOS对于macOS/iOS__APPLE__是最可靠的但它不能区分macOS和iOS。需要引入Apple的TargetConditionals.h#ifdef__APPLE__#includeTargetConditionals.h#ifTARGET_OS_MAC// macOS#elifTARGET_OS_IOS// iOS#endif#endif条件编译的两种组织方式方式一散点式不推荐初学者最容易写出这样的代码voidopen_file_dialog(){#ifdef_WIN32// 50行Windows API代码#elifdefined(__APPLE__)// 50行Cocoa代码#elifdefined(__linux__)// 50行GTK代码#endif}这会导致严重的可维护性问题同一个函数里混杂了多种平台的代码难以阅读、难以修改、难以测试。当一个平台需要修改时你必须阅读大量无关代码才能找到要改的部分。方式二平台抽象层推荐将平台差异收敛到少量文件platform/ ├── file_dialog.hpp // 统一接口 ├── file_dialog_win32.cpp // Windows 实现 ├── file_dialog_cocoa.mm // macOS 实现 ├── file_dialog_gtk.cpp // Linux 实现 └── CMakeLists.txt // 按平台选择编译// file_dialog.hpp — 平台无关的接口#pragmaonce#includestring#includevector#includeoptionalnamespaceplatform{std::optionalstd::stringopen_file_dialog(conststd::stringtitle,conststd::vectorstd::stringfilters);std::optionalstd::stringsave_file_dialog(conststd::stringtitle,conststd::stringdefault_name);}// namespace platform# CMakeLists.txt add_library(platform INTERFACE) target_include_directories(platform INTERFACE ${CMAKE_CURRENT_SOURCE_DIR}) if(WIN32) target_sources(platform INTERFACE file_dialog_win32.cpp) target_link_libraries(platform INTERFACE comdlg32) elseif(APPLE) target_sources(platform INTERFACE file_dialog_cocoa.mm) target_link_libraries(platform INTERFACE -framework Cocoa -framework UniformTypeIdentifiers ) else() target_sources(platform INTERFACE file_dialog_gtk.cpp) find_package(PkgConfig REQUIRED) pkg_check_modules(GTK3 REQUIRED gtk-3.0) target_link_libraries(platform INTERFACE ${GTK3_LIBRARIES}) target_include_directories(platform INTERFACE ${GTK3_INCLUDE_DIRS}) endif()业务代码只需#include platform/file_dialog.hpp完全不知道底层是哪个平台。PIMPL模式与编译隔离PIMPLPointer to IMPLementation指向实现的指针是C中经典的编译防火墙技术。它的核心思想是将类的所有私有成员包括平台相关的成员变量移到单独的实现类中公开类只持有一个指向实现类的指针。PIMPL在跨平台开发中的价值尤为突出公开头文件完全平台无关不需要包含任何平台头文件如windows.h从而避免了平台头文件对用户代码的污染。// window.hpp — 平台无关的公开头文件#pragmaonce#includememory#includestringclassWindow{public:Window(intwidth,intheight,conststd::stringtitle);~Window();voidshow();voidhide();voidresize(intwidth,intheight);private:classImpl;// 前向声明不暴露实现细节std::unique_ptrImplpimpl_;// 指向平台特定实现的指针};// window_win32.cpp — Windows 实现#includewindow.hppclassWindow::Impl{public:HWND hwnd_;HINSTANCE hinstance_;// ... 其他 Windows 特定成员staticLRESULT CALLBACKWndProc(HWND,UINT,WPARAM,LPARAM);};Window::Window(intw,inth,conststd::stringtitle):pimpl_(std::make_uniqueImpl()){// Windows 特定创建逻辑}// window_x11.cpp — Linux X11 实现#includewindow.hppclassWindow::Impl{public:Display*display_;Window xwindow_;// X11 的 Window 类型// ... 其他 X11 特定成员};Window::Window(intw,inth,conststd::stringtitle):pimpl_(std::make_uniqueImpl()){// X11 特定创建逻辑}使用PIMPL后window.hpp中不再出现HWND、Display*等平台类型。这不仅使头文件更干净也意味着包含window.hpp的用户代码不需要链接Windows SDK或X11库。PIMPL的代价是每次访问私有成员都需要一次间接寻址指针解引用以及额外的内存分配。对于大多数应用层代码这个开销可以忽略不计但对于每帧调用数千次的性能关键代码需要考虑其他方案如使用抽象接口而非PIMPL或将整条热点路径移到实现文件中。CMake中的平台检测CMake提供了内置变量和命令来在构建系统层面处理平台差异# 内置平台变量 if(WIN32) # Windows32位和64位 elseif(APPLE) # macOS elseif(UNIX AND NOT APPLE) # Linux 和其他 Unix endif() # 检查编译器 if(CMAKE_CXX_COMPILER_ID STREQUAL MSVC) # MSVC elseif(CMAKE_CXX_COMPILER_ID STREQUAL Clang) # Clang包括 AppleClang elseif(CMAKE_CXX_COMPILER_ID STREQUAL GNU) # GCC endif() # 检测平台特性 include(CheckCXXCompilerFlag) check_cxx_compiler_flag(-Wimplicit-fallthrough HAS_FALLTHROUGH_FLAG) if(HAS_FALLTHROUGH_FLAG) target_compile_options(myapp PRIVATE -Wimplicit-fallthrough) endif() # 检测头文件 include(CheckIncludeFileCXX) check_include_file_cxx(execution HAS_STD_EXECUTION)try_compile是更底层的机制CMake会尝试编译一小段测试代码根据编译结果设置变量。这对于检测非标准的编译器扩展或特定库函数的存在性非常有用。跨平台头文件包含不同平台的系统头文件路径不同、名称不同。写出既能在Windows又能在Linux上正确包含头文件的代码需要注意// POSIX头文件的跨平台包含#ifdef_WIN32#includewinsock2.h// Windows socket必须在windows.h之前#includewindows.h#includeio.h#defineaccess_access#else#includeunistd.h// POSIX: close, read, write, usleep...#includesys/socket.h// POSIX socket#includenetinet/in.h#includearpa/inet.h#endifwindows.h是一个极其污染性的头文件——它定义了大量的宏和类型可能与C标准库冲突例如min和max宏会破坏std::min和std::max。在包含windows.h之前定义WIN32_LEAN_AND_MEAN可以减少这种污染定义NOMINMAX可以阻止min/max宏的定义。实际建议经过多年跨平台实践我总结了以下原则集中而非分散将平台差异集中在少数文件/函数中不要让条件编译散落在项目的每个角落。先抽象后实现面向接口编程——先定义平台无关的接口.hpp然后为每个平台编写实现_win32.cpp、_linux.cpp等。CMake而非宏优先使用CMake来控制文件级别的平台选择target_sources条件添加减少代码内#ifdef的使用频率。PIMPL隔离头文件当平台类型会泄漏到头文件时考虑使用PIMPL模式彻底隔离。编译全部平台在CI中同时构建所有目标平台确保条件编译的每个分支都能通过编译。