浅薄和偏见 驳“C语言已死了”

　　现在，有很多C/C 程式员总是自命不凡，看不起其他研发人员。其实，或许别人更看不起他呢!

　　>> 有偏见的永远只是个体，而不是群体。作者加了后面那句，无疑证实有偏见的不是C/C 程式员，而正是他自己。

　　学生时代，我也曾醉心于C/C ，但时至今日，始终无法写出无懈可击的C 代码，所以我始终认为我不会C/C 。这些年，我一直在寻找编写C 代码的最好模式。但是，老实说，我还没有见到过哪个称得上高手的C 程式员，也没有见到过写得Very good的C/C 代码。C/C 代码总是丑陋不堪，BUG丛生!

　　>> 这段话更加荒谬了。没见过优秀的C/C 代码? C 标准库(STL)如此优雅。况且，有那么多经典的C/C 开源作品，连同无意之中泄漏的Windows NT核心源码，哪相同不是绝世之作?我为作者浅陋感到难过。

　　我用C语言编程已超过20年了。我写过C语言的编译器、C语言的调试器、用C研发的其他语言、游戏、客户端程式和服务器程式，您说吧!更有什么是我没写过的。更有我的书架上充斥着折了角的K&R和Steele的书。我太了解C语言了，但是，我讨厌他。十分讨厌!

　　当我读到一篇博客，题目是"为什么每个程式员都应该学习C语言?"时，我真是鸡皮疙瘩满地。假如您真的是个专业的程式员的话，您肯定觉得这是个天大的笑话，尽管作者的本意也许不是这样的。这篇反驳的文章有点意思，但是还是没有抓住本质。所以我展开了说一下。有以下5个原因来说明，为什么那些会C语言，并且使用C语言的程式员，现在不但应该去用别的语言，而且应该忘记他们学习C语言过程中的那些烦人的东西。

　　1、内存分配

　　仅仅关于这一点我就能写整整一篇文章了，也许能写一本书，甚至更有可能写出能够塞满图书馆技术书籍那块，那么多的内容。内存分配和存储单元分配的存在确确实实是个大麻烦。您要不就是分配太少的内存不够用，要不就是分配了太多内存浪费掉。这里的问题就是：怎么把他初始化为零呢?还是干脆就不初始化他。但最挠头的步骤还是释放内存。任何已有的工具包都会帮助您确认，您是否已释放了之前分配的每一位的内存，在释放完之后是否永远不使用他，并且会阻止您，永远不要释放他第两次。更严重的是，分配内存和释放内存在C语言中都是很慢的，很慢。使用内存分配时，要考虑的各种特别情况，我真是连想都不愿意去想，只要问题(对象)的大小合适，我更愿意使用栈空间或事先分配的结构空间。假如这么做的话，我就有更值得烦恼的事了。话说回来，发明垃圾处理器那人真应该得诺贝尔奖。

　　>> 内存管理是程式设计中最经典的话题。GC无疑是内存管理一个伟大的变革，但是我只是把他看作内存管理的一个解决方案，而认为不是唯一的解决方案。比GC更加优雅的方案不见得没有。我比较倾向于在特定的情况下选择合适的内存管理方案，而不是没有任何选择的余地，而这正是C/C 的伟大之处。 任何那些GC语言(如Java、C#等)均把这个解决方案强加给程式员，这一定程度上来说减轻了程式员的负担，但是也同时约束了程式员的主观能动性。"分配内存和释放内存在C语言中都是很慢的"?不知道作者从哪里获得的结论。

　　2、多线程

　　我过去是喜欢C语言的，真的。直到我开始用C研发并维护多线程的服务器。在为连接相冲突的线程保护数据方面，C语言没有为程式员提供那怕一点点的帮助。您在使用单线程的日子里获得的每一个直觉、经验，用在多线程的时候都是错误的。至少JAVA有表示同步的关键字和备有证实文档(但是是个很奇怪的文档)的记忆体，但即使是这样，除非您使用新的javax.concurrent，否则也只能在那些巨大的平行摆放的机器们面前崩溃。回到C语言上：在模拟生产的环境下，坚持一个星期在数据中央调试一个死锁(这事真的发生过)。而Java却只需要Ctrl Break!天哪!!!

　　>> C/C 语言本身确实没有太多MultiThead的支持，这种情况在C 0x出来后可望改变。但是，请记住C/C 永远倾向于您使用成熟的库来解决问题。

　　3、指针

　　指针太难以控制了，太阴险了;我甚至没有委婉一点的方式去形容他。我生命中每年都有几个月被用来调试那些奇怪的指针问题。我过去常常努力获取任何的诀窍，比方说难以理解的构成符、联合体和偏移量，连同重用最后两位做标记，更有任何其他的诀窍。但我发现这么做根本不值得。其他语言的静态引用就能够解决了。

　　>> 指针是C/C 过于灵活的体现。使用指针的代码能够写得很丑陋，但相同能够很优雅。——这一点上用何种语言不会有区别。我相信，能够写出优雅的Java代码，那么也一定能够写出同样优雅的C/C 代码。而反之则未必(因为有些C 某些范式是Java所不能支持的)。C/C 语言中的选择太多，这的确是令人困惑的，但不见得是劣势。我对C/C 程式员的建议是，多了解和使用C 标准库，而不是过于纠缠指针相关的细节。

　　4、过早的优化

　　说到诀窍，您是否曾浪费脑细胞去研究究竟*p 是不是比p[i]快?您是否曾花时间去试着做点变化来代替乘法，或去尝试使循环中的倒置运行更快的方法?还在为传递一个参数的速度和反对添加结构，并且传递他的速度相同而苦恼不已?停吧!算法是速度的关键，程式员的水平决定了他会使用那些算法。知道这一点能让您的程式更好，更快一点并且让您的脑袋少扭几个筋。好吧，有一些例子也许能够这样做的……不，您就别那么做就行了!

　　>> 算法优化是程式设计的关键。但是通常情况下，任何语言(包括C/C )的程式员研究的是关键路径的优化。研究*p 是不是比p[i]快?我相信这是标准库的实现者要考虑的事情。所不同的是，C/C 程式员也能够和标准库的作者相同去考虑这些细节，而其他语言的程式员被剥夺了这个权利。

　　说到优化，话题就多了。我曾向C#的Dictionary中插入了1亿条整数(从1万多个文本文档中读入)，结果发现程式运行了整整一个下午仍然没有完成。而我改用C 的std::map，20分钟就搞定了。再试试对50万条自定义的结构体数据进行排序，我相信您和我相同，会深深喜欢上C 的的高效而优雅。

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有