[開源]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也可以類似定義