本章节将开始讨论如何开发跨平台的 C++ 插件。
跨平台开发
C/C++ 的跨平台开发相当复杂：数据类型不同，编译器不同，操作系统 API 也不同。跨平台开发关键是封装平台差异性，让你的应用程序仅关注于业务逻辑。如果应用程序使用了与平台相关的代码，我们就需要添加很多#ifdef OS_THIS或者#ifdef OS_THAT这样的宏。这是你必须注意的。解决跨平台问题的一个最佳实践是，将平台相关代码分隔到不同的库中去。这么做的好处是，如果你需要支持全新的平台，你只需修改这个平台的支持库即可。
了解目标平台
开发多平台系统，首先主要了解和注意平台之间的差异。如果你的目标平台分别是 32 位和 64 位系统，那么就应当明白其中的限制。如果你的目标平台是 Windows，你需要了解 ANSI/MBCS 和 Unicode/Wide 字符串的区别。如果你的目标平台是移植了操作系统的移动设备，你需要了解该系统的哪些子集可用。
选择良好的跨平台库
下一步，你需要选择一个良好的跨平台库。选择有很多优秀的库。大多数关注于 UI。这里，我们为我们的插件框架选择了 Apache Portable Runtime (APR)。APR 是 Apache 的 web 服务器，subversion 服务器以及其他项目的基础类库。
但是，或许 APR 并不适合你。尽管它有完善的文档，但是它的文档并不清晰；而且它不是一个著名的大型社区；也没有教程；只有相对较少的项目使用。另外，这是一个 C 库，你或许不喜欢它的命名风格。但是，它易于移植并且健壮（至少它是 Apache 和 Subversion 的一部分），并且可以用于实现高性能系统。
考虑编写一个包装类，实现自己的跨平台库（只封装需要的部分）。这么做有很多好处：
- 你可以修改接口以满足自己的需要
- 符合程序中其它代码的命名
- 方便修改到其它的库，或者是升级底层库的版本
当然，这种做法也有许多不足：
- 需要花费时间和资源编写、维护包装器
- 调试会有些困难，因为你需要浏览另外的底层（更不要说你的包装类也会有 bug）
这里，我们选择 APR，因为它是一个 C 库，需要你显式释放资源，为优化内存分配处理内存池，并且我也不喜欢名称变换。尽管只使用一个相对较小的子集（只使用目录和文件 API），但是依然值得我们花费时间去做这个工作，并且测试。我们可以在插件框架的子目录中找到 Path 和 Directory 类。注意，我们使用了基本类型的 APR 定义的 typedef，而没有自己定义。这只是因为我懒，并不值得推荐。你可以从结构以及接口中找到 APR 的类型信息。
数据类型的差异
C++ 类型继承自 C 是一个跨平台的潜在威胁。int、long 和 friend 在不同的平台上（现在的 32 位和 64 位系统，以及以后的 128 位系统）会有不同的大小。对于一些应用程序而言，这些都不是问题，因为它们不会涉及到 32 位的限制（如果是使用无符号整数，则是 31 位），但是如果你需要在 64 位系统序列化你的对象，又要在 32 位系统上反序列化，那么你就得注意这个问题了。并且，没有什么简单办法避免这个问题。你必须了解这个问题，才能在发送（保存）以及接收（加载）的时候提防每个值的字节数，以便做出正确的处理。文件格式或者网络协议都得注意这个问题。
APR 为在不同平台上可能会有不同的基本类型提供了一系列 typedef。这些 typedef 提供了恰当的大小，避免了类似的问题。然而，对于有些系统（大多数数值相关的应用），的确有必要使用原生的机器字长（典型的就是int的字长）来获得最大化的性能。
在跨平台包装类中包装平台相关的组件
有时，你必须编写一大堆平台相关的代码。例如，APR 所支持的动态库并不能满足插件框架的需要。我们简单地实现了DynamicLibrary 类，使用统一的接口抽象跨平台的动态库的概念。我们的实现时常会有使用体验或者性能的损失。你必须自己权衡，找出自己需要什么。在我们的例子中，DynamicLibrary 是一个最小接口，不允许应用程序给 Unix 上的 dlopen()指定任何标记位；在 Windows 平台上，也只是使用了LoadLibrary() 函数，而不是更加灵活的LoadLibraryEx()。
组织第三方依赖库
现在，我们经常使用第三方代码，而且也已经有很多优秀的第三方库可以使用。你的项目很可能要使用一些。在跨平台的环境中，选择合适的第三方库也是相当重要的。选择第三方库一般需要注意健壮性、性能、使用方便、文档支持良好等，还应当注意这个库的开发以及维护方式。有些库在一开始就没有注意跨平台的问题。很多时候，我们会看到有些库在一开始时为单一平台开发，后来才被移植到其他平台。如果基础代码并不统一，这就是一个红灯信号。如果在特定平台只有很少用户在使用，那么这也算一个红灯信号。如果核心开发者或维护者没有为所有平台提供安装包，也是一个红灯信号。如果新版本推出，但是某些平台有滞后，也是亮起红灯。“红灯”并不意味着你不能使用这个库，而是如果存在相同功能的没有红灯信号的库的时候，你应当优先选择那些库。
深刻理解构建系统
一个良好的自动构建系统对于开发严肃的软件系统是很重要的。如果你的程序支持多种版本（标准版、专业版、企业版），多个平台（Windows、Linux、OS X），多种编译选项（debug、release），你就得注意这个问题。构建系统必须足够自动化，并且支持整个构建生命周期——从源代码控制系统获取源代码、做预处理、编译、链接、运行单元测试、集成测试、发布，可能还会有完整的系统测试、用户反馈报告等。
由于构建系统多而杂，你必须对你自己的构建系统有深刻的理解。
平台服务
平台服务是由你的系统提供给插件的服务。之所以叫做“平台服务”，是因为一般的插件框架都会为基于插件的系统提供一个服务平台。PF_PlatformServices 结构包含了版本号、registerObject 和invokeService 函数指针。代码如下所示：
typedef apr_int32_t (*PF_RegisterFunc)(const apr_byte_t * nodeType,
const PF_RegisterParams * params);
typedef apr_int32_t (*PF_InvokeServiceFunc)(const apr_byte_t * serviceName,
void * serviceParams);
typedef struct PF_PlatformServices
{
PF_PluginAPI_Version version;
PF_RegisterFunc registerObject;
PF_InvokeServiceFunc invokeService;
} PF_PlatformServices; 版本号让插件知道PluginManager 的版本。这就允许插件能够根据版本不同而注册不同的对象。
registerObject() 函数是PluginManager 的一个服务，用于插件注册其对象（没有它也就没有插件系统）。
invokeService是应用程序提供的特定服务。应用程序和插件（插件对象创建之后）的交互由应用程序调用插件的对象模型接口（例如IActor::play()）完成。但是，插件有时也需要调用应用程序的服务，比如应用程序提供的对象日志执行环境的管理，错误报告以及程序级别的内存分配以便其它对象使用等。这些服务通常是单例，或者 static 函数。动态插件不能直接访问。不同于 registerObject 服务，应用程序相关的服务不能在PF_PlatformServices 结构中定义，因为它们不应该是通用插件框架所应该知道的，不同的应用程序提供的这类服务也不相同。应用程序可以将这些服务的访问点封装到一个很大的结构中，然后通过插件的对象模型的接口函数（initObject()）将其传递给各个插件。这种实现对于 C 插件有些不便。这些服务对象更适合使用 C++ 实现，将返回的 C++ 对象当做参数，也可以将其作为模板，也可以抛除异常。当然，我们也可以为每一个插件提供 C 兼容的包装器。但是，使用单一的类来处理插件的交互更为合适。
这就是invokeService()的作用。它的签名很简单——一个服务名的字符串和指向任意结构的 void 指针。这是一个弱类型的接口，但是足够灵活。插件和应用程序必须约定有哪些服务，需要怎样的参数。下面的代码展示了日志服务，其参数是文件名、行号和日志内容。
LogServiceParams.h
==================
typedef struct LogServiceParams
{
const apr_byte_t * filename;
apr_uint32_t line;
const apr_byte_t * message;
} LogServiceParams;
Some Application File...
========================
#include "LogServiceParams.h"
apr_int32_t InvokeService(const apr_byte_t * serviceName,
void * serviceParams)
{
if (::strcmp(serviceName, "log") == 0)
{
LogServiceParams * lsp = (LogServiceParams *)serviceParams;
Logger::log(lsp->filename, lsp->line, lsp->message);
}
} LogServiceParams 结构在插件和应用程序都需要 include 的头文件中定义。该结构提供了插件和应用程序之间的日志服务的协议。插件将当前文件名、行号和日志信息包装进一个结构，将其指针传递给 invokeService() 函数，“log” 作为服务名。应用程序端 invokeService() 函数的实现是，获取作为 void 指针传来的LogServiceParams结构，然后调用 Logger::log()函数。如果插件没有发送正确的LogServiceParams 结构，则其行为是未定义的（当然，这是很坏的结果）。invokeService() 可以用于处理多次请求，并且失败的话则返回 -1。如果应用程序需要返回给插件执行结果，则需要在服务的 params结构添加输出参数。每个服务都应当有自己的 params结构。
例如，如果应用程序需要控制内存分配（它提供了自定义的内存分配函数），就应当提供“allocate”和“deallocate”服务。当插件需要分配内存时，应当调用“allocate”服务，使用包含了请求分配内存空间的大小和用于输出的分配结果的void *指针的 AllocateServiceParams结构。
