是否可以在 C++ 中子类化 C 结构体 并在 C 代码中使用指向结构的指针？

Question

这样做是否有副作用：

C 代码：

struct foo {
      int k;
};

int ret_foo(const struct foo* f){ 
    return f.k; 
}

C++ 代码：

class bar : public foo {

   int my_bar() { 
       return ret_foo( (foo)this ); 
   }

};

C++ 代码周围有一个 extern "C" ，每个代码都在自己的编译单元内。

这可以跨编译器移植吗？

Answer 1

这是完全合法的。 在 C++ 中，类和结构是相同的概念，但所有结构成员默认都是公共的。 这是唯一的区别。 因此，询问是否可以扩展结构与询问是否可以扩展类没有什么不同。

这里有一个警告。 无法保证编译器之间的布局一致性。 因此，如果您使用与 C++ 代码不同的编译器来编译 C 代码，则可能会遇到与成员布局（尤其是填充）相关的问题。 当使用同一供应商的 C 和 C++ 编译器时甚至可能会发生这种情况。

我在 gcc 和 g++ 中遇到过这种情况。 我从事的项目使用了几个大型结构。 不幸的是，g++ 的结构打包比 gcc 松散得多，这导致在 C 和 C++ 代码之间共享对象时出现严重问题。 我们最终不得不手动设置打包和插入填充，以使 C 和 C++ 代码以相同的方式对待结构。 但请注意，无论子类化如何，都可能会发生此问题。 事实上，在本例中我们并没有对 C 结构体进行子类化。

Answer 2

这是完全合法的，尽管它可能会让其他程序员感到困惑。

您可以使用继承来通过方法和构造函数扩展 C 结构。

示例：

struct POINT { int x, y; }
class CPoint : POINT
{
public:
    CPoint( int x_, int y_ ) { x = x_; y = y_; }

    const CPoint& operator+=( const POINT& op2 )
    { x += op2.x; y += op2.y; return *this; }

    // etc.
};

扩展结构可能“更”邪恶，但这并不是禁止你做的事情。

Answer 3

“永远不要从具体的类派生。” — 萨特

“使非叶类抽象。” — 迈耶斯

对非接口类进行子类化是完全错误的。 你应该重构你的库。

从技术上讲，您可以做您想做的事情，只要您不调用未定义的行为，例如，通过指向其基类子对象的指针删除指向派生类的指针。 对于 C++ 代码，您甚至不需要 extern "C"。 是的，它是便携式的。 但这是糟糕的设计。

Answer 4

我当然不建议使用这种奇怪的子类化。 最好更改您的设计以使用组合而不是继承。
只做一名会员

foo* m_pfoo;

在酒吧课程中，它会做同样的工作。

您可以做的另一件事是再创建一个 FooWrapper 类，其中包含结构本身以及相应的 getter 方法。 然后你可以对包装器进行子类化。 这样虚拟析构函数的问题就消失了。

Answer 5

这是完全合法的，您可以在 MFC CRect 和 CPoint 类的实践中看到它。 CPoint 派生自 POINT（在 Windef.h 中定义），CRect 派生自 RECT。 您只是用成员函数装饰一个对象。 只要您不使用更多数据扩展对象，就可以了。 事实上，如果您有一个复杂的 C 结构，默认初始化很麻烦，那么使用包含默认构造函数的类扩展它是解决该问题的简单方法。

即使您这样做：

foo *pFoo = new bar;
delete pFoo;

那么您也可以，因为您的构造函数和析构函数很简单，并且您没有分配任何额外的内存。

您也不必用“extern "C"”包装您的 C++ 对象，因为您实际上并未将 C++ 类型 传递给 C 函数。

Answer 6

哇，这太邪恶了。

这可以跨编译器移植吗？

绝对不是。 请考虑以下事项：

foo* x = new bar();
delete x;

为了使其正常工作，foo 的析构函数必须是虚拟的，但它显然不是。 不过，只要您不使用 new 并且只要派生对象没有自定义析构函数，您就可能很幸运。

/编辑：另一方面，如果代码仅按照问题中的方式使用，则继承相对于组合没有优势。 只需遵循 m_pGladiator 给出的建议即可。

Answer 7

它可以工作，并且可以移植，但是您不能使用任何虚拟函数（包括析构函数）。

我建议您不要这样做，而是让 Bar 包含 Foo。

class Bar
{
private:
   Foo  mFoo;
};

Answer 8

我认为这不一定是一个问题。 该行为已明确定义，只要您小心处理生命周期问题（不要在 C++ 和 C 代码之间混合和匹配分配），就会执行您想要的操作。 它应该可以完美地跨编译器移植。

析构函数的问题是真实存在的，但只要基类析构函数不是虚拟的，不仅适用于 C 结构，也适用。 这是您需要注意的事情，但并不排除使用此模式。

Answer 9

我不明白为什么你不简单地将 ret_foo 设为成员方法。 您当前的方式使您的代码非常难以理解。 首先使用带有成员变量和 get/set 方法的真实类有什么困难？

我知道可以在 C++ 中对结构进行子类化，但危险在于其他人无法理解您编写的代码，因为很少有人真正这样做。 我会选择一个强大且通用的解决方案。

Answer 10

它可能会起作用，但我不相信它一定会起作用。 以下是 ISO C++ 10/5 的引用：

基类子对象的布局 (3.7) 可能与相同类型的最派生对象的布局不同。

很难看出在“现实世界”中实际情况如何。

编辑：

最重要的是，标准没有限制基类子对象布局可以与具有相同基本类型的具体对象不同的地方的数量。 结果是，您可能拥有的任何假设（例如 POD 性等）对于基类子对象不一定是正确的。

编辑：

另一种方法，其行为被明确定义，是使“foo”成为“bar”的成员，并在必要时提供转换运算符。

class bar {
public:    
   int my_bar() { 
       return ret_foo( foo_ ); 
   }

   // 
   // This allows a 'bar' to be used where a 'foo' is expected
   inline operator foo& () {
     return foo_;
   }

private:    
  foo foo_;
};