编写有点低级的 C++ 内容，您经常必须编写特定于操作系统的内容。让我们以一个MessageBox()函数为例（不是一个出色的例子，因为框架会这样做，但很容易理解）。
假设您有一个基App类，每个项目都提供一个自定义子类，例如MyApp. 对于每个操作系统，您可以有一个App::MessageBox()包含多个块的方法。#ifdef或者，您可以有一个基类/接口，每个操作系统的子类提供实现。例如AppWin32 : public App
一方面，后者对我来说似乎更整洁，但另一方面，这意味着您MyApp必须使用一些丑陋的代码来确保它是正确的操作系统特定基类的子类。
更好的方法是什么？
由于 file/socket/memory/database/... 函数在不同平台之间的差异比 GUI 函数要小，因此大多数代码都是为所有架构共享/编译的。我只是在这些函数/类中的平台特定代码周围使用#ifdef 块。
对于完全不同的 GUI（或任何其他复杂的子系统）代码，您应该在平台目录下使用不同的实现（不是头文件，可能是内部头文件）文件。(windows/window.cpp, xwin/window.cpp, macosx/window.cpp, ...)
看看这个方案的 GUI 工具包，wxwidgets 或 fltk 或其他大多数......
IMO，某些类太简单了，例如打开/关闭，#ifdef 对于这些情况还不错。我不认为为一个简单的功能提供一个抽象的平台层是一个好主意，它是过度设计的。
但是跨平台很复杂。如果要提供目标平台中不存在的特定平台功能，则应创建一个抽象平台层并为每个平台实现它，例如Windows中的剪贴板与X11中的X选择有很大不同，因此您必须维护不同的数据结构和算法使它们统一。
#ifdef 绝对是最糟糕的。
我会将特定于平台的代码放在单独的源树中（每个平台一棵树）。从项目位置（对于特定平台）可以使用 2 个文件系统链接 - 到“通用”树（例如，命名为“src”）和平台特定树（例如，命名为“特定”，实际上指向 linux、windows ，或其他特定于平台的源根目录）。这可以保证您始终选择正确版本的学员。此外，您甚至可以为针对不同平台设计的类似类赋予相同的名称。
当然，这种方法在具有 FAT 文件系统的 Windows 下是不可能的，但现在这种情况已经很少见了（因为在 Windows 下通常没有理由不使用 NTFS）。
如果将实现移动到多个 .cpp 文件，则只能使用一个 #ifdef 块。但是，如果需要，您也可以将其与第二种方法结合使用。不过，为了简单的使用，我猜多个定义文件会起作用。