不一样
protobuf是一种先定义schema后，使用的是google的数据类型作为模型
这种方式，使用起来对代码的侵入性大， 类型来回转换，使用感觉不佳
理想的方式是，以原生的c++数据结构作为schema，任意定义类型，
将序列化部分与数据结构定义剥离开，序列化实现不会影响系统的模型定义

【 在 ble 的大作中提到: 】
: 还是protobuf啊，重点不是怎么把schema映射成c++数据结构么。
: 至于中间用json还是二进制，只不过改一个函数的事情。
: 好像很多大厂都用nlohmann-json, 主要是对c++新标准支持的好。
: ...................
--
FROM 111.199.191.*

扩充的意义在于无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.*

你这小作坊级初级工程一个人全包，就纯属臆测了，说的好像大公司就不用rest api了一样
小作坊有小作坊的做法，小作坊出品的东西未必就没有精品
大公司出品的也未必就一定优秀
Qt之于C++, Spring之于Java, 技术品味形成于独立思考


【 在 ble 的大作中提到: 】
: 所以你这唯一的优点无非就是服务器随便改呗，小作坊初级工程，一个人前后端全包的确实适合这样，因为不需要沟通成本，不需要文档和接口规范。
--
FROM 111.199.191.*