c++ - 在使用 STL 容器时是否应该使用结构打包来构建 libstdc++.a 问题？

Question

我们正在将 C++ 中的新功能添加到用 C 编写的大型遗留嵌入式应用程序，该应用程序在整个项目中使用 1 字节的结构封装(由于历史原因，现在可能有效也可能无效)。

使用工具链 arm-none-eabi-g++，我们在使用 std::map 时遇到了问题，因为 libstdc++.a(由工具供应商预先构建，默认打包为 4 个字节)对 struct _Rb_tree_node_base 有不同的想法(在 arm-none-eabi\include\c++\4.7 .3\bits\STL_tree.h) 看起来像，因为

enum _Rb_tree_color { _S_red = false, _S_black = true }; 

该结构中的数据成员在我的程序中为 1 字节宽，而在库中为 4 字节。

我有点惊讶地发现这是一个问题，因为我假设所有的 STL 容器代码都是纯 header (至少是我应该担心的所有位)。基本上，一小段用于 map 实现的代码是作为库的一部分构建的(示例 \arm-none-eabi\src\gcc\libstdc++-v3\src\c++98\tree.cc ).

我的问题是，无论我在打包方面应该做些什么不同(我不会深入探讨的血淋淋的细节)，它是否是实现细节的正确行为，例如 struct _Rb_tree_node_base，这不是 std::map 文档化公共(public)接口(interface)的一部分让我感到悲伤？还是库提供者没有责任确保实现细节不会泄露并导致客户端代码出现问题？

Answer 1

你完全靠自己，除非你的图书馆供应商在你做你刚刚做的事情时记录了行为(在这种情况下，请随时提交错误报告)。

如果您为两个看到相同 header 的编译单元更改了影响类(或结构或其他)大小的编译设置，则无法将它们链接在一起 - 这实际上违反了 ODR(一个定义规则)，即您将链接已看到同一对象的不同定义的代码。

您有责任确保不会发生这种情况，即不要混合使用不同打包/填充选项编译的对象。标准中的任何内容都不能保证这方面的任何内容。