c++ - 如何在 C++ 绑定(bind)中使用不透明指针包装 C 库

Question

我正在考虑用 C++ 包装一些 C 库，但我不确定包装不透明指针的最佳方法是什么。

当 C 语言结构是公共(public) API 的一部分时

typedef struct _SomeType
{
    int a;
    int b;
} SomeType_t;

有几个“成员”函数的地方:

void SomeTypeFoo( SomeType_t* obj, ... );
void SomeTypeBar( SomeType_t* obj, ... );

我喜欢从基派生的方法，将这些“成员”函数简单地关联为实际的类成员。即:

class SomeTypeWrapper:
    public SomeType_t
{
    void foo( ... );
    void bar( ... );
};

就我的理解而言，我相信 SomeTypeWrapper 与 struct _SomeType 是“二进制兼容的”，因此 SomeTypeWrapper* 可以被转换toSomeType_t* 这样 c++ 方法的实现可能是:

SomeTypeWrapper::foo( ... )
{
    SomeTypeFoo( (SomeType_t*)this, ... );
}

见注释[1]。

但是，在某些库中，他们喜欢将结构的定义保密(我想这是为了允许在不更改 header /API 的情况下更改实现)。所以在标题中我有这样的东西:

typedef struct _SomeType SomeType_t;

然后所有的“成员”函数都处理这些不透明的指针。为了将这些方法“包装”到一个接口(interface)中，到目前为止我所做的是提供一个包含指针的类。

class SomeTypeWrapper
{
    private:
        SomeType_t* m_data;

    public:
        SomeTypeWrapper( SomeType_t* data ): m_data(data){}
        void foo(...);
        void bar(...);
};

这意味着对于返回这种不透明指针的 c 库中的任何函数，我必须分配一个新对象来携带该指针。对于许多可能没问题但这种设计使包装器的实现变得复杂的库以及进行大量小对象分配的快速 c 库，我怀疑这种额外的对象开销会导致显着的性能损失。此外，底层对象可能被引用计数，因此在某些情况下我必须决定 SomeWrapperType 是否增加引用计数、实现复制构造函数、是否具有私有(private)构造函数等。

在大多数情况下，我很乐意为更好的界面付出代价，但我正在寻找其他选择。在 C++ 包装器库中是否有更简洁的方法来处理不透明的 c 指针？相关:是否有实现包装器类的好方法，以便 C++ header 不必包含 C 库 header 并且不需要分配包装器对象？

注意[1]:我相信只要使用相同的编译器并且 SomeTypeWrapper 不添加额外的成员并且没有虚拟方法，这个转换就是安全的。通过同一个编译器，我假设 gcc 编译的 c 库将与同一个 gcc 编译的 c++ 包装器一起工作。也许这不能保证？

Answer 1

SomeTypeWrapper 的最终版本(在问题中)是前进的方向。

This means that for any function in the c library which returns such an opaque pointer, I have to allocate a new object to carry that pointer around. For a lot of libraries that is probably fine but this design complicates implementing the wrapper and for speedy c-libraries that do a lot of small-object allocation, I suspect that this extra object over-head can lead to a significant performance penalty.

没有开销。具有一个数据成员且没有虚拟 方法的类 的实例不大于其唯一成员。如果您在 header 中定义内联方法，则也不会有函数调用开销。因此，只要您不使用 new 分配这些实例，而是在堆栈上:

SomeTypeWrapper some_object(make_some_object());  // one allocation on the heap

那么您就有了一个零开销的解决方案。