这还不止是直接的数据结构本身是否含有long的问题，不含long成员的结构体、类本身也还是可能隐含long数据用以维护自身信息吧(这取决于编译器的安排？)，这样的话，那怎么夸平台传数据呢？~

【 在 confinement 的大作中提到: 】
: https://blog.csdn.net/foreverfresh/article/details/6731785
: 程序在Linux和Windows之间传数据，结果报long数据不兼容。然后查网页看到上面了解到，两个系统的long数据类型位数不一样...这样，两个系统之间，凡带有long类型的数据就不能直接传了？？
--
修改:confinement FROM 223.104.63.*
FROM 223.104.63.*

尽可能用 stdint.h 里面的定义，比如 int32_t。
新的编辑器基本都支持了。

不要在跨模块，跨编译器间

使用 size_t, long, long long, 这种尺寸比较模糊的类型。




【 在 confinement (禁闭) 的大作中提到: 】
: https://blog.csdn.net/foreverfresh/article/details/6731785
: 程序在Linux和Windows之间传数据，结果报long数据不兼容。然后查网页看到上面了解到，两个系统的long数据类型位数不一样...这样，两个系统之间，凡带有long类型的数据就不能直接传了？？
--
修改:hoodlum FROM 139.226.109.*
FROM 139.226.109.*

不好整了，代码是已经做成了的。况且，是不是会有我前面说的问题，即使你不用那些数据类型，编译器本身为维护数据结构也可能要产生模糊数据类型吧

看起来，就不能直接序列化/反序列化，只能把数据的类型信息丢掉，都整成原始的长度无分歧的类型来传输，然后再“手工”恢复类型？

【 在 hoodlum 的大作中提到: 】
: 尽可能用 stdint.h 里面的定义，比如 int32_t。
: 新的编辑器基本都支持了。
: 不要在跨模块，跨编译器间
: ...................
--
FROM 223.104.63.*

准确点说是同一个struct，本来想像两台Linux之间那样，这边机器实例序列化传过去，那边反序列化出来就用    可是现在，那边同事因为特定软件平台缘故，只能跑Windows

【 在 z16166 的大作中提到: 】
: 你的同一份代码，会在windows和linux上都编译？
: 还是同一份代码会在linux上同时编译出32和64位的二进制？
: 针对特定的OS、特定的位宽（32还是64）处理就行，
: ...................
--
FROM 223.104.63.*

别瞎猜了。想仔细了解的话，可以看看 endian，以及 int, long 等类型在不同平台下的数据长度，以及结构体内存对齐这些知识。不想了解就用上跨平台序列化反序列化了事，可供选择的是：

json, msgpack, protobuf

如果你们用的是 Qt, 还可以用 Qt 特有的 QDataStream

boost 那个很多说不好用。

【 在 confinement (禁闭) 的大作中提到: 】
: 后续重新开始干活的话可以这么考虑，但是我这里试了一个只有一个int 数据成员的struct，还是包错。编译后，可能这个结构它还是会有long类型的东西，编译器给它加了一堆东西吧，或者，是序列化库加的
--
FROM 183.250.222.*