std :: tuple sizeof，是否错过了优化？

我已经检查了所有主要的编译器，并且sizeof(std::tuple<int, char, int, char>)所有这些都是16。大概它们只是将元素按顺序放入元组中，因此由于对齐而浪费了一些空间。

如果元组在内部像这样存储元素：int, int, char, char，则其sizeof可以为12。

实现有可能执行此操作，还是该标准中的某些规则禁止这样做？

std :: tuple sizeof，是否错过了优化？

是的

一个实现有可能做到这一点吗？

是的

[标准中是否有某些规定禁止使用？

不！

通读[tuple]，在实现上没有约束以模板参数的顺序存储成员。

实际上，我能找到的每一段似乎都竭尽全力避免完全引用任何成员声明顺序：get<N>()用于操作语义的描述。其他措词用“元素”而不是“成员”来表示，这似乎是故意的抽象。

实际上，某些实现显然确实以相反的顺序存储成员，至少可能是由于它们以递归方式使用继承来解压缩模板参数的方式（并且如上所述，因为它们被允许）。

但是，在专门谈论您的假设优化时，我不知道有没有以用户给定顺序的某些琐碎功能存储元素的实现；我猜想，std::get至少与通过这种方式获得的收益相比，提出这样的订单并为提供机器是“困难的” 。如果您真的很关心填充，那么您当然可以谨慎选择元素顺序以避免出现填充（在某些给定平台上），就像您使用类（无需深入研究“打包”属性的世界）那样。（“打包”的元组可能是一个有趣的建议……）

是的，这是有可能的，并且已经（大部分）由R. Martinho Fernandes完成。他曾经有一个名为Flaming Danger Zone的博客，由于某种原因该博客现在已关闭，但其源仍可在github上找到。

这里有四个部分的大小事项在这个确切的主题系列：1，2，3，4。

您可能希望原始查看它们，因为github无法理解所使用的C ++高亮标记，并将代码段呈现为不可读的oneliners。

他本质上是通过C ++ 11模板元程序为元组索引计算一个排列，该排列按不升序对元素进行排序，并根据其存储元素，然后将其应用于每次访问的索引。

不能这样做的另一个原因是：包括x86在内的某些体系结构具有索引模式，该模式可以在一条指令中处理地址基址+大小×索引-但仅当大小为2的幂时才可以执行，否则执行加载可能会稍快或将存储对齐到16字节边界。std::tuple如果它们添加四个填充字节，则可以使代码处理速度更快，结构更紧凑的数组。