- 主题:json反序列化的C++库，用哪个？
json不能说是序列化了，而是人肉可读性很高的抽象化了
稍微复杂一些，带一些动态结构的object，如果还是要走json这条路，那基本肯定是要多一步转换函数的。
如果仅仅需求是方便的正反序列化，且侵入性不算太强的，boost::serialization, boost::ipc::managed_heap_memory/managed_external_buffer，第一个是传统的编码序列化，第二个是分配一块内存，把所有静态和动态的结构都建在内存中，然后直接把内存按顺序发过去，但是序列化效率有待检验
如果一方面object又很复杂，又想要简单且高效的序列化，只能说是设计有问题了：真的有那么多数量和结构都很复杂的数据需要动态传输嘛？
通讯密集 <-> object复杂度，平衡来选了
【 在 z16166 的大作中提到: 】
: json -> c++ object。
: 由于各种原因，没有使用protobuf，而是用了json。
: 用jsoncpp手写代码挨个提取json节点里的数据挺无聊的，纯粹是堆代码行数。
: ...................
--
修改:ziqin FROM 115.193.168.*
FROM 115.193.168.*
对的，protobuf的优势是数据传输的效率高，并不是当一个存储格式来设计的。
【 在 KillnCov 的大作中提到: 】
protobuf是通信协议， 不是用来序列化对象的。完全不同的用处。
很多人非要把proto用来存储对象，变向说明c++的序列化没啥好用的库。
【 在 iwantfly 的大作中提到: 】
: 不一样
: protobuf是一种先定义schema后，使用的是google的数据类型作为模型
: 这种方式，使用起来对代码的侵入性大， 类型来回转换，使用感觉不佳
: ...................
--来自微微水木3.5.12
--
FROM 123.123.42.254
agent和server之间通信，消息类型有个20+，而且会扩充。
agent和server可能是异构的，cpu硬件不一样
【 在 ziqin 的大作中提到: 】
: json不能说是序列化了，而是人肉可读性很高的抽象化了
: 稍微复杂一些，带一些动态结构的object，如果还是要走json这条路，那基本肯定是要多一步转换函数的。
: 如果仅仅需求是方便的正反序列化，且侵入性不算太强的，boost::serialization, boost::ipc::managed_heap_memory/managed_external_buffer，第一个是传统的编码序列化，第二个是分配一块内存，把所有静态和动态的结构都建在内存中，然后直接把内存按顺序发过去，但是序列化效率有待检验
: ...................
--
FROM 114.241.227.*
第一个扩充是什么意义上的？有多大成分是运行时的？我的理解是，在一般的应用场合，A <--> S 之间的通讯，即使在通讯结构转换这个层面有必要做到纯运行时，但是在业务逻辑层面，多多少少都是要在代码层面增补的（编译时）。
第二个，如果不涉及cpu cache hit rate之类的，硬件其实无所谓，大小端统一的问题，网络库层应该内部搞定，和应用层没关系。
听下来还是序列化的老问题，就是动态结构(vector, map之类）怎么自动正反序列化。protobuf msg可以有descriptor，可以实现动态转换，json如果没有这个机制，恐怕你的需求是不行的。如果对运行、传输和编码效率没有太高要求的话，我觉得可以用boost::ipc::managed_external_buffer，就是运行的时候都是boost::ipc 的container了。
我觉得最大的可能就是你们框架并不在你的控制范围内，然后你只有继续搬砖了。
Managed External Buffer: Constructing all Boost.Interprocess objects in a user provided buffer
Sometimes, the user wants to create simple objects, STL compatible containers, STL compatible strings and more, all in a single buffer. This buffer could be a big static buffer, a memory-mapped auxiliary device or any other user buffer.
This would allow an easy serialization and we’ll just need to copy the buffer to duplicate all the objects created in the original buffer, including complex objects like maps, lists.... :
【 在 z16166 的大作中提到: 】
: agent和server之间通信，消息类型有个20+，而且会扩充。
: agent和server可能是异构的，cpu硬件不一样
:
--
FROM 125.119.102.*
扩充的意义在于无schema,json既代表字符串，又代表万物
你见过http ajax服务器端修改了 webservice 接口
还需要单独发布一个dll或者头文件，才能访问吗？
为了访问一个服务端的接口，必须限定语言，限定编译器，限定库链接
类似protobuf这种固定schema访问的接口， 除了效率高简直就是一无是处
绝大多数web框架，都允许你对ajax及http协议无需了解， 就完全可以使用语言内置数据结构编写ajax服务， 通讯层和主干框架完全融为一体
而protobuf这种东西， 光链接编译搭环境就够喝一壶的, 还要学习各种细节，进行各种类型转换，这种玩意，完全割裂开通讯层与系统的主干框架， 多一个库就多一个麻烦， 尤其是这种非标准的技术
【 在 ziqin 的大作中提到: 】
: 第一个扩充是什么意义上的？有多大成分是运行时的？我的理解是，在一般的应用场合，A <--> S 之间的通讯，即使在通讯结构转换这个层面有毕业做到纯运行时，但是在业务逻辑层面，多多少少都是要在代码层面增补的（编译时）。
: 第二个，如果不涉及cpu cache hit rate之类的，硬件其实无所谓，大小端统一的问题，网络库层应该内部搞定，和应用层没关系。
: 听下来还是序列化的老问题，就是动态结构(vector, map之类）怎么自动正反序列化。protobuf msg可以有descriptor，可以实现动态转换，json如果没有这个机制，恐怕你的需求是不行的。如果对运行、传输和编码效率没有太高要求的话，我觉得可以用boost::ipc::managed_external_bu
: ...................
--
FROM 221.219.211.*
基于json的webservice，服务端修改之后照样需要文档之类的规范schema，跟发布一个pb没有区别
pb可以向下兼容，不用新功能的话不需要升级client
json的优势在于人可读，js内置，对于web应用自然是首选
但很多server端的service，性能是首要考虑因素，grpc/thrift之类的是首选
【 在 iwantfly 的大作中提到: 】
: 扩充的意义在于无schema,json既代表字符串，又代表万物
: 你见过http ajax服务器端修改了 webservice 接口
: 还需要单独发布一个dll或者头文件，才能访问吗？
: ...................
--
FROM 106.120.46.*
我感觉现在的代码已经接近于屎山了
不过实际项目中我估计99%的项目都是在赶需求进度，有些人甚至到处复制老的代码块和函数改改，json解析那更不用说，先堆代码打通功能再说
不过这并不妨碍在搬砖的同时想想怎么能做得更好，在2.0、3.0重构时（如果还有重构的机会）能用一种更好的写法。到时也得有理由说服别人。
【 在 ziqin 的大作中提到: 】
: 第一个扩充是什么意义上的？有多大成分是运行时的？我的理解是，在一般的应用场合，A <--> S 之间的通讯，即使在通讯结构转换这个层面有必要做到纯运行时，但是在业务逻辑层面，多多少少都是要在代码层面增补的（编译时）。
: 第二个，如果不涉及cpu cache hit rate之类的，硬件其实无所谓，大小端统一的问题，网络库层应该内部搞定，和应用层没关系。
: 听下来还是序列化的老问题，就是动态结构(vector, map之类）怎么自动正反序列化。protobuf msg可以有descriptor，可以实现动态转换，json如果没有这个机制，恐怕你的需求是不行的。如果对运行、传输和编码效率没有太高要求的话，我觉得可以用boost::ipc::managed_external_buffer，就是运行的时候都是boost::ipc 的container了。
: ...................
--
FROM 114.241.227.*
json还有jsonb, cbor等等兼容二进制
pb之所以效率高，无非就是二进制罢了，比自己手写个二进制快不到哪里去
至于什么可以向下兼容之类的，我要改需求改协议有啥可二进制兼容的， 快速开发才是王道
【 在 jimmycmh 的大作中提到: 】
: 基于json的webservice，服务端修改之后照样需要文档之类的规范schema，跟发布一个pb没有区别
: pb可以向下兼容，不用新功能的话不需要升级client
: json的优势在于人可读，js内置，对于web应用自然是首选
: ...................
--
FROM 221.219.211.*
你是牛人，随随便便吊打google
不要兼容性的也是牛人
【 在 iwantfly 的大作中提到: 】
: json还有jsonb, cbor等等兼容二进制
: pb之所以效率高，无非就是二进制罢了，比自己手写个二进制快不到哪里去
: 至于什么可以向下兼容之类的，我要改需求改协议有啥可二进制兼容的， 快速开发才是王道
: ...................
--
FROM 106.120.46.*
那是你在带宽不紧张的情况。
以前做无线通信，看看asn.1编解码的规则，就是为了省下几个bit几个字节。
看看pdcp，就是为了压缩tcpip的头部。
总之，不同需求用不用的协议，不同的库。
【 在 iwantfly 的大作中提到: 】
: 扩充的意义在于无schema,json既代表字符串，又代表万物
: 你见过http ajax服务器端修改了 webservice 接口
: 还需要单独发布一个dll或者头文件，才能访问吗？
: ...................
--来自微微水木3.5.12
--
FROM 39.144.105.*