维护 ABI：向结构添加构造函数

Question

我们在共享库的修订版 1 中有一个结构体，我们需要为其维护 ABI：

struct Person
{
    std::string first_name;
    std::string last_name;
}

在修订版 2 中，我们将 Person 更改为：

class Person
{
public:
    Person(const std::string &f, const std::string &l);

    std::string first_name;
    std::string last_name;
}

为了保持源代码兼容性，我们希望修改 Person 的版本 1，以便针对较新的头文件编译的代码将运行，未重新编译的代码将运行。

我们可以使用两个新的非内联构造函数执行以下操作吗：

class Person
{
public:
    Person();
    Person(const std::string &f, const std::string &l);

    std::string first_name;
    std::string last_name;
}

我们正在使用 g++ 完成这一切。在使用 nm 查看生成的共享库时，我没有看到普通结构的构造函数或析构函数，因此我猜测未重新编译的代码只会像以前一样在调用站点构造 Person，这很好。任何重新编译的代码都将使用无参数构造函数。

我看到的唯一问题是，如果我们需要回滚到没有构造函数的旧版本共享库，那么针对它编译的任何代码都会中断，但我并不担心这种情况。

Answer 1

那么下面的呢？

class NewPerson : public Person
{
public:
    NewPerson(const std::string &f, const std::string &l)
    {
      first_name = f;
      last_name = l;
    }
}

Answer 2

它可能“有效”，但您将违反“单一定义规则”，并且就 C++ 标准而言，您将陷入“未定义行为”领域，这不是一个好地方。

Answer 3

我认为它应该有效，假设您的显式默认构造函数与之前使用的隐式构造函数执行相同的操作。在这个简单的例子中。然而，恕我直言，很难预测或知道编译器将做什么/改变什么。我自己不会相信它，如果我是你，我宁愿重新编译库用户。

Answer 4

在不破坏二进制兼容性的情况下向类或结构添加新的非虚拟函数应该没有问题。这是因为类函数被实现为普通函数，并采用隐式 this 作为其第一个参数。

但是，如果添加新的虚拟函数，则可能会破坏兼容性，因为新函数将强制修改 vtable，可能会破坏兼容性。

因此添加额外的构造函数（永远不能是虚拟的）不会破坏兼容性。如果要添加虚拟析构函数，很可能会破坏兼容性。

Answer 5

此类事情可能存在风险，了解何时可以或不能安全地进行此类更改可能很困难。该标准不会帮助您，它只是将任何此类更改称为“未定义的行为”。

g++ 确实有一个定义良好的 ABI，但该 ABI 相当复杂，并且有一些您可能不知道的极端情况。

一个特别值得关注的是 POD 和非 POD 类型的处理方式通常截然不同。将构造函数添加到以前是 POD 的类型可以使其成为非 POD，这可以显着改变它作为参数传递的方式以及它作为基类合并的方式。在您的特定情况下，由于字符串字段，您的类型已经是非 POD，所以我认为这在这种特定情况下不是问题，但它肯定是您在类似情况下可能遇到的陷阱。

还有一个有趣的问题是，当某些行为根据 ABI 明确定义，但根据 C++ 标准未定义时，会发生什么情况。如果禁用 lto，这不是问题，但如果启用 lto，编译器有可能检测到未定义的行为并将其视为优化机会。我不知道是否真的有。