最近的一个项目,是开发一个framework,提供给公司内部不同的产品线使用。 之间遇到的一个问题,就是STL容器的使用, 而结论是不要在公共接口中传递STL容器:

这里说的STL容器,但主要则是指容器,字符串类,但其实可以推广到在STL中提供的任何类型,
这里说的公共接口,是指需要暴露给客户的sdk头文件,包括函数签名,或者类成员变量;
也可以说,不要在暴露给客户的头文件中包含STL的头文件。

原因分析
为什么有这个结论,我们可以从几个方面来论述:

客户端使用的STL版本可能不同
因为STL作为标准库,Framework编译的时候使用的STL,与客户端编译的时候使用的STL,版本是有可能不一样的,比如Framework使用VC8编译发布,而客户代码使用VC10编译使用,那么Framework所理解的STL容器,与客户端代码所理解的STL容器,在内存布局上,数据表示上是有可能不一样的,出错也就不可避免了。

编译选项
即使Framework和客户端使用的是同一个版本的STL,但是如果编译选项不一样,也可能导致其不一致性,自然也会出错。

静态变量
即使版本一致,编译选项一致,仍然是不安全的,因为STL容器的实现中,有可能使用了静态变量,而在Framework模块和客户端模块中,虽然由于模板扩展产生的两份代码总体上是一致的,但都各自维护了一份静态变量,从而造成了内部状态的不一致性。
客户端的STL被自定义
但从文件的角度来看,在客户端包含的STL头文件实现,可以是完全不同于标准的 - 只要其接口和标准保持一致。 比如客户那边使用的STL在内存管理方面有特殊需求,改写了默认的allocator,那么内存必然会出问题;比如客户在实现中加入了其他成员变量,那么内存布局必然也不一致。
虽然,微软这篇文章提到导出vector是安全的,但是根据上面的分析,这应该是不安全的做法。

可选方案
但事实上,你还是可能存在这种需求的 - 你需要容器类的函数参数或者返回值,你可能也需要容器类的类成员变量,那么如何解决?

对于前者,我们可以针对具体的类型封装一个具体的容器类,内部还是可以使用STL container的;
对于后者,我们可以用一些办法,防止STL容器出现在头文件中;

解决的方法,可以有以下几种:

提供自己的容器类
这是最彻底,最直接的方法,但是提供一套与STL相当的模板容器类需要蛮大的工作量,而且明显是重复制造轮子了。 要注意,这里简单的对STL容器进行封装是行不通,因为模板不支持分离编译,这么做还是会把STL容器带入公共接口。
PImpl
PImpl模式当然很强大,当然可以解决这个问题,但是此处如果仅仅是为了隐藏容器类,难免杀鸡用牛刀,还引入了不必要的间接层与繁琐的脚手架代码。
使用void*作为数据成员,而后强制转换为容器类
不安全也太丑陋,用起来也繁琐,每次都要cast以下,除非别无他法,是在不应该考虑这个方案。
前置声明STL容器
这个方法在VC9中是可以工作的,但是根据C++标准: 17.4.3.1 Reserved names,这种做法是未定义的:
“ It is undefined for a C++ program to add declarations or definitions to namespace std or namespaces within namespace std unless otherwise specified”

 

自定义结构体封装容器并前置声明
这个方案是这样的:

//头文件

struct PublicClassData;

class PublicClass{

public:   

PublicClass();

private:   

PublicClassData* m_pData;

}

 

//实现文件

struct PublicClassData

{   

vector<int> _array;   

 map<string, int> _map;

};

PublicClass::PublicClass()

{   

m_pData = new PublicClassData;

}

当然,需要注意的是我们需要遵循:rule of three,提供析构,赋值与拷贝构造函数以管理内存。
这个方案相对来讲比较简洁,应该说是现有方案的最有实践性的一个。
结论
所以,结论就是不要在DLL/SO的公共接口中使用STL容器,如果你确实需要,那么请用自定义结构体封装容器并前置声明的方式隔离STL容器!