是 std::array如果 T 是 POD，就保证是 POD？
我目前正在编写一个 C++ 内存编辑库，对于读/写 API，我使用类型特征（std::is_pod、std::is_same）和 boost::enable_if 来提供 3 个重载：
- POD 类型。例如 MyMem.Read(SomeAddress);
- 字符串类型。例如 MyMem.Read>(SomeAddress); （这实际上并不读出 C++ 字符串，而是读出 C 样式字符串并将其转换为 C++ 字符串。）
- 向量类型。例如 MyMem.Read>(SomeAddress, NumElem); （这实际上并没有读出向量，而是读出 C 样式数组并将其转换为向量。）
重载 2 和 3 只是重载 1 周围的“包装器”。（因此，如果您正在阅读 std ::vector 或 std::basic_string 并且 T 不是 POD，它会失败，因为它应该失败。）
最近我想使用 std::array 进行一堆读取和写入，因为我知道我想要读取的数据的大小并在编译时写入（我正在编写 PE 文件格式的包装器）。
我编写了使用 std::array 的代码，然后打算添加另一个重载来检测和处理 std::array 类型，但我不小心点击了编译，令我惊讶的是它起作用了！
我目前正在使用 MSVC 10，事实证明，对于 std::array 如果 T 是 POD 那么 std::array 就是 POD。 （这意味着我可以只使用重载 1 并且它可以工作。）
我的问题是这是由 C++ 标准保证的还是由实现决定。
我知道我可以自己检查标准，但我不像信任这个网站上的一些语言律师那样信任自己，所以我认为最好获得“第二意见”。 ；
谢谢
） 此处提供代码（这是一个仅包含标头的库）： http ://code.google.com/p/hadesmem/source/browse/trunk/HadesMem-v2/Hades-Memory/Hades-Memory/MemoryMgr.h#86
I'm currently writing a C++ memory editing library and for the read/write APIs I use type traits (std::is_pod, std::is_same) and boost::enable_if to provide 3 overloads:
- POD types. e.g. MyMem.Read(SomeAddress);
- String types. e.g. MyMem.Read>(SomeAddress); (This doesn't actually read out a C++ string, it reads out a C-style string and converts it to a C++ string.)
- Vector types. e.g. MyMem.Read>(SomeAddress, NumElem); (This doesn't actually read out a vector, rather it reads out a C-style array and converts it to a vector.)
Overloads 2 and 3 are simply 'wrappers' around overload 1. (So if you're reading a std::vector or std::basic_string and T is not POD it will fail, as it should.)
Recently I wanted to use std::array for a bunch of reads and writes because I knew the size of the data I wanted to read and write at compile time (I was writing a wrapper around the PE file format).
I wrote the code to use std::array, and then intended to add another overload for detection and handling of std::array types, but I accidentally hit compile and to my surprise it worked!
I'm currently using MSVC 10 and it turns out that for std::array if T is POD then std::array is POD. (Which means I can just use overload 1 and it works.)
My question is whether this is guaranteed by the C++ standard or left up to the implementation.
I know I could check the standard myself, but I don't trust myself as much as I trust some of the language lawyers on this site, so I figured it would be best to get a 'second opinion'. ;)
Thanks
P.S. Code available here (it's a header-only lib):
http://code.google.com/p/hadesmem/source/browse/trunk/HadesMem-v2/Hades-Memory/Hades-Memory/MemoryMgr.h#86
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
根据 POD 的定义：
[强调我的]
std::array确实满足了作为一个简单的标准布局类模板的所有要求。所以你的问题的答案是肯定的。By definition of POD:
[Emphasis mine]
std::arraydoes satisfy all the requirements of being a trivial, standard-layout class template. So the answer to your question is yes.Potatoswatter 发现我的结论有错误。 C++ 明确允许实现显式定义“具有相同明显语义”的赋值运算符。这将使其成为一种非平凡的可复制类型。使其成为社区维基...
在我看来，您不想针对 PODnes 进行测试，而是针对 trivially copyable 进行测试，后者的限制要少得多。因为这就是 C++0x 约束可以与 memcpy 和朋友一起使用的类型的方式。
虽然我认为对于std::array的 PODness 没有任何保证，但有保证关于琐碎的可复制性，如下所示（如果我的结论没有错误）。我们知道std::array是一个聚合，而聚合是虽然平凡的可复制性是为具有以下类的类定义的：
std::array没有析构函数（正如std::array定义中的注释所述）。尽管 std::array 的类定义中的注释声明了这一点，但这似乎并不符合聚合类的定义。其余 4 个要求是由于缺少用于聚合的这 4 个特殊成员函数的基础、虚拟函数和用户提供的版本。Potatoswatter found an error in my conclusions. C++ explicitly allows an implementation to explicitly define an assignment operator "with the same apparent semantics". This will make it a non-trivially copyable type. Making it community wiki...
It seems to me you don't want to test against PODnes, but against trivially copyable, which is way less restricting. Because that is how C++0x constraints types that can be used with
memcpyand friends.And while I don't think there are any guarantees about PODness ofstd::array, there are guarantees about trivial copyability, as the following shows (if I haven't got an error in the conclusions). As we knowstd::arrayis an aggregate, and aggregates areWhile trivially copyability is defined for a class that has class that
std::arrayhas no destructor (as a comment in the definition ofstd::arraysays). This does not seem to follow from the definition of aggregate classes though, even though the comment instd::array's class definition claims that.The remaining 4 requirements follow from the absence of bases, virtual functions and user provided versions for those 4 special member functions for aggregates.§23.3.1：
在C++03中，POD是根据聚合定义的：一个类，其中每个子对象都是本机的或聚合是POD。因此，通过向后兼容性，C++0x
std::array是 POD。或者，简单来说，可以将 §9/5（定义普通类）、9/6（定义标准布局）和 9/9（将前面的要求合并到 POD 中）的要点与 8.5.1/ 的要点进行比较1，定义聚合。
8.5.1：
事实上，第 9 条中的要求涵盖了
array，只要它的元素类型也是 POD 并且实现中没有声明operator=或move。除了规范之外，code>array。要真正肛门，17.5.2.2 说
模板类数组伪代码中的注释是construct/copy/destroy是否包含operator=（赋值）或move ？它可能应该，但我认为，通过最严格的阅读，它不会。请注意，这不仅“影响”POD 性，而且还影响 Johannes 提到的琐碎可复制性。
§23.3.1:
In C++03, POD was defined in terms of aggregate: a class where every subobject is native or an aggregate is POD. So, by backwards compatibility, a C++0x
std::arrayis POD.Or, to be anal, one can compare the bullet-points of §9/5 (defining trivial class) 9/6 (defining standard-layout) and 9/9 (combining preceding requirements into POD) with those of 8.5.1/1, which defines aggregates.
8.5.1:
Indeed the requirements in Clause 9 cover
arrayas long as its element type is also POD and the implementation does not declareoperator=ormoveinsidearrayin addition to the specifications.To be really anal, 17.5.2.2 says
The note in the pseudo-code for
template class arrayisDoes
construct/copy/destroyincludeoperator=(assignment) ormove? It probably should, but I don't think, by the strictest reading, it does.Note that this "affects" not only POD-ness, but also trivial copyability as Johannes mentions.