不要在公共接口中传递STL容器

最近的一个项目，是开发一个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是安全的，但这应该是有风险的：

除非能够确信你的DLL和DLL的使用者会使用完全相同的STL - 版本一致，编译选项一致，没有被自定义过等，不然就可能导致行为的不一致性：

举个例子，你在DLL中导出了vector，而这个DLL的客户使用的stl是自定义的版本，内存管理由其自己实现，那么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 namespacestdor namespaces within namespacestdunless otherwise specified”
  
  
  
  
• 自定义结构体封装容器并前置声明
  
  这个方案是这样的：
  
  //头文件
  
  structPublicClassData;
  
  classPublicClass
  
  {
  
  public:
  
  PublicClass();
  
  
  
  private:
  
  PublicClassData*m_pData;
  
  
  
  }
  
  
  
  //实现文件
  
  structPublicClassData
  
  {
  
  vector<int>_array;
  
  map<string,int>_map;
  
  };
  
  
  
  PublicClass::PublicClass()
  
  {
  
  m_pData=newPublicClassData;
  
  }
  
  当然，需要注意的是我们需要遵循：rule of three，提供析构，赋值与拷贝构造函数以管理内存。
  
  这个方案相对来讲比较简洁，应该说是现有方案的最有实践性的一个。

结论

所以，结论就是不要在DLL/SO的公共接口中使用STL容器，如果你确实需要，那么请用自定义结构体封装容器并前置声明的方式隔离STL容器！
原文链接: https://www.cnblogs.com/baiyanhuang/archive/2011/07/10/2102484.html

欢迎关注

微信关注下方公众号，第一时间获取干货硬货；公众号内回复【pdf】免费获取数百本计算机经典书籍