直接序列化结构 [英] directly serializing structs

问题描述

问候，


直接将C ++结构序列化为文件时使用标准的

库函数给出数据的地址和长度
使用sizeof运算符的
结构，因为

不同的编译器将结构打包成不同的大小或者这个结构的组件到不同的地址边界，所以我冒便携的风险吗？ for

例如在32位系统上放置4的倍数）？一旦文件被串行化后，由另一个编译器编译的相同代码甚至是相同的编译器，但是不同的版本带有不是
$ b的风险$ b正确阅读内容？


谢谢

Greetings,

When directly serializing C++ structures to a file with the standard
library functions giving the address of the data and length of
structure using the sizeof operator, do I risk portability because of
different compilers packing structures into different sizes or
components of this structure to different address boundaries (for
example placing in multiples of 4 on a 32bit system)? Once the file is
serialized, does the same code compiled by another compiler or even
the same compiler but a different version carry the risk of not
reading the contents properly?

Thank you

推荐答案

Cagdas Ozgenc写道：

Cagdas Ozgenc wrote:

问候，


直接将C ++结构序列化为具有标准

库的文件函数使用sizeof运算符给出数据的地址和

结构的长度，因为

不同的编译器将结构打包成不同的大小，我是否有冒险的风险？
这个结构的
组件到不同的地址边界（对于

例子，在32位系统上放置4的倍数）？

Greetings,

When directly serializing C++ structures to a file with the standard
library functions giving the address of the data and length of
structure using the sizeof operator, do I risk portability because of
different compilers packing structures into different sizes or
components of this structure to different address boundaries (for
example placing in multiples of 4 on a 32bit system)?

是的。您还存在可移植性问题的风险，因为不同的编译器（或

平台）具有不同的单个数据项格式。字节

整数排序通常因平台而异，浮点

格式甚至可以因同一平台上的不同编译器而异。


一旦文件是

Yes. You also risk portability problems because different compilers (or
platforms) having different formats for individual data items. Byte
ordering for integers often varies across platforms, floating point
formats can even vary for different compilers on the same platform.

Once the file is

序列化，由另一个编译器编译的相同代码甚至是/ b $ b b相同的编译器，但是不同的版本带有没有

正确阅读内容的风险？

serialized, does the same code compiled by another compiler or even
the same compiler but a different version carry the risk of not
reading the contents properly?

是的，见上文。


如果这是一个问题，那么考虑使用文本，它更便携。

Yes, see above.

If this is a concern then consider using text, it''s much more portable.

>

谢谢

>
Thank you

Cagdas Ozgenc写道：

Cagdas Ozgenc wrote:

问候，


直接将C ++结构序列化为具有标准的文件

库函数使用sizeof运算符给出数据的地址和

结构的长度，因为

不同的编译器将结构打包成不同的大小或者/>
这个结构的组件到不同的地址边界（对于

，例如在32位系统上放置4的倍数）？一旦文件被串行化后，由另一个编译器编译的相同代码甚至是相同的编译器，但是不同的版本带有不是
$ b的风险$ b正确阅读内容？

Greetings,

When directly serializing C++ structures to a file with the standard
library functions giving the address of the data and length of
structure using the sizeof operator, do I risk portability because of
different compilers packing structures into different sizes or
components of this structure to different address boundaries (for
example placing in multiples of 4 on a 32bit system)? Once the file is
serialized, does the same code compiled by another compiler or even
the same compiler but a different version carry the risk of not
reading the contents properly?

是的，确实如此。内部布局是实现定义的。


-

Ian Collins。

Yes, it does. Internal layout is implementation defined.

--
Ian Collins.

" Cagdas Ozgenc" < ca *********** @ gmail.comwrote in message

news：11 ******************* **@w5g2000hsg.googlegrou ps.com ...

"Cagdas Ozgenc" <ca***********@gmail.comwrote in message
news:11*********************@w5g2000hsg.googlegrou ps.com...

问候，


直接将C ++结构序列化为文件时使用标准的

库函数使用sizeof运算符给出数据的地址和

结构的长度，因为

，我是否存在可移植性的风险不同的编译器将结构打包成不同的大小或

这个结构的组件到不同的地址边界（对于

例子，在32位系统上放置4的倍数）？一旦文件被串行化后，由另一个编译器编译的相同代码甚至是相同的编译器，但是不同的版本带有不是
$ b的风险$ b正确阅读内容？

Greetings,

When directly serializing C++ structures to a file with the standard
library functions giving the address of the data and length of
structure using the sizeof operator, do I risk portability because of
different compilers packing structures into different sizes or
components of this structure to different address boundaries (for
example placing in multiples of 4 on a 32bit system)? Once the file is
serialized, does the same code compiled by another compiler or even
the same compiler but a different version carry the risk of not
reading the contents properly?

您的软件/应用程序是否需要那么多的可移植性？为什么要用写一次，随处编译来挣扎
如果你只针对一个平台或

甚至只有一台机器，例如？


我不会打电话给你上面描述的那个序列化"虽然。对我来说，

序列化你的内涵是你确实在研究结构

和数据成员的大小，它们的填充等，或者通过有线传输使用ASN.1 / BER来获得
，再举一个例子，而不仅仅是做一个结构大小写的
。建议的做法是在每个边界（磁盘，电线）上传输所有内容，这对我来说似乎不自然和乏味。我想

a层在非主要的b / b
平台上进行流媒体的边界并且在主平台上做任何事都不是那么糟糕

工具。


我可以想到3个阻止爆炸结构全部结束的问题。概念
来自工作的
：endianess，padding / alignment，datatype sizes。第一个是派对破坏者的
。保证宽度整数有助于最后一个问题。

字节对齐数据（无填充）可能在大多数编译器上都可用（？）。

Endianess尽管如此，那么''为了使

概念有效，你可以做多少。幸运的是，大端机器的用户大多数与小端机器用户不同，所以你可以只需要b $ b来挑选你的目标用户并为他们量身定制你的软件。或者做

转换：


结构在英特尔上线到Sparc - 没有更改为struct

struct即将到来从英特尔转换到Sparc - 转换结构endianess
$ spb将sparc转换为磁盘 - 转换结构endianess

结构在Sparc转向英特尔 - 转换结构endianess
$ b从Sparc进入英特尔的$ b struct - 没有更改为struct

stuct on Intel go-disk


（以上场景假设平台需要独立的文件。如果没有，

需要更少的转换。）

（是的，在任何人打趣之前，我知道网络字节顺序很大

endian。还有比Unix更多的Windows机器。


（问题4：一个字节的大小）。

John

Does your software/application require that much portability? Why struggle
with "write once, compile anywhere" if you''re only targeting one platform or
even only one machine, for instances?

I wouldn''t call what you described above "serializing" though. To me,
"serializing" has the connotation that you indeed are looking into structs
and the sizes of data members, their padding etc. or using ASN.1/BER for
over the wire transmission, for another example, rather than just doing a
struct-sized write. The recommended practice of streaming everything at
every boundary (disk, wire) seems unnatural and tedious to me also. I guess
a layer at the boundaries that does the streaming on the non-primary
platform and doesn''t do anything on the primary platform isn''t that bad to
implement.

I can think of 3 issues that prevent the the "blast struct all over" concept
from working: endianess, padding/alignment, datatype sizes. The first one is
the party spoiler. Guaranteed width integers helps for the last issue.
Byte-aligning data (no padding) is probably available on most compilers (?).
Endianess though, well there''s not much you can do about that to make the
concept work. Luckily, the users of big endian machines are mostly
categorizably different from little endian machine users, so you can just
pick your target users and tailor your software to them. Or else do the
conversions:

struct on Intel going over wire to a Sparc -no change to struct
struct coming into Sparc from Intel -convert struct endianess
struct on Sparc going to disk -convert struct endianess
struct on Sparc going to Intel -convert struct endianess
struct coming into Intel from Sparc -no change to struct
stuct on Intel going to disk -no change to struct

(The above scenario assumes platform-independent files are desired. If not,
fewer conversions required).
(Yes, before anyone quips, I do know that "network byte order" is big
endian. There''s also more Windows machines than Unix).

(Issue 4: size of a byte).

John

这篇关于直接序列化结构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！