有什么方法可以为将来的添加准备一个结构吗？

Question

我有以下结构将用于保存插件信息。我非常确定这会随着时间的推移而改变（很可能会增加）。假设该文件将被修复，还有比我所做的更好的事情吗？

struct PluginInfo
{
    public:
        std::string s_Author;
        std::string s_Process;
        std::string s_ReleaseDate;
        //And so on...

        struct PluginVersion
        {
            public:
                std::string s_MajorVersion;
                std::string s_MinorVersion;
                //And so on...
        };
        PluginVersion o_Version;

        //For things we aren't prepared for yet.
        void* p_Future;
};

此外，在为此系统构建共享对象时我应该采取任何预防措施吗？我的预感是我会遇到很多库不兼容的情况。请帮忙。谢谢

Answer 1

这是怎么回事，还是我想得太简单了？

struct PluginInfo2: public PluginInfo
{
    public:
        std::string s_License;
};

在您的应用程序中，您可能只传递指向 PluginInfo 的指针，因此版本 2 与版本 1 兼容。当您需要访问版本 2 成员时，您可以使用 测试该版本Dynamic_cast 或使用显式 pluginAPIVersion 成员。

Answer 2

你的插件要么是使用相同版本的 C++ 编译器和 std 库源编译的（或者它的 std::string 实现可能不兼容，并且所有字符串字段都将损坏），在这种情况下你必须重新编译插件，并且将字段添加到结构中并不重要

，或者您希望与以前的插件进行二进制兼容，在这种情况下，请坚持使用纯数据和固定大小的字符数组（或者提供一个 API 来根据大小或传入 const 为字符串分配内存char* ），在这种情况下，结构中存在一些未使用的字段并非闻所未闻，然后在需要时将它们更改为有用的命名项。在这种情况下，结构中通常有一个字段来表示它代表哪个版本。

但期望二进制兼容性并使用 std::string 的情况很少见。您将永远无法升级或更改您的编译器。

Answer 3

正如其他人所说，为了二进制兼容性，您很可能将自己限制为 C API。

Windows API 在许多地方通过将 size 成员放入结构中来维护二进制兼容性：

struct PluginInfo
{
    std::size_t size; // should be sizeof(PluginInfo)

    const char* s_Author;
    const char* s_Process;
    const char* s_ReleaseDate;
    //And so on...

    struct PluginVersion
    {
        const char* s_MajorVersion;
        const char* s_MinorVersion;
        //And so on...
    };
    PluginVersion o_Version;
};

当您创建这样的野兽时，您需要相应地设置 size 成员：

PluginInfo pluginInfo;
pluginInfo.size = sizeof(pluginInfo);
// set other members

当您针对较新版本的 API 编译代码，其中 struct 具有其他成员，其大小发生变化，并在其 size 成员中注明。 API 函数在传递这样的 struct 时，大概会首先读取其 size 成员，并分支到不同的方式来处理 struct，具体取决于它的大小。

当然，这假设进化是线性的，并且新数据始终只添加在struct的末尾。也就是说，您永远不会拥有具有相同大小的此类类型的不同版本。

---

然而，使用这样的野兽是确保用户在代码中引入错误的好方法。当他们针对新 API 重新编译代码时，sizeof(pluginInfo) 将自动调整，但不会自动设置其他成员。通过以 C 方式“初始化”struct 可以获得相当的安全性：

PluginInfo pluginInfo;
std::memset( &pluginInfo, 0, sizeof(pluginInfo) );
pluginInfo.size = sizeof(pluginInfo);

然而，即使抛开技术上的事实，将内存清零也可能不会为每个成员赋予合理的值（例如，可能是所有位设置为零的架构对于浮点类型来说不是有效值），这很烦人且容易出错，因为它需要三步构造。

一种解决方法是围绕该 C API 设计一个小型的内联 C++ 包装器。类似于：

class CPPPluginInfo : PluginInfo {
public:
  CPPPluginInfo()
   : PluginInfo() // initializes all values to 0
  {
    size = sizeof(PluginInfo);
  }

  CPPPluginInfo(const char* author /* other data */)
   : PluginInfo() // initializes all values to 0
  {
    size = sizeof(PluginInfo);
    s_Author = author;
    // set other data
  }
};

该类甚至可以负责将 C struct 成员指向的字符串存储在缓冲区中，以便该类的用户甚至不必担心这一点。

---

编辑：由于这似乎并不像我想象的那么清晰，所以这里有一个例子。
假设相同的 struct 将在更高版本的 API 中获得一些附加成员：

struct PluginInfo
{
    std::size_t size; // should be sizeof(PluginInfo)

    const char* s_Author;
    const char* s_Process;
    const char* s_ReleaseDate;
    //And so on...

    struct PluginVersion
    {
        const char* s_MajorVersion;
        const char* s_MinorVersion;
        //And so on...
    };
    PluginVersion o_Version;

    int fancy_API_version2_member;
};

当链接到旧版本 API 的插件现在初始化其 struct 时，如下

PluginInfo pluginInfo;
pluginInfo.size = sizeof(pluginInfo);
// set other members

所示struct 将是旧版本，缺少 API 版本 2 中新的闪亮数据成员。如果它现在调用第二个 API 接受指向 PluginInfo 的指针的函数，它将把旧 PluginInfo 的地址（短一个数据成员）传递给新 API 的函数。然而，对于版本 2 API 函数，pluginInfo->size 将小于 sizeof(PluginInfo)，因此它将能够捕捉到这一点，并将指针视为指向没有 fancy_API_version2_member 的对象。 （据推测，在主机应用程序的 API 内部，PluginInfo 是带有 fancy_API_version2_member 的新且闪亮的 API，PluginInfoVersion1 是该 API 的新名称。因此，新 API 需要做的就是将插件传递的 PluginInfo* 转换为 PluginInfoVersion1* 并分支到可以处理的代码。 API

另一种方法是针对新版本 API 编译一个插件，其中 PluginInfo 包含 fancy_API_version2_member，插入旧版本的 对此一无所知的主机应用程序。同样，主机应用程序的 API 函数可以通过检查 pluginInfo->size 是否大于其自己的 PluginInfo sizeof 来捕获这一点。如果是这样，则该插件可能是针对比主机应用程序所知的更新版本的 API 进行编译的。 （或者插件写入无法正确初始化 size 成员。请参阅下文了解如何简化处理这种有点脆弱的方案。）
有两种方法可以解决这个问题：最简单的是拒绝加载插件。或者，如果可能的话，主机应用程序可以无论如何使用它，只需忽略它所传递的 PluginInfo 对象末尾的二进制内容，它不知道如何解释。
然而，后者很棘手，因为您需要在实现旧 API 时做出决定，而不确切知道新 API 是什么样子。

Answer 4

rwong 建议的 (std::map) 是一个很好的方向。这使得添加有意的字符串字段成为可能。如果您想要更大的灵活性，您可以声明一个抽象基类

class AbstractPluginInfoElement { public: virtual std::string toString() = 0;};

，

class StringPluginInfoElement : public AbstractPluginInfoElement 
{ 
  std::string m_value;
  public: 
   StringPluginInfoElement (std::string value) { m_value = value; }
   virtual std::string toString() { return m_value;}
};

然后您可以派生更复杂的类，例如 PluginVersion 等，并存储 map。

Answer 5

一个丑陋想法：

std::mapm_otherKeyValuePairs; 足够接下来的 500 年了。

编辑：

另一方面，此建议很容易被滥用，因此可能符合 TDWTF 的条件。

另一个同样可怕的想法：
a std::string m_everythingInAnXmlBlob;，如真实软件中所示。

（丑陋==不推荐）

编辑3：

• 优点：
  std::map成员不受< a href="http://en.wikipedia.org/wiki/Object_slicing" rel="nofollow">对象切片。当旧的源代码复制属性包中包含新键的 PluginInfo 对象时，整个属性包都会被复制。
• 缺点：
  许多程序员会开始向属性包添加不相关的东西，甚至开始编写这样的代码： 处理属性包中的值，导致维护噩梦。

Answer 6

这是一个想法，不确定它是否适用于类，它肯定适用于结构：您可以使结构“保留”一些空间以供将来使用，如下所示：

struct Foo
{
  // Instance variables here.
  int bar;

  char _reserved[128]; // Make the class 128 bytes bigger.
}

初始化程序会在填充整个结构之前将其清零，因此该类的较新版本将访问现在位于“保留”区域内的字段，具有合理的默认值。

如果您仅在 _reserved 前面添加字段，相应地减小其大小，并且不修改/重新排列其他字段，那么应该没问题。不需要任何魔法。旧软件不会接触新字段，因为它们不了解这些字段，并且内存占用将保持不变。