@vicence 就是 linus 那句名言：Read The Fucking Source Code

https://sites.google.com/site/shopexts/trading/php/read-the-fucking-source-code

1.《 LINUX 设备驱动程序》，多数嵌入式开发的人是做驱动，如果楼主不是，可以看《 Linux 内核模块编程指南》
2.《深入理解 LINUX 内核》
3. linus: RFSC

1，对模块机制、驱动开发有足够的了解
2，对 linux 内核比较全面的了解
3，前两本能拿下，剩下的就是啃源码了
其他的书没什么必要看，浪费时间，尤其 200 多页那本，看上去啥都讲了，实际相当于啥都没讲，就跟《七周七语言》《七周七并发》那些书类似，连鸡肋都不如：食之无味、弃之不可惜

@shujun 感谢支持！

golang，你值得拥有

@marceliu323 嗯嗯，如果是 pos 机里面已经使用了某种序列化，那是没法换 pb 之类的了，如果 c/s 端都是自家可控的，可以选择 pb 之类的。

一些老 c/cpp 项目是直接把不涉及深拷贝的 struct 的 sizeof 内存段拷贝过来用于序列化的，另一端 c/cpp 也是直接 struct X *p = (struct X *)buf，这种确实比较酸爽。唯有重构，能得结果 :joy:

关于序列化，protobuf/json 足够用了，并且还有其他一大堆知名的序列化方案可选。

另外，是否支持完备的嵌套，比如是否支持 struct 内的 struct 成员、数组成员、数组成员的元素是 struct 等。如果支持，算是相对完善，剩下的要看性能，如果不支持，对业务太不友好了。对于性能，主要是两个方面考量，一是速度，二是生成的数据长度。因为是用注释的方式，也就意味着要反射，性能可能不会比 protobuf 这些生成代码的快、长度也不会比 protobuf 能省，因为没有按照固定的 proto 生成固定的代码，所以传输给对方解码时仍需要带上 key 信息，相比 json 倒是可以把一些引号冒号省了，但可能又跟 MessagePack 差不多了。

单就序列化，对简化 tcp 服务消息封装和解析帮助不大。楼主应该是指这个 Header 做包长相关的流到包的解析。这个对于 go 也比较简单，单独协程读的方案，有 ReadFull 这些方便的方法，不需要像 c/c++ 那些异步解析稍微费神（但是异步解析费神也不算太多）。所以，整体看，tcp 服务也没必要用这种序列化方案。实现这种序列化，对学习和提高编解码能力是好事情，但建议使用更成熟优秀的方案。

@nannanziyu 对，很多不必要的争论都源自误解的分歧，所以没必要。回头望跟跳出圈外看事情是一个道理，往往旁观者清。

另外，我并不是想用自己两个库 star 数量来说明自己水平还可以，因为相比于同类项目动辄头部大厂团队多年积累、或者 5k+ star，而我那两个性能综合指标、易用性、扩展性都更强，star 数少得可以忽略。。。

@nannanziyu
> 我想说的就是一句 “2021 年了，c++ 发一个简单的 http 请求不麻烦了

兄台，你仔细想想，不管是不是包括搜索的步骤，你想去极力说明的观点，对于跟你辩论的同学来说，就是在说明 cpp 门槛不高。所以上一个帖子我也看了但是没在里面回复。

其实最简单的一点，你来一句“cpp 门槛确实高，但之前的楼主主要是研究方法不当、比如连搜索都不太会”，就能避免大家的分歧。

年纪越大了，就越知道很多事情都是在浪费时间，所以，这个问题我要“回头”了，再回帖只交流技术好了。

@Cbdy 基础设施的领域，因为开发者自身水平比较高，通常 c 也能搞定。基础设施用 c++的，牛逼的团队会限制姿势使用 c++比如只用 c with class and stl 。内存敏感的领域甚至连 stl 都是要禁的。

非基础设施的领域，因为涉及到很多更偏商业业务的，开发人员水平也有很多初级中级，所以单就 stl 讲就比纯 c 好用的多。尤其是还有很多年代背景，那个年代还是 tr1 、boost 早期阶段，没有 c++11 到 21 这些更加闹心的语言标准和姿势，那时候有很多 c++的老项目。现在仍然有很多性能敏感的偏商业业务是 c++的天下，因为 rust 还太年轻，需要一些年头去过度才能大面积取代 c++。

> 可能还有一种工程师的选择，就是不碰 C++
牛逼点的工程师，还是需要一些 c++的积累的。可以选择不用，但至少自己能够知道为什么不用、并且用其他的什么能在性能、开发效率、商业之间收获更好的平衡收益。

> C++就是碰瓷营销 C 语言，就像 JavaScript 碰瓷营销 Java 一样，把很多人都迷惑了
也不算碰瓷，c++诞生的年代，确实需要比 c 更方便一些的功能来让业务开发效率得到提升，c 是对于高手相对友好，但是复杂业务仍然门槛高，比如内核你去读源码，一个逻辑十几层的宏看着看着就忘记了从哪里过来的、非常耗费时间。cpp 相比于 java 的一大劣势是作者本身，bj 老爷子本身是偏学术型的学者而非偏商业的大佬，并且那个年代，前面的编程语言可借鉴的主要是 c，而 java 是 sun 公司搞出来的，性能其次考虑，很多特性尤其是 gc 和成熟的社区方案供给，对开发者太友好了、可以极大促进商业成功。
c++也并非失败，只是相比于稍晚辈的 java 的成功显得差一些。去年看到一篇 bj 老爷子的专访，还是比较客观的：
https://new.qq.com/omn/20201117/20201117A0988S00.html

我看好 rust 逐渐在更多领域替代 cpp

楼主还忽略了一点，跟你争论的人里是有不少熟手的，这些都是可以自己解决原贴的 cpp 问题的人，然而这些人同样认为 cpp 门槛高。各位 battle 的点，是门槛高，而不是如何解决发送 http 请求这个问题本身了。

我前面说学 cpp 关隘在于 “回头”，技术交流又何尝不是，在并非技术细节本身而是对技术认可相关评价的问题上，更广大用户的态度是不认可，而自己却一味坚持去解释它并不这样。

每次的自我否定通常也会给自己带来知识和心境的提升，早回头，少浪费点时间吧。

> 我主语言是 java

我之前看到你说主语言是 java 了。
我讲的跟主语言没关系，而是对待 cpp 的态度。太多人沉迷于维护 cpp 的名声而不自知了。

> 2. 这楼里，你和 @darknoll 两个刚入门的人，蹲在井底一块落砖上，却以为站在高台上指点别人，贻笑大方。走出井看看，你会发现世界不一样

我也快 40 了，十几年前最早就是开始写 c/c++ 写了好多年，现在已经不靠代码为生。至于水平，这里有我两个 go 的 repo：
https://www.v2ex.com/t/794435#reply1

做的晚，宣传力度小，star 少，但你可以对比下同类 repo，再来评价我是不是刚入门:
https://github.com/cloudwego/kitex-benchmark
https://github.com/lesismal/go-net-benchmark

《一代宗师》里「老猿挂印回首望，关隘不在挂印，而是回头」。
对于 cpp，回头的含义可以理解为：能够正视 cpp 的问题，而不是用 “如何解决 cpp 的某个问题” 来解释 “所以 cpp 没这个问题”。你用 1 分钟发 http 请求，就相当于是在用 “如何搞定发 http” 来跟别人 battle “cpp 门槛高” 的问题。

之前帖子里我没有回复也是因为懒得去 battle cpp 相关的，以前在各种老论坛、技术群跟人 battle 得太多了，对于 cpp 最清醒的大概两类人，一类是顶尖一批接近语言律师级别的大神、既能精通各种语法予以模式又能在实际业务中合理运用，一类是独孤九剑式的清醒工程师、知道什么不利于工程所以弱水三千只取 cpp 最合适的那一瓢或者几瓢来做项目。剩下的要么被 cpp 折磨要么转其他了。

@shoaly github 是非常方便和足够交流的，技术群会消耗我大量的社交时间，所以暂时不打算建群。有需要的在 github 上提 issue 就可以了，习惯了 github 对大家提升水平也有帮助。

《一代宗师》里「老猿挂印回首望，关隘不在挂印，而是回头」。
工程师学习的 cpp 的过程，关隘不在挂印——比如精通 cpp 各种语法予以达到语言律师级别，关隘在回头。

中毒的 cpper 千篇一律，清醒的工程师万里挑一。

@bthulu 果然不行，白高兴了

@bthulu 看你回复的好像还是不行呀，我试试

```golang
println("test markdown response"
```