分类： tech

主要想写写C语言，也是巩固一下自己的基础。计划写下面这些主题：

1，指针，数组

2，Bitfields

3，volatile，const，static

4，extern，作用域

5，字符串，宽字符

6，define，typedef

7，lvalue，rvalue

8，库函数

9，malloc、free

10，c api

11，strcpy

回复一下这篇文字http://groups.google.com/group/pongba/browse_thread/thread/2c4aef6e89cfd362/adda28b8d29a93b7?show_docid=adda28b8d29a93b7

多少也算是个windows下的MFC常用的程序员，谈谈个人看法。

1，Essential C++这本书不是高阶的，如Milo所言，另外也不算是初学的，我翻看过钱能那本书，如果是follow了国内的教育体系，这书可以看。

2，这个学习路线基本上用处不大，每天8小时，那么这个人既不学习也不工作，只是为了学而学，傻啦。学东西要有个目的，为了赚钱或者为了乐趣或者为了泡妞，没有目的的长时间学习是无法坚持的。

3，”吃透“这个词很有意思，楼主写了比党更长久，不知能否做到，但我相信，一定会比里面提到的一些技术活的更长久，所以只要吃透本质性的东西就好了。比如算法、操作系统、内存管理、socket编程、消息循环机制、多线程编程基础等等，其它的，真的没有必要吃透，会用就好了。样样想精通，只能痒痒稀松。哪些东西算是本质性的，我有一个办法，可以去图书馆看看10年前的计算机书，如果那些书还有用，还有人推荐推广，那个技术应该算是本质性的了，时间是最好的标杆。

4，MFC不必深学，照猫画虎即可，MFC的好处是他所有的源代码都给你，可以读，可以改，可以模仿克隆。而且MFC没有死，VC2010依然对它继续加强，Windows系统下搞界面设计还是用它比较容易。

5，SDK是否需要深学，也未必，我的感觉是知道大体有什么，到时候能查到就OK，SDK的开发例程是基于C的，所以跟你前面推荐的不太配合。另外有没有必要非得学SDK呢？还是有些怀疑的，MFC也好，ATL也好或者WTL也好，都对SDK做了包装，就是让程序员更简单的使用，非得赤裸裸用SDK的时候很少，这个投入产出比例就不合算了。当然，我说的是操作系统的SDK，其它的不论。

总而言之，一年这个期限是远远不够的，而且一年的程序员，眼界或者能达到的水平是有限的，开发这件事其实就是个熟练工种，除了少数计算机科学家，大多数人都是在重复做工。只要有心，从小工达到工匠的水平并不难，但是需要时间，看看过去的学徒如何出师就知道了。小工算是一般程序员的话，工匠也就是高级程序员了，大师嘛，可望不可及，就不说了。

http://geekwhisperin.wordpress.com/2009/09/24/bug-vs-feature/

某个笑话中程序员经常说到的几句话里面就有这句：

你懂什么？！这不是bug，这是个feature！

当然，这种情况其实不怎么常见，毕竟客户也不是傻子，还是能看出来有没有错误发生的。

但是在这篇博客中

http://blogs.msdn.com/shawnhar/archive/2009/12/29/bug-or-feature.aspx

Shawn给我们分享了个真正的bug变feature、老母鸡变鸭的故事，简单说一下：

Extreme G是一个任天堂64上的赛车游戏，每个赛车都有超级加速（turbo boosts）功能，开过车的应该都知道，在弯道时候不应该加速，直道加速才能获得最好的效果。

Ash（主程序员）编写了一些人工智能（AI）代码让计算机控制的赛车知道什么时候应该加速，算法基本上就是直道加速加上随机选定某些值。

游戏出来以后，程序员们读到了一篇玩后感：

“我们特别喜欢这个具有攻击性的人工智能，它会用尽全力来阻止你超车。如果你超了一辆计算机控制的赛车，甚至是在弯道中间它都会加速，结果就是导致一片混乱人仰马翻，或许这个不是最好的比赛策略，但是这个心态简直是太他妈的爽翻了！”

‘喔！”Ash说“这是什么傻逼玩后感啊！我设计的人工智能系统根本不应该是这样运作的。”

检查了一些代码以后（见原文），Ash发现原来是代码写错了，结果就不是他预想的那种特性。当然，修改一些代码还是可以达到他原来的目的。

改不改呢？评论者说的是对的，尽管有些出乎意料，但是这个bug（或者说feature）产生了比原来更爽的效果，游戏开发者把这段代码继续保留在正式发布版本中，作为游戏的feature出现。

挺有意思的故事吧，嘿嘿！