- 主题:已经完全抛弃C++了
恰恰相反，新的C++远比C好用
单纯一个RAII机制，就足以让我抛弃C了，想象一下C得在函数里的每个early return之前都要加一句资源释放语句的那种情况，既属于凑代码行数，还是error-prone的，以至于要发展出goto、do...while(0)、__try/__finally等蹩脚的“技法”来规避这种问题。
而ranged for语句，就是用来规避C里面手撸loop条件容易出现边界错误的
类似的例子，可以举一大箩筐
感觉C里面加一个go的defer是正途，哈哈
而且是有这种提案和实现的
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2895.htm
https://github.com/moon-chilled/Defer （受限于编译器，这个实现远非完美）
--
修改:z16166 FROM 222.130.136.*
FROM 222.130.136.*
那是老规矩了，或者是特殊行业
有RAII加持，推荐用early return
这有个关于early return的argue，有点意思，包括下面的评论
https://www.fluentcpp.com/2018/08/24/how-to-design-early-returns-in-c-based-on-procedural-programming/
【 在 brucewww 的大作中提到: 】
: 我们以前有一项规定就是只能最后统一返回，中间禁止。
--
修改:z16166 FROM 222.130.136.*
FROM 222.130.136.*
C++有它自己不好的地方，昨天我就看到一个喷std::variant的封装导致访问麻烦的blog，要么用std::visit，要么用overloaded，新手不太容易很快搞懂这两种，可能只能用std::get_if这种原始的。
最简单的原则是：不要用自己还没熟练掌握的C++特性。带类的C对不少场合也许就够用。
C++搞复杂语法，不纯粹是为了满足低级程序员不出错的需要。况且要真能解决这个问题，那也是很牛的，参考一下Rust用什么样的语法来解决码农易犯的内存错误、同步错误。C++的目的一直是两个：direct hardware mapping、abstraction with zero cost。执行时有没发生目标偏差，那得众人评说了。
编译出来的东西又大又慢，这个恐怕不符合实际，或者说你的项目和问题的规模本身就大，或者说不会用。
比如C在每个early return之前加一句fclose(f)，编译出来的代码肯定比C++只在dtor里加一句fclose(f)要大，因为会多出来很多句fclose(f)的调用。
【 在 ksxfhs 的大作中提到: 】
: 自己写释放代码才是内存管理的精华
: C++搞了一堆复杂的语法只是解决一个很简单的问题，满足低级程序员不出错的需要
: 或者搞出新语法只是为了省了两行代码，但实际运行效率一秒都不少，编译出来的东西又大又慢
: ...................
--
FROM 222.130.136.*
不是RAII要求用early return，而是RAII让early return更放心，
如果所有资源都用RAII管理，那么early return就不会导致资源泄漏
是否使用early return，是一种偏好，有人用，有人不用。
【 在 teleheart 的大作中提到: 】
: raii要求用early return吗？Linux内核里有大量这种风格的代码，逻辑也都很清楚
:
https://vilimpoc.org/research/raii-in-c/:
--
FROM 222.130.136.*
C++可没有说你的内存管理必须用它提供的RAII或者“高级”语法来搞，在C++里你也完全可以手撸内存管理代码，只要你有这个需要
但是RAII等机制，提供了更便捷同时又没损失什么效率的抽象，使得码农可以兼顾开发效率、代码质量、代码速度。
【 在 ksxfhs 的大作中提到: 】
: 内存管理是基本功
: 基本功不好，指望C++提供些语法规避这个问题，就是不入流
: 能自己熟练管理内存，再用新语法辅助避错，才是正道。一个新手连内存概念都不熟，就只会用这些新语法跳过问题，能写出真正高效的算法才是怪事
: ...................
--
FROM 222.130.136.*
有需求，才有动力和机会
没有需求，就不必要去学那些东西
正如很多C码农，也不需要一上来就去学习汇编语言甚至cpu微码一样
强制去学，和出于自己的爱好去学，是两回事
【 在 ksxfhs 的大作中提到: 】
: 一个新手，如果一上来就学RAII或者其它语法，有啥机会练习自己管理内存，总不能自己写两行代码就算练习过吧，总得有一定规模的项目锻炼
: 然而很多人是没有这样的锻炼机会的，反正有现成的工具，领导也不答应，最后就是没实际锻炼机会，没有语法工具根本都不会写，谈何手撸，何谈管理
:
--
修改:z16166 FROM 222.130.136.*
FROM 222.130.136.*
再加一个，用C怎么实现OOP
【 在 iwantfly 的大作中提到: 】
: 想象一下c语言面试的题目
: 1. 怎样用c语言实现 RAII
: 2. 在c语言中使用early return的最佳实践方式
: ...................
--
FROM 222.130.136.*
c++委员会的需求就是B.S说的那两大原则：direct hardware mapping，zero-overhead abstraction。
一般还会加点其他东西，比如兼容老代码、尽可能simple。
Herb Sutter在下面这个视频里也有提到这些原则（第8页ppt）
CppCon 2018: Herb Sutter “Thoughts on a more powerful and simpler C++
https://www.youtube.com/watch?v=80BZxujhY38
【 在 ksxfhs 的大作中提到: 】
: 不否认又需求才有必要，但C++委员会的需求是啥？必要又是啥？
: 先得会底层原理，再用各种语法才有价值，但现在的C++，已经越来越偏了。只会各种稀奇古怪的语法，和高端开发，在某种程度上是背道而驰
: 语法上比java, c#还花，又有啥意义，大家要搞c++是因为语法很花吗？还不是看重底层效率，这才是着力点，结果搞了一套语法包装，让大家不用关心底层，这啥思路
: ...................
--
FROM 222.130.136.*
智能指针搞出奇怪的内存泄漏是指什么？循环引用？这个不是有拆为weak ptr的标准搞法吗？
lambda这个吐槽也有点奇怪。lambda大部分情况下就是要capture外部变量，capture成员变量有啥问题？改成capture this？这个完全可以通过编码规范搞定。
"大量新语法对大部分coder并没有带来生产力的提高，反而带来阅读和理解代码的难度"，这个恐怕也是自己臆想的吧，对我来说，auto、constexpr、ranged for等，都是好东西，既好用，又好读。难读的东西，是复杂的宏和模板元编程。
【 在 toutouqi 的大作中提到: 】
: 不能抓住一个你懂的点就无限放大。没有人否认cpp的每一个新语法都有其用武之地，熟练的cpper用应该没什么问题。但总还是不断有新人加入cpp队伍的，当新语法被不太熟悉cpp的cpper拿来用的时候，除了语法难看懂，各种bug也仍然不可避免。比如智能指针，仍然可以搞出奇怪的内存泄露，比如lambda函数，每个成员函数里给你搞一两个，形参和引用的成员变量混用，严重降低了函数代码的可读性和封装。大量新语法对大部分coder并没有带来生产力的提高，反而带来阅读和理解代码的难度，这才是大家吐槽的点。
--
修改:z16166 FROM 222.130.136.*
FROM 222.130.136.*