C++的坑真的多吗?

C++的坑真的多吗?

先说明一下,我不希望本文变成语言争论贴。希望下面的文章能让我们客观理性地了解C++这个语言。(另,我觉得技术争论不要停留在非黑即白的二元价值观上,这样争论无非就是比谁的嗓门大,比哪一方的观点强,毫无价值。我们应该多看看技术是怎么演进的,怎么取舍的。)

事由

周五的时候,我在我的微博上发了一个贴说了一下一个网友给我发来的C++程序的规范和内存管理写的不是很好(后来我删除了,因为当事人要求),我并非批判,只是想说明其实程序员是需要一些“疫苗”的,并以此想开一个“程序员疫苗的网站”,结果,@简悦云风同学直接回复到:“不要用 C++ 直接用 C , 就没那么多坑了。”就把这个事带入了语言之争。

我又发了一条微博

@左耳朵耗子 新浪个人认证 : 说C++比C的坑更多的人我可以理解,但理性地思考一下。C语言的坑也不少啊,如果说C语言有90个坑,那么C++就是100个坑(另,我看很多人都把C语言上的坑也归到了C++上来),但是C++你得到的东西更多,封装,多态,继承扩展,泛型编程,智能指针,……,你得到了500%东西,但却只多了10%的坑,多值啊

结果引来了更多的回复(只节选了一些言论):

  • @淘宝褚霸也在微博里说:“自从5年前果断扔掉C++,改用了ansi c后,我的生活质量大大提升,没有各种坑坑我。
  • @Laruence在其微博里说: “我确实用不到, C语言灵活运用struct, 可以很好的满足这些需求.//@左耳朵耗子: 封装,继承,多态,模板,智能指针,这也用不到?这也学院派?//@Laruence: 问题是, 这些东西我都用不到… C语言是工程师搞的, C++是学院派搞的

那么,C++的坑真的多么?我还请大家理性地思考一下

C++真的比C差吗?

我们先来看一个图——《各种程序员的嘴脏的对比》,从这个图上看,C程序员比C++的程序员在注释中使用fuck的字眼多一倍。这说明了什么?我个人觉得这说明C程序员没有C++程序员淡定

Google Code 中程序语言出现 fuck 一词的比率

不要太纠结上图,只是轻松一下,我没那么无聊,让我们来看点真正的论据。

相信用过C++的程序员知道,C++的很多特性主要就是解决C语言中的各种不完美和缺陷:(注:C89、C99中许多的改进正是从C++中所引进的

  • 用namespace解决了很C函数重名的问题。
  • 用const/inline/template代替了宏,解决了C语言中宏的各种坑。
  • 用const的类型解决了很多C语言中变量值莫名改变的问题。
  • 用引用代替指针,解决了C语言中指针的各种坑。这个在Java里得到彻底地体现。
  • 用强类型检查和四种转型,解决了C语言中乱转型的各种坑。
  • 用封装(构造,析构,拷贝构造,赋值重载)解决了C语言中各种复制一个结构体(struct)或是一个数据结构(link, hashtable, list, array等)中浅拷贝的内存问题的各种坑。
  • 用封装让你可以在成员变量加入getter/setter,而不会像C一样只有文件级的封装。
  • 用函数重载、函数默认参数,解决了C中扩展一个函数搞出来像func2()之类的ugly的东西。
  • 用继承多态和RTTI解决了C中乱转struct指针和使用函数指针的诸多让代码ugly的问题。
  • 用RAII,智能指针的方式,解决了C语言中因为出现需要释放资源的那些非常ugly的代码的问题。
  • 用OO和GP解决各种C语言中用函数指针,对指针乱转型,及一大砣if-else搞出来的ugly的泛型。
  • 用STL解决了C语言中算法和数据结构的N多种坑。
(注意:上面我没有提重载运算符和异常,前者写出来的代码并不易读和易维护(参看《恐怖的C++语言》后面的那个示例),坑也多,后者并不成熟(相对于Java的异常),但是我们需要知道try-catch这种方式比传统的不断地判断函数返回值和errno形成的大量的if-else在代码可读性上要好很多)

上述的这些东西填了不知有多少的C语言编程和维护的坑。少用指针,多用引用,试试autoptr,用用封装,继承,多态和函数重载…… 你面对的坑只会比C少,不会多。

C++的坑有多少?

C++的坑真的不多,如果你能花两到三周的时候读一下《Effecitve C++》里的那50多个条款,你就知道C++里的坑并不多,而且,有很多条款告诉我们C++是怎么解决C的坑的。然后,你可以读读《Exceptional C++》和《More Exceptional C++》,你可以了解一下C++各种问题的解决方法和一些常见的经典错误。

当然,C++在解决了很多C语的坑的同时,也因为OO和泛型又引入了一些坑。消一些,加一些,我个人感觉上总体上只比C多10%左右吧。但是你有了开发速度更快,代码更易读,更易维护的500%的利益。

另外,不可否认的是,C++中的代码出了错误,有时候很难搞,而且似乎用C++的人会觉得C++更容易出错?我觉得主要是下面几个原因:

  • C和C++都没学好,大多数人用C++写C,所以,C的坑和C++的坑合并了。
  • C++太灵活了,想怎么搞就怎么搞,所以,各种不经意地滥用和乱搞。

另外,C++的编译对标准C++的实现各异,支持地也千差万别,所以会有一些比较奇怪的问题,但是如果你一般用用C++的封装,继承,多态,以及namespace,const, refernece,  inline, templete, overloap, autoptr,还有一些OO 模式,并不会出现奇怪的问题。

而对于STL中的各种坑,我觉得是程序员们还对GP(泛型编程)理解得还不够,STL是泛型编程的顶级实践!属于是大师级的作品,一般人很难理解。必需承认STL写出来的代码和编译错误的确相当复杂晦涩,太难懂了。这也是C++的一个诟病。

这和Linus说的一样 —— “C++是一门很恐怖的语言,而比它更恐怖的是很多不合格的程序员在使用着它”。注意我飘红了“很多不合格的程序员”!

我觉得C++并不适合初级程序员使用,C++只适合高级程序员使用(参看《21天学好C++》和《C++学习自信心曲线》),正如《Why C++》中说的,C++适合那些对开发维护效率和系统性能同时关注的高级程序员使用。

这就好像飞机一样,开飞机很难,开飞机要注意的东西太多太多,对驾驶员的要求很高,但你不能说飞机这个工具很烂,开飞机的坑太多。(注:我这里并不是说C++是飞机,C是汽车,C++和C的差距,比飞机到汽车的差距少太多太多,这里主要是类比,我们对待C++语言的心态!)

C++的初衷

理解C++设计的最佳读本是《C++演化和设计》,在这本书中Stroustrup说了些事:

1)Stroustrup对C是非常欣赏,实际上早期C++许多的工作是对于C的强化和净化,并把完全兼容C作为强制性要求。C89、C99中许多的改进正是从C++中所引进。可见,Stroustrup对C语言的贡献非常之大。今天不管你对C++怎么看,C++的确扩展和进化了C,对C造成了深远的影响

2)Stroustrup对于C的抱怨主要来源于两个方面——在C++兼容C的过程中遇到了不少设计实现上的麻烦;以及守旧的K&R C程序员对Stroustrup的批评。很多人说C++的恶梦就是要去兼容于C,这并不无道理(Java就干的比C++彻底得多,但这并不是Stroustrup考虑的,Stroustrup一边在使尽浑身解数来兼容C,另一方面在拼命地优化C。

3)Stroustrup在书中直接说,C++最大的竞争对手正是C,他的目的就是——C能做到的,C++也必须做到,而且要做的更好。大家觉得是不是做到了?有多少做到了,有多少还没有做到?

4)对于同时关注的运行效率和开发效率的程序员,Stroustrup多次强调C++的目标是——“在保证效率与C语言相当的情况下,加强程序的组织性;能保证同样功能的程序,C++更短小”,这正是浅封装的核心思想。而不是过渡设计的OO。(参看:面向对象是个骗局

5)这本书中举了很多例子来回应那些批评C++有运行性能问题的人。C++在其第二个版本中,引入了虚函数机制,这是C++效率最大的瓶颈了,但我个人认为虚函数就是多了一次加法运算,但让我们的代码能有更好的组织,极大增加了程序的阅读和降底了维护成本。(注:Lippman的《深入探索C++对象模型》也说明了C++不比C的程序在运行性能低。Bruce的《Think in C++》也说C++和C的性能相差只有5%)

6)这本书中还讲了一些C++的痛苦的取舍,印象最深的就是多重继承,提出,拿掉,再被提出,反复很多次,大家在得与失中不断地辩论和取舍。这个过程让我最大的收获是——a) 对于任何一种设计都有好有坏,都只能偏重一方,b) 完全否定式的批评是不好的心态,好的心态应该是建设性地批评

我对C++的感情

我先说说我学C++的经历。

我毕业时,是直接从C跳过C++学Java的,但是学Java的时候,不知道为什么Java要设计成这样,只好回头看C++,结果学C++的时候又有很多不懂,又只得回头看C最后发现,C -> C++ -> Java的过程,就是C++填C的坑,Java填C++的坑的过程

注,下面这些东西可以看到Java在填C/C++坑:

  • Java彻底废弃了指针(指针这个东西,绝对让这个社会有几百亿的损失),使用引用。
  • Java用GC解决了C++的各种内存问题的诟病,当然也带来了GC的问题,不过功大于过。
  • Java对异常的支持比C++更严格,让编程更方便了。
  • Java没有像C++那样的template/macro/函数对象/操作符重载,泛型太晦涩,用OO更容易一些。
  • Java改进了C++的构造、析构、拷贝构造、赋值。
  • Java对完全抛弃了C/C++这种面向过程的编程方式,并废弃了多重继承,更OO(如:用接口来代替多重继承)
  • Java比较彻底地解决了C/C++自称多年的跨平台技术。
  • Java的反射机制把这个语言提升了一个高度,在这个上面可以构建各种高级用法。
  • C/C++没有一些比较好的类库,比如UI,线程 ,I/O,字符串处理等。(C++0x补充了一些)
  • 等等……

当然时代还在前进,这个演变的过程还在C#和Go上体现着。不过我学习了C -> C++  -> Java这个填坑演进的过程,让我明白了很多东西:

  • 我明白了OO是怎么一回事,重要的是明白了OO的封装,继承,和多态是怎么实现的。(参看我以前写过的《C++虚函数表解析》和《C++对象内存布局》)
  • 我明白了STL的泛型编程和Java的各种花哨的技术是怎么一回事,以及那些很花哨的编程方法和技术。
  • 我明白了C,C++,Java的各中坑,这就好像玩火一样,我知道怎么玩火不会烧身了。

我从这个学习过程中得到的最大的收获不是语言本身,而是各式各样的编程技术和方法,和技术的演进的过程,这比语言本身更重要在这个角度上学习,你看到的不是一个又一个的坑,你看到的是——各式各样让你可以爬得更高的梯子

我对C++的感情有三个过程:先是喜欢地要死,然后是恨地要死,现在的又爱又恨,爱的是这个语言,恨的是很多不合格的人在滥用和凌辱它。

C++的未来

C++语言发展大概可以分为三个阶段(摘自Wikipedia):

  • 第一阶段从80年代到1995年。这一阶段C++语言基本上是传统类型上的面向对象语言,并且凭借著接近C语言的效率,在工业界使用的开发语言中占据了相当大份额;
  • 第二阶段从1995年到2000年,这一阶段由于标准模板库(STL)和后来的Boost等程式库的出现,泛型程式设计在C++中占据了越来越多的比重性。当然,同时由于Java、C#等语言的出现和硬件价格的大规模下降,C++受到了一定的冲击;
  • 第三阶段从2000年至今,由于以Loki、MPL等程式库为代表的产生式编程和模板元编程的出现,C++出现了发展历史上又一个新的高峰,这些新技术的出现以及和原有技术的融合,使C++已经成为当今主流程式设计语言中最复杂的一员。

在《Why C++? 王者归来》中说了 ,性能主要就是要省电,省电就是省钱,在数据中心还不明显,在手机上就更明显了,这就是为什么Android 支持C++的原因。所以,在NB的电池或是能源出现之前,如果你需要注重程序的运行性能和开发效率,并更关注程序的运性能,那么,应该首选 C++。这就是iOS开发也支持C++的原因。

今天的C++11中不但有更多更不错的东西,而且,还填了更多原来C++的坑。(参看:C++11 WikiC++ 11的主要特性

 

总结

  • C++并不完美,但学C++必然让你受益无穷。
  • 是那些不合格的、想对编程速成的程序员让C++变得坑多。

最后,非常感谢能和“@简悦云风”,“@淘宝诸霸”,“@Laruence”一起讨论这个问题!无论你们的观点怎么样,我都和你们“在一起”,嘿嘿嘿……

(全文完)


关注CoolShell微信公众账号和微信小程序

(转载本站文章请注明作者和出处 酷 壳 – CoolShell ,请勿用于任何商业用途)

——=== 访问 酷壳404页面 寻找遗失儿童。 ===——
好烂啊有点差凑合看看还不错很精彩 (40 人打了分,平均分: 4.65 )
Loading...

C++的坑真的多吗?》的相关评论

  1. 一名马上大三的学生,C学的不好,学过一些C#,OO,大二下学期学了《数据结构》(C++实现),算是了解了些C++的东西。
    马上要开始学C++(也许你很惊讶为什么没学C++直接学C++版的《数据结构》),我们学校就这么安排了,哈哈,看到这篇博文有些益处,谢谢博主!博主很幽默。
    关于这门语言,真的觉得指针很难懂,但有时很方便,就又不得不学习。但有时又不怎么想用它,可能学过C#的原因更喜欢引用。
    另外祝福你们:在一起.

  2. 文章说得很中肯,特别赞成:C和C++都没学好,大多数人用C++写C,所以,C的坑和C++的坑合并了。平时就见到很多用C++写C的,比如字符串查找,构造std::string对象后,不用string的find方法,而是用strstr(str.c_str(), “xxx”),声明了类,却完全用面向过程的编程方法来写程序;等等等…

  3. 嗯嗯,说的很对,最近重头开始看C++,发现自己的确是一个很不及格的C++开发者,现在在按照阁下的练级宝典在一步一步的重新审视C++,很有收获~

  4. 看到最后在一起,我瞬间就乐了,我现在准备找时间去学一下c++,不知道陈老师有没有好的书介绍呢?(ps:我是学c到java的,java刚学了2年),我想拓宽一下自己的知识面,开扩下自己的眼界!

  5. 用C++的理论知识武装头脑,然后用C实现。(前提是有充足的时间和精益求精的态度)

  6. C++不应该得到赞美,因为它没有完成的它的历史定位。
    面向对象+组件平台,都完成的一塌糊涂。而需要Java,.Net这类货色充当历史舞台。
    而面对性能问题,又会回来到C上来解决。
    C的问题很明显,但这么多年来还不能退休就是因为C++不能接班。
    所以你们不觉得这个情况很尴尬吗?

    1. 是这个道理,历史给了她机遇,单考虑的太多,左右环顾,什么都想要。导致没有了现在的尴尬。

  7. 自学C++一年多了,一直想找一份C++的工作,但总是觉得自己能力不够,Effective C++这本书至少看了3偏了,C++真的这么难吗,

  8. 其实很简单,就是在要求运行效率且能对业务很好抽象的环境下使用
    C++是一门专家语言
    C++难的原因是没有用心去学习,仅此而已

  9. 说起来C++填C的坑,有些地方,额,其实我不是很认同,比如对函数指针的看法。另外对STL和Boost在实际使用中也是有各种坑的

  10. C++坑大了
    #########

    我生活中主要用Python,C++作为第二语言,用在性能瓶颈上。但我觉得 C++ 坑很大,标
    准委员会过于学术化,而且效率低下,,N年才出一部标准,同时期Python已经更新换代
    得面目全非。甚至有《Imperfect C++》这么厚厚一本书专门抱怨C++的不足。

    最大的问题就是实在过于复杂,而且很多时候没法避免复杂性。这个帖子我超同意:
    http://coolshell.cn/articles/7771.html

    没有反射
    ========

    很多真正有用的东西却没有,比如反射。当新手发现检查一个类型是否有 swap(T&a) 成
    员函数,以便针对特定类型使用高效的交换操作,却需要使用SFINAE这种看上去跟需求豪
    不搭杆的技术,不傻眼才怪。而Python只需要hasattr(T, “swap”)即可。

    http://stackoverflow.com/questions/87372/is-there-a-technique-in-c-to-know-if-a-class-has-a-member-function-of-a-given

    代码噪音多
    ==========

    代码胜过千言万语,C++11中写一个泛型的min函数都不简单::

    #include

    template
    auto min(T x, U y)
    -> typename std::remove_reference< decltype(x ::type
    { return x < y ? x : y; }

    而相比之下,Python中只需要::

    def min(x, y):
    return x if x < y else y

    实际上C++完全可以设计成::

    []min(x, y) { return x < y ? x : y }

    别问为什么不用宏。这里有详细讨论,解释了为什么要像上面那么写::

    http://cpp-next.com/archive/2011/11/having-it-all-pythy-syntax/

    模板编程语法奇特
    ================

    为了实现某些静态特性,函数式编程显得过于奇特。引入D语言的 "static if" 会好很多。

    出错信息
    ========

    C++ 拥有令人发疯的出错信息,就像一只猫刚爬过键盘一样,因此还诞生了很多 Error
    messages pettyprint 工具。现在 Concept 也被否决,看来 C++ 标准委员会认为这不是
    个大问题。对于经验丰富的程序员来说也许不是,因为他们已经习惯读天书了,但是如果
    新手程序员尝试对一个 list 容器使用 std::sort ,肯定会被吓坏。

    不使用设计良好的Loki::SmartPtr作为标准智能指针类型
    ==================================================

    个人觉得Loki::SmartPtr比boost的智能指针设计要好,可是C++标准委员会却用劣币驱逐
    良币。

    STL
    ===

    我承认自己是一个STL Hater,这玩意儿坑太多,比如"vector, auto_ptr, etc”
    说一些不那么常见的坑:

    string 的 API
    ————-

    std::string API及其丑陋,成员函数太多。其实可以借鉴D语言的一个特性:
    如果“d.function(argv)“编译不通过,就尝试“function(d, argv)“。
    这样就解决了语法一致与封装的问题。

    接口不一致
    ———-

    算法与容器松散固然是好事,但有时我也奇怪,为什么不能写 sort(sth) 而必须用
    sort(sth.begin(), sth.end()) 或者 sort(sth, sth + sizeof(sth)/sizeof(sth[0]))
    虽然一个简单的函数重载就可以办到。而且有 list::sort 却没有 vector::sort 或者
    deque::sort ,使得代码重构时,把 list 换成 vector 有可能要在天书一般的编译错误
    中寻找问题。

    你可以找得到 count 和 count_if, remove 和 remove_if, replace 和 replace_if, 等
    等。但是却只有 copy 而没有 copy_if,难道STL的发明者害怕他们带来的惊奇还不够么?

    list, deque 都有 push_front 成员,vector 却没有。也许有人会说,vector 没法实现
    push_front,可是真的没法实现吗?实际上 push_front(v) 可以用 insert(begin(), v)
    实现。正确的说应该是不能在常数时间复杂度实现,可是这并不能成为不提供 push_front
    的理由。也许 C++ 标准委员会认为提供 push_front 可能在复杂度上起到迷惑人的作用,
    毕竟其他容器的 push_front 和 push_back 都是常数时间,毕竟真要 push_front 用
    insert 代替的话不容易令人误解。所以决定选择复杂度一致而不是接口一致。不过这仍然
    存在某种程度上的不一致,参见下一条。

    时间复杂度不一致
    —————-

    大家都知道在 STL 中 vector、string、deque、map 的成员函数 size 是常数时间复杂度
    的,可 list 的 size 却是线性复杂度 (至少 SGI STL 和 libstdc++ 是这种实现)。不过
    这也是没办法,要不然 splice 没法做到常数复杂度的。在这里 C++ 标准却又选择接口一
    致而不是复杂度一致。而且我觉得 list 提供一个 size 也没必要,毕竟 size() 可以用
    distance(begin(), end()) 代替,而且事实上也有不少标准库的实现是这样做的, list
    也不能用索引,size 操作的意义不大。

    容器没有公共基类,而且不能用来继承
    ———————————-

    当然,为了可能根本用不上的功能,而添加虚拟函数,对于性能狂 STL 来说其抽象惩罚是
    不可接受,尽管其他语言都无此顾虑。但事实上,可以设计出一个能够给用户一个选择,
    让他们自由决定是否使用公共基类和虚拟继承的容器,以便既满足对性能要求苛刻的用户
    的需求,又满足普通用户的需求。实现方法可参考《C++ Templates: The Complete Guide》
    Section 16.4. Parameterized Virtuality。

    结语
    ====

    其实我个人觉得D语言本身好过C++语言,这东西可是Andrei Alexandrescu 设计的。可惜这个
    世界上大多数代码和库基础都是建立在C++上。

    不能说只有专家才能用好C++,更准确的应该是C++常常把简单问题复杂化。C++标准委员
    会真应该从 Java, Python, C#, D 引用一些特性。

  11. fun2()函数和类型转换之类问题个人觉得应该是程序员态度或者水平问题,与C语法无关的

  12. 1) C++拥有指针算术, 就不可能有Java式引用. C++的引用只是指针算术的语法糖而已; 我觉得在C++里统一用指针没什么不好, 因为引用在功能上不足: 没有NULL…
    2) C++的编译速度…OMG…只要处理好include应该就能减少很多编译时间, 但是C包袱使得它不能;
    3) C++的异常机制太失败了…关键是有些地方它还倡导抛异常的, 比如构造函数失败了: 这导致我只能用普通函数来构造一个对象并返回指针(Oh泄漏了…好吧, 智能指针), 失败则返回NULL. // 我肯定是个不合格的C++程序员; 有没有更好的方法?
    4) 用C++当然是好的, 它能把程序员磨练得更强大:)(当然, 我不是程序员…)

  13. 从一个初学者的角度看,C++有些反人类,比如static 成员变量必须在类体外定义一次。//昨天还为了这个去查了primer OTZ…

  14. @kamushin
    如果不在类外面定义一次, 那要在哪初始化? 类定义不负责初始化. // 其实C++的初始化机制不健全…
    就好像C中一个变量在某个地方初始化一次, 别的地方extern一样. 在类中的static只能算一个声明.

  15. 想问下,关于C语言做大型程序的时候,架构是怎么设计的?怎么保证不会产生太多的全局变量导致难以追踪的问题?

  16. C++与C的性能之争应该早已经没有争论。因为性能从C++转向C的应该寥寥无几。
    再看C++与C的不同,自然就是范式的不同。
    我们都知道C++是范式的联邦,你可以选择其一任你使用。
    代价呢?
    个人认为代价就是你需要学习整个联邦,多种范式融合在一门语言里,必然存在某种程度上的耦合,单纯的学习某种范式并使用在C++中是困难的或者说不可能的。
    这就是学习成本。
    在付出了高额的学习成本之后,你得到了什么优势?一门相比较与C而言或许更适合构建大型项目,百万行级代码项目的语言。
    但现实是你并不总是在构建这样的项目,甚至你可能从未去构建这样的项目也不打算构建这样的项目,更不用说linus早已经用实际行动证明了C也可以完成百万行级代码的项目并且项目的整体架构非常优秀,那么现在C++的优势又在哪里。

    C++当然是一个优秀的语言,只是它适合不适合你?又或是像云风所说,你是不是在以正确的方法是用它?我想这才是每一个programer自己应该与自己争论的。而不是单纯的语言之争。

  17. 实事求是的说,汇编语言的坑最少。基本上你把内存和寄存器操作正确了,机器就会忠实执行你的程序。

  18. @test
    哎,我只能说兄弟啊,这年头写文章,不咬文嚼字,别人随便找一个字眼就被喷死了。很多总是喜欢以点盖面,抓住一个死角不妨,然手死扣。

  19. 不知道一个团队在搞技术选型的时候,是否要考虑只在国内能招到多少高水平的高级C++程序员,还要让他们统一在一个精心选择的C++子集中工作,而不是由着性子和喜好来随意折腾。
    另,不能过分关注于单个程序员是否踩中了坑,而要考察团队中各个成员踩中坑的机率,中坑对团队协作效率的影响,以及对项目进度的拖累。

    C++可供选择的特性太多,很通用,但未必是银弹。

  20. …而不是过渡设计的OO… //貌似有笔误(过度设计)
    各有各的用武之地,不过C++必学,学习C++可以了解程序语言的设计和实现

  21. 如果 C/C++ 是你的左右手,思维的延伸,C++ blah blah 几乎不会出现。因为当我要用某个特性的时候,就会用,当我不用的时候,我就不用。当发现有错误的时候,就知道是什么引起的,那还有什么问题呢?
    很多时候,语言之争,几乎已经上升到信仰状态。这是很没有必要的。不管是不是所谓的大牛,这种争论适可而止,多了,就是 EQ 有问题。

  22. 以前面试过一个 C 语言的人,水平不好,然而代码很好看,不仔细看内容真以为是有水平,再问下去就知道这人已经被某位国内的 C 拥趸偏执狂洗脑了,直接 ban 掉。
    其实都一样,不合格的 C 程序员的代码隐藏的更深,一大堆 struct ,memcpy 看起来很牛叉的样子,仔细看内容却毫无意义,这样的人在团队里面就是定时炸弹。
    我们要做的是项目,而不是研究登月飞船,实用才是硬道理。

  23. 印象最深的是这句话:“我对C++的感情有三个过程:先是喜欢地要死,然后是恨地要死,现在的又爱又恨,爱的是这个语言,恨的是很多不合格的人在滥用和凌辱它。”首先我想说,这个不是又爱又恨,而是比第一层次更爱了,恨得只是人。

    其次我想说,现在耗子哥对C++的状态也是我对“语言争论”的感觉。

  24. 老赵 :
    印象最深的是这句话:“我对C++的感情有三个过程:先是喜欢地要死,然后是恨地要死,现在的又爱又恨,爱的是这个语言,恨的是很多不合格的人在滥用和凌辱它。”首先我想说,这个不是又爱又恨,而是比第一层次更爱了,恨得只是人。
    其次我想说,现在耗子哥对C++的状态也是我对“语言争论”的感觉。

  25. 写的不错,尺有所长,寸有所短

    评价任何东西的时候都应该辩证的看待,别一棒子敲死

  26. 作者应该没意识到,说了那么多,其实是在说c++很难掌握,只有很少的人能掌握好,运用好。

    最后两条总结实在太牵强了,第一条虚的不行,基本上可以用在任何一个语言上,第二条其实就是上面意思(很少人能学好用好)的另一种说法。
    感觉是越辩解越无力。
    我想只有出现简洁的解决方案(学用的门槛大大降低),才会是最有力的辩解。否则堆砌再多的词句理由,不解决问题终究是没用。

  27. 应该综合项目难度来看:对于一个语言
    程序员有3级:新手,老手,高手(牛人就不参与评级了)
    对于项目应用,难度也分:普通,中等,复杂

    看看各种组合的结果,就知道一个语言的真正好坏了

发表评论

电子邮件地址不会被公开。 必填项已用*标注