在同一个项目中混合使用C++风格

在实践中,也许吧.

对于C++ 11和C++ 03的标准库来说,对std命名空间对象的布局存在不同意见是相对常见的.作为一个例子,sizeof(std::vector<int>)在MSVC土地上的各种编译器版本中明显改变.(随着它们的优化,它变小了)

其他示例可能是编译器栏两侧的不同堆.

因此,您必须在两个源树之间仔细"防火墙".

现在,一些编译器试图最小化这种二进制兼容性变化,即使以违反标准为代价.我相信std::list没有大小计数器可能就是一个例子(违反C++ 11,但我记得至少有一家供应商提供了一种不符合标准的std::list维护二进制兼容性 - 我不记得哪一个).

对于两个编译器(以及C++ 03和C++ 11中的编译器是不同的编译器),您将获得一些ABI保证.可能有很大一部分ABI会同意的语言,在那个集合中你是相对安全的.

为了相当安全,您需要将其他编译器版本文件视为不链接到同一C++标准库的第三方DLL(延迟加载库).这意味着从一个传递到另一个的任何资源必须与破坏代码一起打包(即,从它被破坏后返回到DLL).您要么必须调查两个标准库的ABI,要么避免在公共头文件中使用它,因此您可以在DLL之间传递智能指针等内容.

更安全的方法是将自己剥离到具有其他代码库的C样式接口,并且仅在两个代码库之间传递句柄(不透明类型).为了使这一点理智,将一些包含C风格接口的头文件只用于漂亮的C++代码,只是不要在代码库之间传递那些C++对象.

所有这一切都是痛苦的.

例如,假设您有一个std::string get_some_string(HANDLE)函数,并且您不信任ABI稳定性.

所以你有3层.

namespace internal {
  // NOT exported from DLL
  std::string get_some_string(HANDLE) { /* implementation in DLL */ }
}
namespace marshal {
  // exported from DLL
  // visible in external headers, not intended to be called directly
  void get_some_string(HANDLE h, void* pdata, void(*callback)( void*, char const* data, std::size_t length ) ) {
    // implementation in DLL
    auto r = ::internal::get_some_string(h);
    callback( pdata, r.data(), r.size() );
  }
}
namespace interface {
  // exists in only public header file, not within DLL
  inline std::string get_some_string(HANDLE h) {
    std::string r;
    ::marshal::get_some_string(h, &r,
      [](void* pr, const char* str, std::size_t length){
        std::string& r = *static_cast<std::string*>(pr);
        r.append( str, length );
      }
    );
    return r;
  }
}

所以DLL外面的代码做了一个auto s = ::interface::get_some_string(handle);,它看起来像一个C++接口.

DLL中的代码实现std::string ::internal::get_some_string(HANDLE);.

所述marshal的get_some_string提供了两个,其提供不是依赖于布局和执行更好二进制兼容性之间的C语言风格的界面std::string保持在DLL和使用DLL的代码之间的稳定.

所述interface的std::string存在完全内的非DLL的代码.在internal std::string存在完全内的DLL的代码.编组代码将数据从一侧移动到另一侧.