我正在开发一个应用程序的平台抽象库，但是很难想出一种将平台无关代码与平台相关代码分离的简洁方法。
我认为有两种基本方法可行：带平台特定委托的平台无关类，或者具有平台特定派生类的平台无关类。这两种方法各有优缺点吗？在任何情况下，什么是最佳机制来建立委托/继承关系，以便于平台无关类的用户透明地进行操作？
如果您能提供一个简洁的架构方案，甚至只提供过去人们所采用方法和相应方法的优缺点的例子，我会非常感激。
编辑：针对那些建议使用Qt及类似框架的人，是的，我故意要“重造轮子”，因为我不仅关注于开发应用程序，而且也对开发自己的平台抽象库的理论挑战感兴趣。感谢建议！
*.win32.cpp、*.posix.cpp等。只有在相关平台上编译平台特定的源文件。#ifdef MyPlatform，使平台特定的代码易于识别，在平台特定的源文件中允许使用编译器特定的功能，通过不包含平台头文件来避免全局命名空间的污染。class Foo {
public:
void write(const char* str);
void close();
};
Foo的模块，显然都有#include "Foo.h"，但在特定于平台的makefile中，你可能会有-IWin32，这意味着编译器会查找.\Win32并找到一个Windows特定的Foo.h，其中包含该类，具有相同的接口，但可能具有Windows特定的私有成员等。Foo的文件，而只有一组特定于平台的文件，只有在由特定于平台的makefile选择时才会使用。看看ACE。它使用模板和继承有相当不错的抽象。
我可能会去做一些政策方面的事情：
template<typename Platform>
struct PlatDetails : private Platform {
std::string getDetails() const {
return std::string("MyAbstraction v1.0; ") + getName();
}
};
// For any serious compatibility functions, these would
// of course have to be in different headers, and the implementations
// would call some platform-specific functions to get precise
// version numbers. Using PImpl would be a smart idea for these
// classes if they need any platform-specific members, since as
// Joe Gauterin says, you want to avoid your application code indirectly
// including POSIX or Windows system headers, containing useless definitions.
struct Windows {
std::string getName() const { return "Windows"; }
};
struct Linux {
std::string getName() const { return "Linux"; }
};
#ifdef WIN32
typedef PlatDetails<Windows> PlatformDetails;
#else
typedef PlatDetails<Linux> PlatformDetails;
#endif
int main() {
std::cout << PlatformDetails().getName() << "\n";
}
在这种情况下，使用CRTP进行常规的模拟动态绑定与此相比并没有太大区别。因此，通用的东西是基类，而具体的东西则是派生类：
template<typename Platform>
struct PlatDetails {
std::string getDetails() const {
return std::string("MyAbstraction v1.0; ") +
static_cast<Platform*>(this)->getName();
}
};
struct Windows : PlatDetails<Windows> {
std::string getName() const { return "Windows"; }
};
struct Linux : PlatDetails<Linux> {
std::string getName() const { return "Linux"; }
};
#ifdef WIN32
typedef Windows PlatformDetails;
#else
typedef Linux PlatformDetails;
#endif
int main() {
std::cout << PlatformDetails().getName() << "\n";
}
// Or just set the include path with -I or whatever
#ifdef WIN32
#include "windows/platform.h"
#else
#include "linux/platform.h"
#endif
struct PlatformDetails {
std::string getDetails() const {
return std::string("MyAbstraction v1.0; ") +
porting::getName();
}
};
// windows/platform.h
namespace porting {
std::string getName() { return "Windows"; }
}
// linux/platform.h
namespace porting {
std::string getName() { return "Linux"; }
}
您可能还想看看poco：
POCO C++库（POCO代表可移植组件）是开源的C++类库，简化和加速了基于网络的便携式应用程序在C++中的开发。这些库与C++标准库完美集成，并填补了许多功能空缺。它们的模块化和高效的设计和实现使得POCO C++库非常适合嵌入式开发，这是C++编程语言因其适用于低级别（设备I/O、中断处理程序等）和高级面向对象开发而变得越来越受欢迎的领域。当然，POCO C++库也准备好迎接企业级挑战。
(来源：pocoproject.org)
所以...你不想简单地使用Qt吗？对于真正使用C++进行工作，我非常强烈推荐它。它是一个绝对优秀的跨平台工具包。我刚刚写了一些插件让它在Kindle和Palm Pre上运行。Qt使一切变得容易和有趣。甚至可以说是令人振奋的。好吧，直到你第一次遇到QModelIndex，但他们据说已经意识到过度设计了它并且正在替换它;)
然而，作为学术练习，这是一个有趣的问题。作为一个重复发明轮子的人，我自己也做过几次。:)
简短的答案：我会选择PIMPL。（Qt源代码有很多例子）
我过去使用过基类和特定于平台的派生类，但通常结果比我想象中更混乱。我还使用了一些函数指针来实现平台特定的部分，但我对此感到更不满意。
两次我都有一种非常强烈的感觉，即我正在过度设计并且迷失了方向。
我发现使用不同文件中的私有实现类（PIMPL）来处理不同平台特定位最容易编写和调试。但是......如果只有几行代码并且非常清楚正在发生什么，那么不要过于害怕使用#ifdef。我讨厌杂乱或嵌套的#ifdef逻辑，但是偶尔使用一两个可以真正帮助避免代码重复。
使用PIMPL时，您不需要在发现需要在平台之间使用不同实现的新位时不断重构设计。这样可能会导致问题。
在实现级别上，从应用程序中隐藏......也没有什么错处使用一些平台特定的派生类。如果两个平台实现相当明确并且几乎没有共享数据成员，则它们是一个很好的候选对象。只需在意识到这一点后再进行操作，而不是出于某种想法而提前选择所有内容都需要符合您选择的模式。
如果有什么的话，我对今天编码的最大抱怨就是人们似乎很容易迷失在理想主义中。PIMPL是一种模式，具有平台特定的派生类是另一种模式。使用函数指针是一种模式。没有什么可以说它们是互斥的。
然而，作为一般准则......从PIMPL开始。
