恰恰相反，新的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.*

本身会配套一些相关要求，并不会产生嵌套层次的问题。有一个好处是，对于行数多的代码，随时可以轻松拆分。很容易的保持函数在一屏之内。
严苛的要求本身就容易受到诸多抵制，我也是少数遵守的比较好的。

【 在 iwantfly 的大作中提到: 】
: 最后统一返回的代码， 就是垃圾代码
: 无数的嵌套层次，莫名的逻辑
:
--
修改:brucewww FROM 103.10.85.*
FROM 103.10.85.*

自己写释放代码才是内存管理的精华

C++搞了一堆复杂的语法只是解决一个很简单的问题，满足低级程序员不出错的需要

或者搞出新语法只是为了省了两行代码，但实际运行效率一秒都不少，编译出来的东西又大又慢

更不说很多新语法是省了代码，可大大增加了调试复杂度，这是省吗？

这都是低级程序员的标配思路，C++早死早超生

【 在 z16166 的大作中提到: 】
: 恰恰相反，新的C++远比C好用
: 单纯一个RAII机制，就足以让我抛弃C了，想象一下C得在函数里的每个early return之前都要加一句资源释放语句的那种情况，既属于凑代码行数，还是error-prone的，以至于要发展出goto、do...while(0)、__try/__finally等蹩脚的“技法”来规避这种问题。
: 而ranged for语句，就是用来规避C里面手撸loop条件容易出现边界错误的
: ...................
--
FROM 222.70.129.*

有道理说出来，比如C++就是运行效率高，就是好调试，这才是打脸。。。。。不然。。。。。

【 在 iwantfly 的大作中提到: 】
: 这是哪的大神，快看纯c大神跳出来喷c++了
:
--
FROM 222.70.129.*