« 脏矩形演示 demo | 返回首页 | opera fans »

C 有 C 的规则

最近在用 C 写程序,规模不小的程序,也谈不上太大。大约一万行之内的模块吧,关于 UI 的基础框架。我知道这个东西连用 C++ 都谈不上合适,更莫谈 C 了。可是我倔强的认为,应该用 C 把它写好。

很多人批评 C++ 没有拥有好的教育体系和方式,导致了很多 C++ 程序员在用 C 的方式写 C++ ,或是把 C++ 当成更好的 C 来用。可是受过 C++ (正确的?)教育熏陶过的程序员呢,当他拿起 C 的时候,是否把 C 当成蹩脚的 C++ 来用呢?

我希望我不是。

了解了更多的语言后,我深信,每种语言有它的游戏规则。C 有 C 的规则,C++ 有 C++ 的规则。用的越深入,越发觉得其间的差别。C++ 不是 C ,C 也不是 C++ 。它们的最大的共通点,是类似的语法,语法类似到可以用一套编译器编译。

C 没有构造函数,没有析构函数。没有虚表,没有继承。const 的使用不那么严格,强制转换不那么忌讳。没有模板,宏是强有力的工具。简单而统一的 ABI ,冗长但是有效的命名规则。

C99 以前,我们甚至不可以任意声名一个变量,这估计是最让 C++ 程序员讨厌的地方,直接违反了设计原则,但同时也让 C 程序员保持了良好且统一的风格:不会让一个函数过长,也会把函数内的模块分开,即使用蹩脚的 do {} while(0);

我曾经认为 C 在某方面比 C++ (运行时)低效,但是长时间用下来,发现正是这些“低效”,让我更小心的使用它,设计更合理的结构。

C 的潜规则里,所有数据结构的最佳默认值是 0 ,这样可以方便的使用 calloc 或者 memset 。数据结构最好是 POD ,最好减少指针的滥用,内存如果可以连续的排放在一起,那么就不惜用一些在 C++ 中看似很糟糕的方案,但这样可以方便的 free ,而且不会忘记析构。

C 做成框架中,最好减少暴露的接口,和 C++ 不同,C++ 可以一组组接口的暴露,而 C 一次只是一个 api ,这成就了无数优秀的 C 库,比 C++ 类库的使用更加便捷。但是也无形提高了设计的难度,只是 C 标准库中,就有那么些不合理的接口设计。

一不小心,我们就会用 C 把整个项目写的很糟糕,但是 C++ 不会,糟糕的项目构架很晚才会发现。而 C ,如果你设计的好,感觉就会很好,稍有不适,就需要重构了。用 C 做项目,如履薄冰。

C 就是那么一如既往的简单,简单的可爱又可恨。我用五年时间,感觉自己学会了 C++ 。但是十五年了,仍旧问自己到底可以用 C 完成多大的项目。

Comments

D语言注定是昙花一现,最多就是第2个delphi 它只是个私人物品,甚至还不如c++面子大 很多人就是不开窍 思想可以无限开放 但是既成事实使你不得不低头 即使你思想先进好几倍都得承认现实
C 做成框架中,最好减少暴露的接口. 说得好,深有感触。
随便举个例子, strtok . 我不想多举了,其实很多的。
"只是 C 标准库中,就有那么些不合理的接口设计" 为什么? 能否举个不合理的设计例子?
云风对UI不是一般的重视,这点我在>就已经发觉了,书中有数处提到了UI。真可谓内行看门道,很多作游戏的不愿意作UI,可能他们认为UI是小case吧. 难得云风对ui模块有客观的评价,呵呵.
程序员,为什么要分C程序员,C++程序员呢?在需要的地方使用合适的解决方案。
C++完成的项目的规模应该是远远小于C完成的项目规模吧,从操作系统到嵌入式应用
恩 如果C++本来叫D 就不会有很将其和C混为一谈了。
QiaoJie,我的观点可能就是你说的C++的“集成性”的问题,虽然说并不是和“移植性和复用性”是同一个概念,但是之间还是紧密相关的。就说“复用性”吧,在 BCB 里使用一个 VC 编写的二进制模块我想不能否认为一个非常基本的复用的应用(这里就不谈源代码级的复用了,没有意义不是吗)。我之前的一个项目中就是用 VC6 做的核心,用 BCB 做的 UI ,那时候还没有用.net,否则我也不会这么抱怨。 另外你说的遵守规范的问题,也是挺可笑的一件事情:COM? 跨平台就不行啦;暴露一组抽象接口?最终总是要一个C的接口来创建对象取得接口吧?;至于说 C 需要暴露一组函数的问题,那本身就是挺漂亮的:)如果你不喜欢,大可用一个函数来创建一个填满了函数指针的struct :P 其实这个话题好无趣…………
C++ 的 ABI 貌似有历史原因和商业利益的驱使于是变得无法统一. C 就不一样了, 那应该是历史原因. 说 C++ 拘泥于编译器以及库的约束, 那是没有办法的事, 不得不说是悲哀. 还是那句话, 能解决问题才是正道. 其他都是浮云.
其实你主要是想说C++的集成性不好,但这个和移植性和复用性是不一样的概念。确实,C++特性复杂,不要说跨语言集成就是不同编译器之间集成都存在问题。但是如果你对接口做一些限制,遵守一些规范(比如COM规范),那么C++也可以达成很好的集成性,不管怎么说,用C++暴露一组抽象接口比用C暴露一组函数在写法上和语义上要漂亮一些。
跨平台的移植当然只能基于源码(大部分情况,不排除一些二进制跨平台的应用,哦,我们现在项目就在搞这个)。但是在同一个平台上不基于源码的应用应该还是有很多的。C 不会限定说必须使用何种编译器,何种编译平台编译环境;但是 C++ 很多时候 就需要这么做。在这个不是人人都愿意开放源码的时代,哪个方式能够使发布更加简单?经常遇到一个令人发寒的事情就是:一个 C++ 的库,注明要配合使用哪个版本的 STL 才可以,不觉得很讽刺吗?另外,跨语言的移植也是同样的,C 库能够方便的暴露给 VB 用, C++ 呢? “设计模式是以面向对象程序语言为基础的OO设计模式”,这同样不是“C++的设计模式”。不过对设计模式的应用来看,天生对 OO 支持的语言的确更显方便和顺手。
这么长的评论...-__-! 也许C->C++是个错误 也许C->D才是正道... http://www.digitalmars.com/d/
设计模式是以面向对象程序语言为基础的OO设计模式,而不是以C为基础的设计模式。 ABI问题是二进制级别的复用,而说到移植的话不在源代码级别上移植恐怕是做不到的吧?移植跟ABI没多大关系吧?历史上好像有不少著名的跨平台C++类库吧?你说移植性比C差在哪里了呢? myan说:成为好的C程序员比成为好的C++程序员更难。这句话应该这样解读,用C比用C++需要付出更多的脑力负荷才能写好程序。如果你想证明自己的技术比别人强那么就用C,如果你想更快更好的完成程序,那么用C++会更简单轻松一点。
C++从C发展而来,使用C++ 8年,从当初的执迷到近几年的一些重大转变.发现了很多的东西. stroustrup 说 "learning c++ as an new language", 但是我现在认为,如果要写出更漂亮的C++代码还是需要较强的C功底,从最底层看C++的语法糖是如何将C包裹起来的.理解了C++的机理后更能写出漂亮的代码. 目前认为最好的设计语言就是C with class 这种简单语法糖包裹的C++是最棒的. C有C的简单,C++有C++的易于表达,但是最终,程序员的职责就是解决问题.
谁说GOF设计模式作者会吐血?奇怪了,设计模式与 C++ \ C 有何相干? 另外,C++难移植难道没有体会吗?BCB\VC 你是如何协同工作的? 两个版本的 STL 你如何同时使用?该死的 ABI 搅得人心烦意乱,你手足无措的时候索性就用 extern "C" ,终于一了百了。
我现在的感觉跟myan差不多,感觉自己使用C++虽有2y,但是在几个C的老手面前,自己还很嫩。 编程素养不仅仅是语言把握能力而以,在见识过的人中用C++作设计的个个是态度严谨,能规划好整个项目的牛人。
C++比C难移植?此话从何讲起? C++比C难复用?GOF设计模式的作者看到这话估计会吐血。
我个人觉得用汇编做比不好。 汇编很难移植,但是 C 很容易移植。而 C++ 却又变的移植困难。 从复用性讲也是如此。 我把 C C++ 看成是跟汇编不同层次的语言。但是我不把 C 和 C++ 看成两个层次的语言。
对,成为一个好的c程序员比成为一个好的c++程序员难 就像成为一个只用汇编语言就可以写windows操作系统的程序员肯定比成为用c写出来那个难 当然键盘上只有0和1的程序员用机器码写一个网络游戏,更需要心思慎密,如履薄冰....
参合一下: 成为一个程序员,不论C还是C++抑或Java程序员并不难。或许一年、两年、三年也就可以了,至少做为一个CODER不难。 语言终究没有错,也不难,难的,是语言所体现的内在思维、思考。 程序员并不固限于语言。 难的是,不固于语言;难的是,好的解决;难的是,简单轻松。
用C也可以做好UI,WINDOWS的UI部分也是C风格的API,现在外面有一些不错的网络游戏都是用C开发的,比如石器时代,RO等。只要架构设计合理,程序员遵守一定的约束,C可以干任何事情,也可以做出大规模的系统,比如LINUX。。。
说到“C的表现能力也不见得差”,我觉得那是你的表现能力,不是C的。C和汇编这样直接表现计算机结构的语言,更多的需要程序员本身的能力来完成的待解决问题的抽象,语言层面提供的支持太少了。 而对于“陷阱和缺陷”,C++确实比C要来得更多,如果坚持用ANSI C的正统语法和风格的话,C还是很淳朴的语言。而C++就有些过于卖弄,就像身处繁华都市更多的需要个人的自持一样,C++需要程序员有清醒的头脑。从这一点出发,我也更喜欢用C。
一楼真有趣~
C抽象机制比较有限,所以不得不用简朴的手段、花费比较多的代码量来实现一些抽象。而熟练的C语言程序员通常会使用宏技巧来减少代码输入。结果就是,很多“高水平”的C程序,实际上是被宏改造以后的另一种语言。 此外,要使用C写出高质量的代码相当困难,理论上每一个syscall都需要检查返回值,errno,做相应的错误处理,将已经分配的资源注销。有多少人真正踏踏实实地把这样的代码写出来呢? 且不提算法问题,且不提个人能力问题,单说编写高质量的C语言代码,就不容易做到。 相比之下,如果你懂得谨慎地使用,别乱用模板、多继承等自己也控制不了的东西,那么写好C++代码确实是简单得多。了。
我现在倒不觉得 C 语言的"陷阱和缺陷" 会比 C++ 来的多。只不过 C 语言有的是看的见的陷阱,而 C++ 却是看不见的陷阱。 C 语言的表现能力也不见得差,只是没有 C++ 那样,用更多的复杂的语法糖来引导程序员思考。 我更愿意这样说,学会 C 比学会 C++ 更难。我们知道,学会一门计算机语言,并非学会其语法,而是要学会用它来解决问题。 而只有真正学会了 C ,才能说是一个好的 C 程序员。
个人认为用C设计接口不会比C++困难,一个C++的抽象接口可以很自然的映射成为C的一组函数。在组件一级,用C提供的接口可以和C++做得一样好。但是组件内部,C会让开发者直接面对复杂度,必须要搞清楚整个系统的来龙去脉才能用好;而C++可以一定程度的封装复杂度,但是设计者往往高估了C++的这种能力,为了灵活性却引入了更多的复杂性,使得学习曲线陡然上升。所以如果我们不对C++抱以很多不切实际的幻想,老老实实的使用C++的话,相比于C用起来要轻松简单许多。 说到UI设计的话,UI天生就是面向对象的,再没有比面向对象设计更适合更自然的设计思路了。弃用C++改用C不会得到什么额外好处。当然C++也不是最适合的语言,理想的语言是带有metadata的静态类型面向对象语言,C#/JAVA之类很适合做UI。
同感亚,C中的一些方法技巧,平移到C++中很可能就犯下了大忌。
成为好的C程序员比成为好的C++程序员更难。 这句话基本上是有问题的,如果不谈C的那些陷阱和缺陷的话,C语言的表现能力要差很多的,而用这样的语言写出好的程序,那么就不是语言方面的能力了,可以说是一个好的程序员了。 那么这句话可以修正为:成为一个好的程序员比成为好的X程序员更难!
这是一个秘密:成为好的C程序员比成为好的C++程序员更难。 我早就有这个感觉,但是不敢嚷嚷,怕被人拍砖。

Post a comment

非这个主题相关的留言请到:留言本