使用C++實(shí)現(xiàn)插件模式時(shí)要注意哪些問題

這篇“使用C++實(shí)現(xiàn)插件模式時(shí)要注意哪些問題”文章的知識(shí)點(diǎn)大部分人都不太理解，所以小編給大家總結(jié)了以下內(nèi)容，內(nèi)容詳細(xì)，步驟清晰，具有一定的借鑒價(jià)值，希望大家閱讀完這篇文章能有所收獲，下面我們一起來看看這篇“使用C++實(shí)現(xiàn)插件模式時(shí)要注意哪些問題”文章吧。

什么是插件模式和為什么要用插件模式

插件，Plug-In，或者（IE/Edge稱之為）加載項(xiàng)/Add-On，（Office稱之為）外接程序/Add-In，（GIMP稱之為）擴(kuò)展/Extension，等等，總之看字面意思都是“額外增加功能”的這種東西，是一類開發(fā)模式?；舅悸肪褪?，研發(fā)軟件本體的時(shí)候，外部需求不明確、直到使用期仍然經(jīng)常會(huì)增加功能細(xì)節(jié)。為了把變動(dòng)部分切割開，在設(shè)計(jì)的時(shí)候，通過對(duì)可變部分的歸納分析，對(duì)可變部分抽象出一套接口；每套外部需求用動(dòng)態(tài)庫(kù)之類的形式實(shí)現(xiàn)接口；軟件本體按某種約定，加載動(dòng)態(tài)庫(kù)，并從中獲取插件實(shí)例，通過接口來調(diào)用滿足當(dāng)時(shí)需求的功能實(shí)現(xiàn)。

可以看到，插件的思想，其實(shí)就是靈活運(yùn)用“動(dòng)態(tài)庫(kù)”的動(dòng)態(tài)加載能力，把對(duì)“接口”的實(shí)現(xiàn)移到軟件本體之外，并用工廠模式來約束動(dòng)態(tài)庫(kù)的實(shí)現(xiàn)方式。

只要是具有動(dòng)態(tài)加載能力的運(yùn)行環(huán)境上，都可以使用插件模式來設(shè)計(jì)軟件系統(tǒng)。極端一些的軟件系統(tǒng)，甚至只提供基礎(chǔ)平臺(tái)，所有功能都由插件的方式提供，例如 Visual Studio Code 、 Eclipse 等。

C++實(shí)現(xiàn)插件模式

用C++實(shí)現(xiàn)插件模式，一般是把下面這些功能組合起來：

• 用一個(gè)C++的帶虛函數(shù)的基類來表示功能

• 約定動(dòng)態(tài)庫(kù)里的工廠模式接口

• 在一些動(dòng)態(tài)庫(kù)里提供實(shí)現(xiàn)虛函數(shù)的派生類

• 在動(dòng)態(tài)庫(kù)里實(shí)現(xiàn)工廠模式

不幸的是，由于各操作系統(tǒng)的動(dòng)態(tài)庫(kù)機(jī)制普遍是C風(fēng)格的，用C++做動(dòng)態(tài)庫(kù)時(shí)候的坑，在用C++實(shí)現(xiàn)插件模式時(shí)，全都會(huì)遇到。比如：

• C++的編譯器差異導(dǎo)致的不互通
  會(huì)導(dǎo)致必須用同一種（或兼容的）編譯器來生成插件和軟件本體。

• 名字改寫（Name Mangling）：參考：Wikipedia、C/C++中的名字空間與作用域示例詳解 會(huì)導(dǎo)致加載插件時(shí)“找不到符號(hào)”

• 虛函數(shù)（表）實(shí)現(xiàn)：
  會(huì)導(dǎo)致加載插件時(shí)可能不報(bào)錯(cuò)，但運(yùn)行時(shí)候找不到正確的虛函數(shù)入口

• 操作系統(tǒng)機(jī)制導(dǎo)致的不互通

• Windows上使用MSVCRT時(shí)的內(nèi)存分配和回收
  Windows每個(gè)模塊的內(nèi)存分配默認(rèn)是在模塊自己的堆里的，而Windows上的C運(yùn)行時(shí)庫(kù)（各種MSVCRT）為了封裝出 malloc 、 free 等C函數(shù)的效果，建立了__crtheap（2010及之前版本行為）或直接使用進(jìn)程默認(rèn)堆（2015及之后版本行為）[1]。這導(dǎo)致，即使是同一個(gè)編譯器，靜態(tài)鏈接VC運(yùn)行時(shí)會(huì)采用本模塊內(nèi)部的堆來實(shí)現(xiàn) malloc 等，而動(dòng)態(tài)鏈接VC運(yùn)行時(shí)則會(huì)采用MSVCRT動(dòng)態(tài)庫(kù)DLL的模塊堆。需要解決好“誰申請(qǐng)誰釋放”的問題，否則內(nèi)存管理的地方容易出異常。

• 全局變量在模塊間的共享問題

一些典型的不良實(shí)現(xiàn)

這里說的不良實(shí)現(xiàn)，使用時(shí)候未必會(huì)錯(cuò)或崩，但早晚要崩，或者會(huì)限制住插件的開發(fā)。以下用如下插件接口作為例子。

// IFilter.h
 
/// 濾波器接口.
class IFilter {
protected:
    IFilter();
public:
    virtual ~IFilter();
public:
    /// 一個(gè)將輸入復(fù)數(shù)數(shù)組處理為輸出復(fù)數(shù)數(shù)組的函數(shù).
    virtual void Filter(const std::complex<double>* acdIn, std::complex<double>* acdOut, size_t uLen) = 0;
    /// 獲取當(dāng)前實(shí)現(xiàn)的一些描述字符串.
    virtual std::string GetDescription() const = 0;
};
// IFilter.cpp
IFilter::IFilter() { }
IFilter::~IFilter() { }

并約定插件實(shí)現(xiàn)中以如下形式提供工廠函數(shù)。

// FilterPluginDll.h
#include "IFilter.h"
/* 插件DLL應(yīng)該提供如下函數(shù) 
extern "C" int GetFilterPluginInDll(char* szFilterNamesBuf, size_t uBufLen);
extern "C" IFilter* BuildFilterPlugin(const char* szFilterName);
extern "C" void FreeFilterPlugin(IFilter* pFilter);
*/
typedef int (*PFNGetFilterPluginInDll)(char* szFilterNamesBuf, size_t uBufLen);
typedef IFilter* (*PFNBuildFilterPlugin)(const char* szFilterName);
typedef void (*PFNFreeFilterPlugin)(IFilter* pFilter);

接口類沒有提供二進(jìn)制實(shí)現(xiàn)

比如，對(duì)插件只發(fā)布兩個(gè)頭文件；認(rèn)為 IFilter 的構(gòu)造和析構(gòu)反正是空函數(shù)無所謂，直接寫在類定義里。

這樣，插件開發(fā)者自己生成插件DLL時(shí)，會(huì)在自己的DLL里鏈接進(jìn)一份 IFilter::IFilter() 和 IFilter::~IFilter() 的實(shí)現(xiàn)，而軟件本體里也有一份自己的實(shí)現(xiàn)。雖然看上去，如果編譯器一樣，兩份實(shí)現(xiàn)是等同的，但考慮到它們使用了不同的模塊堆，以及其它各種原因，插件DLL中的 IFilter 和軟件本體里的 IFilter 并不是完全等同的。

這里應(yīng)該由軟件本體導(dǎo)出 IFilter::IFitler() 和 IFilter::~IFilter() 等接口類的共性成分的實(shí)現(xiàn)給插件，以免出現(xiàn)一些奇怪的問題。

工廠函數(shù)里沒有正確設(shè)計(jì)“誰分配誰釋放”

比如，為了“簡(jiǎn)單”，只要求了 BuildFilterPlugin 工廠函數(shù)，認(rèn)為可以由軟件本體用 delete pFilter; 來釋放插件實(shí)例。

一種建議的實(shí)現(xiàn)方法

用類似于Windows的COM風(fēng)格的“放了一堆函數(shù)指針的結(jié)構(gòu)體”來表示插件的接口定義；軟件本體里為了使用方便，再用接口類包裝一下。

以上就是關(guān)于“使用C++實(shí)現(xiàn)插件模式時(shí)要注意哪些問題”這篇文章的內(nèi)容，相信大家都有了一定的了解，希望小編分享的內(nèi)容對(duì)大家有幫助，若想了解更多相關(guān)的知識(shí)內(nèi)容，請(qǐng)關(guān)注億速云行業(yè)資訊頻道。