c – 在库的公共API中转换远离std :: string,std

对于具有相同二进制文件的许多工具链中的API / ABI兼容性,它是 well known that STL容器,std :: string和其他标准库类(如iostream)在公共头文件中是禁止的. (例外情况是,如果为每个受支持的工具链版本分配一个构建;一个为最终用户编译提供没有二进制文件的源,在本例中不是首选选项;或者一个转换为其他一些内联容器,以便不同的std实现不会被库提取.)

如果已经有一个已发布的库API没有遵循此规则(请求朋友),那么最好的路径是什么,同时保持尽可能多的向后兼容性,并且我不能支持编译时断点？我需要支持Windows和Linux.

重新考虑我正在寻找的ABI兼容性水平：我不需要它是疯狂的未来证明.我主要是为每个版本的多个流行的Linux发行版只做一个库二进制文件. (目前,我为每个编译器发布一个,有时为特殊发行版(RHEL vs Debian)发布特殊版本.与MSVC版本相同的问题 – 所有支持的MSVC版本的一个DLL将是理想的.)其次,如果我不’在破解修复版本中打破API,我希望它与ABI兼容,并且无需重建客户端应用程序即可替换掉DLL / SO.

我有三个案例,有一些初步的建议,模仿Qt到一定程度.

旧的公共API：

// Case 1: Non-virtual functions with containers
void Foo( const char* );
void Foo( const std::string& );

// Case 2: Virtual functions
class Bar
{
public:
    virtual ~Bar() = default;
    virtual void VirtFn( const std::string& );
};

// Case 3: Serialization
std::ostream& operator << ( std::ostream& os,const Bar& bar );

案例1：带容器的非虚函数

从理论上讲,我们可以将std :: string用法转换为非常类似于std :: string_view的类,但是在我们库的API / ABI控件下.它将在我们的库头中从std :: string转换,以便编译的库仍然接受但是独立于std :: string实现并且向后兼容：

新API：

class MyStringView
{
public:
    MyStringView( const std::string& ) // Implicit and inline
    {
        // Convert,possibly copying
    }

    MyStringView( const char* ); // Implicit
    // ...   
};

void Foo( MyStringView ); // Ok! Mostly backwards compatible

大多数客户端代码没有做出异常的事情,比如获取Foo的地址,无需修改即可运行.同样,我们可以创建自己的std :: vector替换,但在某些情况下可能会导致复制惩罚.

Abseil’s ToW #1建议从util代码开始,然后进行处理,而不是从API开始.还有其他任何提示或陷阱吗？

案例2：虚拟功能

但虚拟功能怎么样？如果我们更改签名,我们会破坏向后兼容性.我想我们可以让旧的一个到位,最后强制破坏：

// Introduce base class for functions that need to be final
class BarBase
{
public:
    virtual ~BarBase() = default;
    virtual void VirtFn( const std::string& ) = 0;
};

class Bar : public BarBase
{
public:
    void VirtFn( const std::string& str ) final
    {
        VirtFn( MyStringView( str ) );
    }

    // Add new overload,also virtual
    virtual void VirtFn( MyStringView );
};

现在,旧的虚函数的覆盖将在编译时中断,但是使用std :: string的调用将自动转换.覆盖应该使用新版本,并在编译时中断.

这里有任何提示或陷阱吗？

案例3：序列化

我不知道如何处理iostreams.一种选择,存在一些效率低下的风险,是将它们内联定义并通过字符串重新路由它们：

MyString ToString( const Bar& ); // I control this,Could be a virtual function in Bar if needed

// Here I publicly interact with a std object,so it must be inline in the header
inline std::ostream& operator << ( std::ostream& os,const Bar& bar )
{
    return os << ToString( bar );
}

如果我将ToString()作为一个虚函数,那么我可以迭代所有Bar对象并调用用户的覆盖,因为它只依赖于MyString对象,这些对象在头部定义,它们与std对象(如流)交互.

想法,陷阱？

解决方法

第1层

使用良好的字符串视图.

不要使用std :: string const&虚拟过载;没有理由.无论如何,你正打破ABI.一旦他们重新编译,他们将看到新的基于字符串视图的重载,除非他们正在获取并存储指向虚函数的指针.

要在不使用中间字符串的情况下进行流式传输,请使

void cps_to_string( Bar const& bar,MyFunctionView< void( MyStringView ) > cps );

其中cps被重复调用部分缓冲区,直到对象被序列化出来.写<<最重要的是(在标题中内联).函数指针间接有一些不可避免的开销. 现在只使用虚拟接口,永远不会重载虚方法,并始终在vtable的末尾添加新方法.因此,不要暴露复杂的heirarchies.扩展vtable是ABI安全的;加到中间不是. FunctionView是一个简单的手动非拥有std函数克隆,其状态为void *和R(*)(void *,args&& …),它们应该是ABI稳定的以跨越库边界.

template<class Sig>
struct FunctionView;

template<class R,class...Args>
struct FunctionView<R(Args...)> {
  FunctionView()=default;
  FunctionView(FunctionView const&)=default;
  FunctionView& operator=(FunctionView const&)=default;

  template<class F,std::enable_if_t<!std::is_same< std::decay_t<F>,FunctionView >{},bool> = true,std::enable_if_t<std::is_convertible< std::result_of_t<F&(Args&&...)>,R>,bool> = true
  >
  FunctionView( F&& f ):
    ptr( std::addressof(f) ),f( [](void* ptr,Args&&...args)->R {
      return (*static_cast< std::remove_reference_t<F>* >(ptr))(std::forward<Args>(args)...);
    } )
  {}
private:
  void* ptr = 0;
  R(*f)(void*,Args&&...args) = 0;
};
template<class...Args>
struct FunctionView<void(Args...)> {
  FunctionView()=default;
  FunctionView(FunctionView const&)=default;
  FunctionView& operator=(FunctionView const&)=default;

  template<class F,Args&&...args)->void {
      (*static_cast< std::remove_reference_t<F>* >(ptr))(std::forward<Args>(args)...);
    } )
  {}
private:
  void* ptr = 0;
  void(*f)(void*,Args&&...args) = 0;
};

这使您可以通过API障碍传递通用回调.

// f can be called more than once,be prepared:
void ToString_cps( Bar const& bar,FunctionView< void(MyStringView) > f );
inline std::ostream& operator<<( std::ostream& os,const Bar& bar )
{
  ToString_cps( bar,[&](MyStringView str) {
    return os << str;
  });
  return os;
}

并实施ostream& << MyStringView const&在标题中.

2级

将每个操作从头文件中的C API转发到extern“C”pure-C函数(即将StringView作为一对char const * ptrs传递).仅导出extern“C”符号集.现在,符号改变不再破坏ypur ABI.

C ABI比C更稳定,并且通过强制您将库调用分解为“C”调用,可以使ABI明显改变.使用C头胶使物品清洁,C使ABI坚固.

如果您愿意冒险,可以保留纯虚拟接口;使用与上面相同的规则(简单的heirarchies,没有重载,只添加到最后),你将获得体面的ABI稳定性.

c – 在库的公共API中转换远离std :: string,std :: ostream等

解决方法

相关文章