《CC：构建你自己的插件框架.docxVIP

C/C++：构建你自己的插件框架本文译自Gigi Sayfan在DDJ上的专栏文章。Gigi Sayfan是北加州的一个程序员，email：gigi@.本文是一系列讨论架构、开发和部署C/C++跨平台插件框架的文章的第一篇。第一部分探索了一下现状，调查了许多现有的插件/组件库，深入研究了二进制兼容问题，并展现了一些该方案必要的一些属性。后续的文章用一个例子展示了可用于Window、Linux、Mac OS X并易于移植到其他系统的，具有工业级强度的插件框架。与其他类似框架相比，该框架有一些独一无二的属性，并且被设计为灵活、高效、易于编程、易于创建新插件，且同时支持C和C++。同时还提供了多种部署选项（静态或动态库）。我将开发一个简单的角色扮演游戏，可以自己增加非玩家角色的插件。游戏的引擎加载插件并无逢地集成他们。游戏展示了这些概念并且展示能够实际运行的代码。谁需要插件？插件是你想开发一个成功的动态系统所需要的一种方式。基于插件的扩展性是当前扩展进化一个系统的最具有实践意义的安全方式。插件使得第三方开发人员可以为系统做增值工作，也可以使其他开发人员增加新的功能而不破坏现有的核心功能。插件能够促进将关注点分开，保证隐藏实现细节，将测试独立开来，并最具有实践意义。类似Eclipse的平台实际上就是一个所有功能都由插件提供的骨架。Eclipse IDE自身（包括UI和Java开发环境）仅仅是一系列挂在核心框架上的插件。?为什么选择C++众所周知，当用于插件时，C++不是一个容易适应新环境的东西。它非常依赖于编译器和平台。C++标准没有指定任何应用程序二进制接口，这说明由不同的编译器编译出的库甚至不同版本的库是不兼容的。加上C++没有动态加载的概念，且每个平台提供了自己的与其他平台不兼容的解决方案，你就能够了解。有少许重量级的解决方案试图说明不仅仅是插件和对一些额外的运行时的支持的依赖。但当要求高性能系统时，C/C++依然是仅有的实际可行的选项。?那里有什么？在着手一个全新的框架之前，检查现有的库或者框架是值得的。我发现既有重量级的解决方案，如M$的COM和Mozilla的XPCOM（Cross-platform COM），或者只提供相当基础功能的如QT的插件以及少许关于创建C++插件的文章。一个有趣的库，DynObj，声称能解决二进制兼容的问题（在相同的约束下）。也有一个由Daveed Vandervoorde提出，作为一个原生的概念给C++添加插件的提案。那是一个有趣的读物，但感觉怪怪的。?没有一个基础的解决方案阐述了与创建工业级强度的基于插件的系统相关的大量的问题，如错误处理，数据类型，版本控制，与框架代码以及应用代码的分离。在进入解决方案前，让我们理解这个问题。?二进制兼容问题再次强调，没有标准的C++ ABI。不同的编译器（甚至同一编译器的不同版本）产生不同的目标文件和库。最明显的表现是，不同编译器实现不同的name mangling（译注：这个术语我没有找到合适的翻译，意思是编译时给函数名字加上一些标识，功能之一就是区分重载函数）。这表明，通常情况下，你只能链接完全由同一个编译器（版本号也要相同）编译出来的目标文件。甚至有很多编译器没有完全实现C++98标准中的功能。?对于这个问题有一些局部的解决方案。例如，如果你访问一个C++对象时仅仅是通过虚拟指针（译注：不知道说的是什么意思，很费解，原文如下：if you access a C++ object only through a virtual pointer and call only its virtual methods you sidestep the name mangling issue）并只调用其虚函数九可以回避name mangling问题。然而，不能保证所有编译器编译出来的代码运行时在内存中有相同的VTABLE布局，尽管它更稳定（译注：应该指的是VTABLE在内存中的布局各编译器的实现更倾向于一致）。?如果你试图动态加载C++代码将面对另一个问题——没有直接的方法从Linux或者Mac OS X的动态库来加载并实例化C++的类（在Windows上，VC++支持）。?解决方案是使用一个具有C linkage的函数（因此编译器不会对其进行name mangling操作）作为一个工厂方法，来返回一个透明的handle给调用方。然后调用方将其转换成正确的类（通常是一个纯抽象基类）。当然，这需要一些协作，而且仅当应用和库所用编译器的VTABLE内存布局一致时才能工作。?解决兼容性的终极方法就是忘记C++，并使用纯C的API。在实际中，C对于所有的编译器实现都是兼容的。后面我会战士如何在C的兼容性基础上达成C++编程模型。?基于插件的系统的体系结构一个基于插件的系统可