iterator::difference_types 是否独立于系统
我有一些序列化逻辑，其中我还序列化 stl 数据结构。目前，我只是编写大小字段，然后通过迭代来编写结构的每个元素。在反序列化中，我读取了大小字段，然后我知道何时完成了数据结构的读取。
不，问题是如何正确编写大小字段并且与系统无关。目前我使用 std::iterator_traits 作为存储在文件中的类型。但是，当我尝试在不同系统之间交换文件时，我不确定这种类型是否保证与系统无关，或者是否可能发生变化。
我查看了 std::string 的这种类型，在这种情况下 sizeof(std::iterator_traits 返回64 位机器上为 8。所以我想在这种情况下，这只是 size_t 的一个 typedef，它占用一个单词。我目前没有可用的 32 位机器，因此我无法检查那里的大小是否有所不同。
标准是否保证这是可移植的，或者我应该对这里的所有数据结构使用某种固定类型来编码长度？
I have some serialization logic in which I also serialize stl datastructures. Currently I just write the size field and then each element of the structure by iterating over it. In the deserialization I read the size field and then I know when I am done reading the data structure.
No the question is how to write the size field correctly and system independent. Currently I am using the std::iterator_traits<const_iterator>::difference_type as the type to store in the file. However I am not sure, if this type is guaranteed to be system independent or if it might change, when I try to exchange files between different systems.
I had a look at this type for std::string and in this case sizeof(std::iterator_traits<std::string::const_iterator>::difference_type) returns 8 on a 64 bit machine. So I guess in this case this is just a typedef for size_t which takes up one word. I do not have a 32 bit machine available here currently so I cannot check if the size is something different on there.
Is this guaranteed by the standard to be portable, or should I use some fixed type for all data structures here to encode the length?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
所有这些 typedef 的要点是您不需要全局修复类型！
对于序列化，您必须决定并修复序列化格式。此时，您可以简单地要求大小适合 32 位整数，测试给定的大小是否适合并进行转换。如果出现错误，您可以让序列化失败（例如“数据结构不可序列化”）。如果您认为有必要，请将大小字段设置为 64 位，您应该有足够的余地，但这取决于您权衡空间与灵活性和使用情况。您真的会拥有包含超过 40 亿个元素的容器并将它们写入磁盘吗？
序列化是关于做出决策和发布处方，你必须忍受并解释导入和导出失败的可能性。
The whole point of all those typedefs is that you do not need to fix the type globally!
For serialization, you will have to decide and fix your serialized format. At that point, you may simply demand that the size fit into a 32-bit integer, test if the given size does and convert. If there's an error, you can just let your serialization fail (e.g. "data structure not serializable"). If you think it's necessary, make the size field 64-bit and you should have plenty of leeway, but it's up to you to weigh space against flexibility and usage profile. Will you really have containers with more than 4 billion elements and write those to disk?
Serializing is about making decisions and publishing prescriptions, and you have to live with and account for the possibility of import and export failures.
不，它不可移植，是的，您应该使用某种固定大小的类型。对于大多数应用程序，32 位整数应该没问题。请注意，根据您的序列化代码和可移植性要求，您还可能面临字节顺序问题（小端序与大端序）。
有关更多信息和最佳实践，请参阅 Qt 文档
QDataStream。 Qt 人们建议选择固定大小的整数类型（例如qint32），然后在序列化时进行适当的转换。No, it is not portable, and yes, you should use some fixed-size type. For most applications, a 32-bit integer should be fine. Please note that, depending on your serialization code and portability requirements, you could also face byte order issues (little-endian vs. big-endian).
For more information and best practices, look at the documentation of Qt
QDataStream. The Qt people recommend to decide on a fixed-size integer type (such asqint32), then cast appropriately when serializing.difference_type由标准定义为“有符号整数类型”（20.1.5，表 32），并且需要为ptrdiff_t< 类型的typedef/code> (20.1.5/4)，而它又是实现定义的 (5.7/6)。由于这里的共同点是它可以转换为“有符号整数类型”，因此如果您需要序列化此值，我建议将其
static_cast'转换为long代码> 并保存它。difference_typeis defined by the Standard to be a "signed integral type" (20.1.5, Table 32) and is required to be atypedefof typeptrdiff_t(20.1.5/4), which, in turn, is implementation-defined (5.7/6).Since the common denominator here is that it is convertible to a "signed integral type", if you need to serialize this value I'd recommend
static_cast'ing it to something like alongand saving that.