插件系统组件 本章节主要描述通用插件框架的主组件及其作用。 DynamicLibrary DynamicLibrary组件是一个简单的跨平台 C++ 类。它使用 dlopen/dlclose/dlsym 系统调用（UNIX 以及 OS X）和 LoadLibrary/FreeLibrary/GetProcAddress API 调用（Windows）。
主题 Salodad 由 PenciDesign 提供 | 静态文件存储由又拍云存储提供 | 苏ICP备13027999号-2
注册对象 现在，球已经在插件手上了（在PF_initPlugin中）。如果版本正确，插件管理器应当已经注册了所有支持的对象类型。注册的目的是提供类似PF_CreateFunc和PF_DestroyFunc这样的函数，以便以后用于创建和销毁插件对象。这种安排允许插件自己控制所管理对象的实际创建和销毁操作，包括资源管理等（如内存），而由应用程序控制所有的对象及其生命周期。当然，插件也可能使用单例模式， ...
在前面的文章中，我们讨论了问题的细节、多种解决方案，最后大体引入了插件框架。下面，我们将继续架构的描述、插件生命周期的管理以及插件框架的具体实现细节。注意，我们的代码可能仅仅是接口层次的，不会涉及更深入的实现。 基于插件系统的架构 基于插件的系统可以分成三个部分，这三个部分都是松散耦合的：使用其对象模型的主系统或主应用程序，插件管理器和插件。插件需要符合插件管理器的接口和协议，并且需要实现对象模型 ...
编程语言的支持 在前面的章节中，我们已经了解到，如果你能够使用编译器令应用程序和插件的虚表匹配，那么就可以保持 C++ 虚表级别的兼容性；或者你可以使用 C 级别的兼容性，然后就能使用不用的编译器去构建系统，但其限制在于你只能编写纯 C 应用。这样的话，你就不能够使用前面我们在例子 IActor 中看到的那种优雅的 C++ 接口。
插件编程接口 所谓插件，其实就是基于接口的设计。基于插件的系统最基本的一点就是，要有一个中心系统，用于加载未知的插件，并且能够使用预先定义好的接口和协议与这些插件进行交互。 最基本的方式是定义一个接口，提供一系列插件（动态的或者是静态）需要暴露出的函数。这种实现从技术上说是可行的，但实际并不那么简单地操作。原因在于，一个插件需要支持两类接口，但是却只能暴露出一个接口的函数集。这意味着，两类接口必须 ...
本系列文章来自 Building Your Own Plugin Framework，主要内容是讨论使用 C/C++ 语言开发跨平台的插件框架所需要的架构、开发方法以及部署。我们将从分析现有插件/组件系统开始，一步步深入了解如何开发插件框架，以及很多需要注意的问题，比如二进制兼容性等，在文章的最后，我们将给出一个比较合理的解决方案。 在本系列文章中，我们将开发一套具有工业强度的插件框架，可以运行在 ...
Core::BaseFileWizard 类Core::BaseFileWizard在 coreplugin/basefilewizard.h 文件中声明：
Item Model 类向导 假设我们希望提供一个新的类向导，来帮助我们自动生成一个数据项模型的文件。这个文件将基于如下几个数据： 模型类名称； 父类名称（可以是QAbstractItemModel、QAbstractListModel或者QAbstractTableModel中的一个）； 头文件名； 源代码文件名。
预定义的IWizard实现：Core::BaseFileWizard Qt Creator 已经提供了一个默认的IWizard接口的实现，也就是Core::BaseFileWizard类。这个类提供了IWizard接口的所有函数的默认实现，并且增加了自己特有的虚函数。为了利用这个类，我们需要继承它，并且重写其中的一个或多个函数。
Qt Creator 中，新的工程类型将出现在“文件 -> 新建”菜单项中；我们可以通过打开的选择工程类型的对话框来找到所需要的工程： 在本章中，我们将学习如何向上面所示的对话框中添加新的工程类型。