[开源]C结构体工具DirectStruct，更新至v1.3.0

linux_arm

好人呐！凑够字支持楼主

zylthinking

BetonArmEE 发表于 2014-09-08 21:51
第三波来袭，欢迎大家吐槽，您的建议就是我前进的动力。

再增加XML、JSON序列化/反序列化函数如何？

lz 始终不明白， protocol buffer 之所以有意义， 就在于它在允许协议变动的同时可保证旧版本解析新版本协议； 单纯一个序列化库无意义， 尤其这个库提供不了比裸结构体更简单直观编码的情况下

zylthinking

BetonArmEE 发表于 2014-09-15 14:58
回复 12# zylthinking

若论性能， 你首先超过裸结构体再说； 或者就算不如裸结构体， 也至少编码上比裸结构体方便再说。 二不占其一， 就一个单纯的避免显式调用 htonX 之类的玩意， 比起编码上增加的抽象层造成的脑力负担， 不觉得有什么好一而再而三的

zylthinking

BetonArmEE 发表于 2014-09-15 14:58
回复 12# zylthinking

我现在的应用场景就是客户/服务端必须保持相同的协议版本，不相同就拒绝处理交易，老大要求的

不在于你的场景， 转换位置别老站在作者角度上维护好不？ 1， 需要一个鸟 proto 文件， 还要遵循某些私有语法， 还难说表达力能不能达到 c 结构体的表达能力，多半不如， 我先妄下断言  2， 需要额外的编译步骤 3， 生成的 c 代码依然逃不脱手工调用； 不过 struct.x = htonl(x) 之类的 换成了 generated_function_set(x) 之类， 很好看吗？ 很方便吗？？ 很有用吗？？？

hellioncu

zylthinking 发表于 2014-09-15 15:32
不在于你的场景， 转换位置别老站在作者角度上维护好不？ 1， 需要一个鸟 proto 文件， 还要遵循某些私 ...

我已经打击过好几次了，不过LZ孜孜不倦的搞了好一个又一个的版本。
现在好歹把字符串做变长处理了，直接用结构有点不方便。

我再打击一次：
现在比较大的问题是解的时候没有判断数据的合法性，一个错误的数据包很容易就能把对方搞崩溃。

hellioncu

BetonArmEE 发表于 2014-09-15 16:45
回复 16# hellioncu

版本对后面数据就不会有问题？你这也想得太简单了吧

hellioncu

BetonArmEE 发表于 2014-09-15 16:50
回复 14# zylthinking

数据类型可以用typedef呀，像linux下很多用int32_t之类的，windows也可以类似定义