工作态度指你能有些做职员的基本素质。

      这个道理应该所有人都清楚。但是到实际事情时候就经常犯迷糊。下面几点是经常会出问题的地方：

1、不经测试，Review，就认为自己工作完成了。

       你的代码或者应用一旦被别人Review ，或者进行试用。这时候你代码的好坏，或者功能是否在各种场景下是否可用，都会影响你这个人在上级及同事眼里的可信任度。

       代码书写的规范，性能的高质量，各种功能在各个场景都可用，则表示你这个人是完全可信的。下次上级给你分派任务的时候，就可以给你更多的自由度来发挥。长此以往，前途和钱途自然就随手可得。

        反之，代码不规范，功能好些场景不可用。这只能让上级或同事觉得你不可信任。每次都需要处理你带来的这些问题，说恶心点就是你每次拉完大便都没擦屁股，每次都得你的同事和上级帮你擦屁股。数次都这样后，上级或同事下次跟你沟通的时候就会觉得你这个人不可信任，一件事情必须反复多次强调，总觉得你还会作出问题。你的信用已经非常危险了。

       你在别人眼里的信用就这样被你慢慢透支了。透支到一定程度，走人吧。整个团队的效率会因为你而变慢（每个人跟你沟通的成本都会影响到他本人的产出），你不走人谁走人。

2、最短可接受的工作时限

       你有没有统计过，公司分派给你一个工作时候，上级指定的这项工作计划做多久的预计，跟你自己的预计有多大差异？

       如果你预计时间大于上级给的工作计划时间，同时上级没有增派人手进行相关工作。除了BT的领导外，那只有一种情况：上级对你的工作态度非常不满，认为你的薪水对应的工作能力不是这么点。

       对于刚工作的，更多的是你表现出来的工作能力在公司的平均工作能力之下。同时公司觉得你对工作没有表现出足够的热情。 一个能力在平均水平下面，又缺乏工作激情的人，他的前途在那里？？

       如果这个人还没有表现出几个月后能达到平均水平之上的希望，为啥会留这样一个人呢？

3、工作能力不等于技术水平

       我曾看到过有人抱怨说大公司的员工也不过是这技术水平， 这么简单的技术问题都不会。我自己早期也有这样想法，后来发现是不对的。

       不论大公司还是小公司，要得是解决问题的工作能力。 我的曾经手下就有好几个技术水平很牛的，但是作出来的应用却一次次返工的。为啥，工作能力这些非技术因素他们做的很不好。

       工作能力的非技术因素包括的很多： 责任心，表现就是对自己写出来的代码有一定要让人放心的责任； 沟通能力，一个典型的表现就是需求不理解或者需求不明时，及时得跟相关人沟通，而不是自己先按自己想法实现，造成代码写完后再返工的恶果等等。

       技术水平低，但是解决问题能力强的，我也碰到过一些人。 工作的能力更重要的是这些非技术的工作能力，而不是技术水平。技术人员很容易技术水平高，但是非技术的工作能力差。 这是很糟糕的。

4、发展潜力，学习能力

      公司使用的技术不可能一直不变，一直不变的公司只能慢慢被市场淘汰。这就要求员工能不断的学习新的知识，并应用到工作中来。

      要想不会出现几年后，自己发现跳槽找个工作都没人要，赶快学习吧。

      坚持，是一个人最难做到的。 但是不坚持，那就等着灭亡吧。

5、笨鸟先飞

      一个人，在公司，如果工作能力在平均线以下， 加班吧， 不要有任何幻想。

      最可怕的是自己没这个意识， 自认为自己技术水平很牛， 但是解决问题的工作能力却在平均水平线以下， 眼高手低 ， 这样的人， 公司是不能留的。

6、承诺到的事情一定要做到，不要找理由

       一件事情没有被做完，想找理由能找很多的。既然你承诺了某个时间点前完成，就不要再找各种理由推脱。

       公司同事和上级虽然可能这次接受了你的理由，但是下次呢， 慢慢的就会让你的上级，同事觉得你是一个喜欢推托的人。 感觉你干事是非常不可靠的。不知道那次就会不完成，下次谁敢再找你干事？

新补充的：

7、有能力者不用加班，能力在平均线之下的自觉加班吧

从CSDN的评论中，争议最大的一个在加班。我这里就补充一下我对加班的看法。

首先，所有人加班，这肯定是领导者的责任， 整体的工作进度压力过大了。

连续的不间断的加班，这也是领导者的责任，人不可能一直处于线绑紧的状态。

但是，如果一个部门，部分人加班，部分人不加班，而且并不是因为领导弱智的把一些人工作分派多，一些人工作分派少导致的。加班的人只能说明他的工作能力在部门的平均线之下。
同一个工作， A 员工干的话 3 天完成， B 员工干的话 5天完成。 最后如果这个工作分派给 B 员工， 很可能是要求他 4天完成。 而且他必须自觉加班。

这就是我所说的 ： 有能力者不用加班，能力在平均线之下的自觉加班。

想起写这篇文章是在看侯杰先生的《深入浅出MFC》时,突然觉得自己在大学这几年关于游戏编程方面还算是有些心得，因此写出这篇小文,介绍我眼中的游戏程序员的书单与源代码参考。一则是作为自己今后两年学习目标的备忘录,二来没准对别人也有点参考价值。我的原则是只写自己研究过或准备研究的资料，所以内容无疑会带上强烈的个人喜好色彩,比如对网络,数据库等重要方面完全没有涉及。因为自己主要对三维图形引擎,人工智能算法,脚本系统,反外挂(反反外挂? ^－^)等方面感兴趣。这学期电脑都没联网了,在岳麓山闭关修炼中(^－^),连这篇文章都得在学校图书馆电子阅览室（电影放映室？）上传,内容很多凭记忆写出,如有误差敬请订正。程序员应该在理论学习与实践编程中反复迭代，所以学习资料是一回事，须知尽信书不如无书。

一、书籍：

算法与数据结构：

《数据结构（C语言版）》——严蔚敏、吴伟民 清华出版社

我觉得其配套习题集甚至比原书更有价值，每个较难的题都值得做一下。

《Introduction to Algorithms》第二版 中文名《算法导论》

关于算法的标准学习教材与工程参考手册，在去年CSDN网站上其翻译版竟然评为年度二十大技术畅销书，同时《程序员》杂志上开设了“算法擂台”栏目，这些溯源固本的举动，不由得使人对中国现今浮躁不堪的所谓“IT”业又产生了一线希望。这本厚厚的书，幸亏打折我才买得起。虽然厚达千页，但其英文通俗晓畅，内容深入浅出，可见经典之作往往比一般水准的书还耐读。还能找到MIT的视频教程，第一节课那个老教授嘻皮笑脸的，后面就是一长发助教上课了。

《C语言名题精选百则 技巧篇》——冼镜光 机械工业出版社

作者花费一年时间搜集了各种常见C程序段的极具技巧性的编程法，其内容都是大有来头的，而且给出了详细的参考资料。如一个普通的Fibonacci数就给出了非递归解、快速算法、扩充算法等，步步深入，直至几无油水可榨。对于视速度如生命，连一个普通的浮点数转化为整数都另辟蹊径以减少CPU cycle的游戏程序员，怎可不看？

《计算机算法基础（第二版）》—— 佘祥宣等 华中科大出版社

我看到几个学校的研究生拿它作教材（研究生才开算法，太开玩笑了吧）。这本书薄是薄了点，用作者的话来说，倒也“精辟”。其实此书是《Fundamentals of Computer Algorithms》的缩写版，不过原书出版太久了，反正我是没找到。

《The Art of Computer Programming》Volume 1-3

作者Donald E. Knuth是我心目中与冯.诺依曼、Dijkstra、Shannon并列的四位大师。这本书作者从读大学本科时开始写，一直写到博士时，十年磨一剑，足见其下足了功夫。可作为计算机技术的核心——算法与数据结构的终极参考手册。创新处也颇多，譬如常见的Shell排序他在书中提出可用(3i-1)/2的间隔，这使其稍快于O(n1. 5)。当然这套书描述高度数学化，为此恐怕一般的人（我？）最好还得先看一本数学预备书《Concrete Mathematics》（直译为混凝土数学？^－^）再说。可惜的是这套书才出到第三卷，并没有覆盖全部常见的算法内容。不过好在对于游戏程序员来说，越常见的算法用得越多，这也不算是什么要命的损失。

《STL源码剖析》—— 侯捷 华中科大出版社

侯捷不用介绍了，华人技术作家中的旗舰，说其有世界级水准也不为过。这本书我以为是C++与数据结构的葵花宝典（欲练此功，必先自宫）。也就是说，不下几层地狱很难看懂，因为它要求的预备知识太多了，如STL、数据结构、泛型编程、内存管理都要很扎实（为此是不是还要看看有内存管理设计模式之称的《Small Memory Software》这本书呢？），但是一旦看懂，真会是所向披靡。

《Data Structures for Game Programmers》

每个数据结构的例程都是一个小游戏，还用SDL库实现了一个算法演示系统。虽然内容失之于浅，但起码让人了解了数据结构在游戏中的作用。

其实游戏程序并不比其它程序特殊，甚至要求基本功更加扎实，所以花时间做一些看似与实际应用不甚相干的习题，对今后的工作是大有裨益的。而且有些应用很广的算法，如常被人津津乐道的A*算法及其变种，牵涉到图的检索周游与分枝-限界法，恐怕还得读一些艰深的论文才能充分明白运用，如Donald E. Knuth的《An analysis of alpha-beta cutoffs》。其实还有不少此类的好书，如《Data Structures and Algorithms in C++》、《Programming Pearls》、《More Programming Pearls》（算法珠玑）等，我却以为要先看严谨一点的著作，再看内容随笔一点的书。

汇编：

《IBM-PC 汇编语言程序设计》第二版　

国内经典教材。

《The Art of Assembly Language》

这本书足有1600页，噢！

C语言：

《The C Programming Language》第二版

虽然篇幅短小，但每个例程都很经典。（我们老师开始拿它作教材，后面换为谭小强的C语言书，理由为：例子尽是些文本处理。我就纳了闷了，难道现代的计算机程序不是将大量时间消耗在字符串与文本的处理上吗？）

C++：

学过C语言，再学C++，先看这本《C++ Primer》的缩写版：

《Essential C++》

对C++有个入门了解，再看

《C++ Common Knowledge: Essential Intermediate Programming》

就不会有什么重要的知识点完全不知所措了，接下来是

《The C++ Standard Library : A Tutorial and Reference》

标准库，当然主要是标准模板库的标准学习参考手册，然后最好平时边写程序边参悟。

《Effective C++》等

我是说书名以形容词 + C++的那些书，计有七八本，慢慢看吧，罗马不是一日建成的。

(《Essential C++》、《Effective C++》、《More Effective C++》、《Accelerated C++》、《Effective STL》、《Exceptional C++》、《More Exceptional C++》、《Imperfect C++》，虽然书名格式相似，但每一本都绝非马虎之作。)

谁说C++程序比C程序要慢？那就请看下面：

《The Design and Evolution of C++》

知其过去才能知其未来，才能应用。

《Inside the C++ Object Model》

揭露C++的编译器模型。

《Efficient C++ Performance Programming Techniques》

当算法优化已到极致，在运用汇编之前，最后还可看看此书，有时高级和低阶都能做成相同的事情。

还有两本特别的书：

《Modern C++ Design : Generic Programming and Design Patterns Applied》

作者想把设计模式和泛型编程结合起来，并写了个尝试提供一切的Loki库来实作,不过其观点并未得到C++社区的普遍响应。尽管如此，本书仍称得上思想前沿性与技术实用性结合的典范。

《C++ Template Metaprogramming》

把编译器当作计算器？本书介绍了Boost库的MPL模板元编程库。当然提到Boost库，对于游戏程序员不能不提到其中的Graph库，有《The Boost Graph Library》一书可看。还有其中Python库，号称国内首款商业三维图形引擎的起点引擎就用了Boost－Python库。说实话我觉得起点引擎还是蛮不错的，那个自制的三维编辑器虽然界面简陋，但功能还算蛮完善，给游戏学院用作教学内容也不错。另有一个号称中国首款自主研发的全套网游解决方案。我看到它那个三维编辑器，心想这不就是国外一个叫freeworld3D的编辑器吗？虽然有点偏门，但我以前还较劲尝试破解过呢。还把英文界面汉化了，大概用exescope这样的资源修改软件就能搞定吧。我又心想为什么要找freeworld3D这个功能并不太强大的编辑器呢？仅仅是因为它便宜到几十美金？它唯一特别一点的地方就是支持导出OGRE图形引擎的场景格式，这样一想不由得使人对它图形引擎的“自主”性也产生怀疑了。这样的“自主”研发真让人汗颜，只要中国还没封sourceforge这个网站（据说以前和freeBSD网站一起被封过？），国人就能“自主”研发。

有人还会推荐《C++ Primer》《Thinking in C++》《The C++ Programming Language》等书吧，诚然这些书也很好，但我总觉得它们太大部头了。还不如多花点时间看看国外好的源代码。

Windows编程

Operating System Concepts第五版

国内有些操作系统的教程其实就是它的缩写版。

《Windows 95 System Programming Secrets》

深入剖析了Windows操作系统的种种种种，有人爱看《Linux内核完全注释》，有人爱看《自己动手写操作系统》这样煽情的书，但我想作为商业的操作系统，把Windows内核剖析到这地步也高山仰止了。

《Programming Applications for Microsoft Windows》第四版

先进程线程，再虚存管理，再动态链接库，最多讲到消息机制。作者在序言中说：“我不讲什么ActiveX, COM等等，因为当你了解了这些基础后，那些东西很快就会明白！”可以作为《Programming Windows》的先修课。

计算机体系：

《Computer Systems : A Programmer’s Perspective》

和《The Art of Computer Programming》在我心中是计算机史上两本称得上伟大的书，计算机组成原理，操作系统，汇编，编译原理，计算机网络等等课程汇成这本千页的大书，因为计算机在作者眼中就是一个整体。

开源阅读：

《Code Reading : The Open Source Perspective》

张大千临摹了几百张明代石涛的山水，画出的画以假乱真，后来他去敦煌潜心临摹几年，回来画风大变，终成大家。程序员其实有40%的时间是在读别人的源代码，侯捷先生说：“源码面前，了无秘密”，又说“天下大事，必作于细”，可以与他的《上穷碧落下黄泉，源码追踪经验谈》参看。

MFC:

《深入浅出MFC》

我实在以为没有看过侯捷先生的《深入浅出MFC》的人多半不会懂得MFC编程。其实我是打算用一年多的时间写一个给游戏美工用的三维编辑器，顺便作为毕业设计。图形库就用MFC吧，反正也没得选择。如果要用wxWidgets无非是猎奇而已，还不是MFC的翻版，当然它跨平台了。就象阻击手对自己枪械的零件了如指掌一样，要想用MFC写出非玩具程序的人一定要了解其内部构造。还有一本书叫《MFC深入浅出》，并不是同一本。

IDE:

《Microsoft Visual Studio 2005 Unleashed》

工欲善其事，必先利其器。当然我认为与其用形如Source Insight、Slick Edit、Code Visualizer之类的代码阅读器、图形化工具，还不如用自己的大脑。但如果你嫌打源代码慢的话，可以用Visual AssistX。如果嫌老是写重复相似的代码的话，可以用Code Smith。单元测试可以用CppUnit，Boost库中的测试框架也不错。有心情可以吧Visual Studio外接Intel的Compiler，内嵌STLport，但不是大工程，性能分析没必要动不动就用下VTune吧。

程序员之路：

《游戏之旅——我的编程感悟》

云风大哥。在我心目中游戏程序员国外首推卡马克，国内首推云风。也许过两年我会到网易当云风大哥的助理程序员吧。It’s my dream.（^-^）他写这本书的时候本着只有透彻理解的东西才写出来，因此内容不会很酷新，但是相信我，每读一遍都有新的收获，主要还不是知识上的，因为知识是学无止境的，授人以鱼不如授人以渔，精神上的启迪才是长久的。诚如经典游戏《仙剑奇侠传》的主力程序员兼美术指导姚壮宪（人称姚仙）在序言中所说的“云风得到的只是一些稿费，而整个中国民族游戏产业得到的将是一次知识的推动”，此言不虚矣。

《编程高手箴言》

梁肇新是豪杰超级解霸的作者，本来每个合格的程序员（Programmer , 而非Coder）都应该掌握的东西，现在变成了编程高手的独家箴言。不知是作者的幸运还是中国IT业的悲哀。知识点还是讲得蛮多的，不过对MFC的地位颇有微词。我实在认为MFC的名声就是那些不懂得用它的人搞臭的。不过作者的牢骚也情有可原，每个具有创造力的程序员都应该不太喜欢framework。

《Masters of DOOM: How Two Guys Created an Empire and Transformed Pop Culture》中文名《DOOM启世录》

卡马克，罗洛斯，这些游戏史上如雷贯耳的名字。（现在卡马克已专注于火箭制造上，罗洛斯则携妻回乡隐居）要不是没上过大学的卡马克和图形学大师亚伯拉罕的功勋，可能到现在游戏中还不知三维为何物。勿庸置疑，在计算机界历史是英雄们所推动的。这本书真实的记录了这些尘世英雄的所为所思。

作为程序员的我对这几本策划与美工的书也产生了浓厚兴趣，以前搞过一两年的3DS MAX插件编程，觉得用maxscript还是好过MaxSDK，毕竟游戏开发中所多的是模型场景数据的导入导出，大可不必大动干戈。

策划：

《Creating Emotion in Games : The Craft and Art of Emotioneering》

在壮丽煊目的宏伟三维世界背后，在残酷的杀戮，动人心魄的情节背后，我们还需要什么来抓住玩家的心？答对了，就是emotion.真正打动人心的，才是深入骨髓的。

《Ultimate Game Design : Building Game Worlds》

从名字可以看出，写给关卡设计师的，特别是讲室外自然场景的构建颇有可取之处。

《Developing Online Games : An Insider’s Guide》

就象名为反模式的书讲软件团队运营一样，这本书讲商业运作多过技术。一个历经艰难，现在盛大的游戏程序员，翻译了这本书。

美工：

《Digital Cinematography & Directing》

数字摄影导演术，每当你在3DS MAX或者Maya等三维创作软件中摆放摄影机，设计其运动轨迹时，你可曾想过你也站在导演的位置上了？

《The Animator’s Survival Kit》

看着这本讲卡通角色运动规律的书，一边产生温习《猫和老鼠》的念头，一边继续对前不久新闻联播中关于中国产生了某计算机自动卡通动画生成软件报道的蔑视，这条报道称此举可大大加快中国卡通动画的产量。我且不从技术上探讨其是否是在放卫星（其实我知道得很清楚，前文已表，本人搞过一两年的卡通动画辅助软件编程），但计算机机械生成的动画怎可代替人类充满灵性的创作？

《The Dark Side of Game Texturing》

用Photoshop制作材质贴图，还真有些学问。

三维图形学：

搞三维图形学首先还是要扎扎实实的先看解析几何、线性代数、计算几何的教材，后面的习题一个都不能少。国内数学书还是蛮好的。苏步青大师的《计算几何》称得上具有世界级水准，可惜中国CAD的宏图被盗版给击垮了。现在是我们接过接力棒的时候了。It’s time!

《Computer Graphics Geometrical Tools》

《计算机图形学几何工具算法详解》算法很多，纰漏处也不少。

《3D Math Primer for Graphics and Game Development》

浅易，可作为三维数学的“速食“。

《Mathematics for 3D Game Programming & Computer Graphics》第二版

比上面那本深入一些，证明推理的数学气也浓一些，可作为专业的数学书与编程实践一个过渡的桥梁吧。内容涉猎也广，射线追踪，光照计算，可视裁剪，碰撞检测，多边形技术，阴影算法，刚体物理，流体水波，数值方法，曲线曲面，还真够丰富。

《Vector Game Math Processors》

想学MMX,SSE吗，那就看它吧，不过从基础讲起的，要耐心哦。

 DirectX:

《Introduction to 3D Game Programming with DirectX 9.0》

DirectX入门的龙书，作者自己写的简单示例框架，后面我干脆用State模式，把所有例子绑到一块儿去了。

《Beginning Direct3D Game Programming》

作者取得律师学位后变成了游戏程序员，真是怪也哉。本书虽定位为入门级书，内容颇有独特可取之处。它用到的示例框架是DXSDK Sample Framework，而不是现在通行的DXUT。要想编译有两种办法吧，一是自己改写成用DXUT的。二是找旧的Sample Framework。我又懒得为了一个示例框架下载整个早期版本的DirectX，后面在Nvidia SDK 9.5中发现了。

《Advanced Animation with DirectX》

DirectX高级动画技术。骨骼系统，渐变关键帧动画，偶人技术，表情变形，粒子系统，布料柔体，动态材质，不一而足。我常常在想，从三维创作软件导出的种种效果，变成一堆text或binary，先加密压缩打包再解包解压解密，再用游戏程序重建一个Lite动画系统，游戏程序员也真是辛苦。

OpenGL:

《NeHe OpenGL Tutorials》

虽是网络教程，不比正式的书逊，本来学OpenGL就不过是看百来条C函数文档的工夫吧,如果图形学基础知识扎实的话。

《OpenGL Shading Language》

OpenGL支持最新显卡技术要靠修修补补的插件扩展，所以还要配合

《Nvidia OpenGL Extension Specifications》

来看为上。

《Focus on 3D Models》

《Focus on 3D Terrain Programming》

《Focus on Curves and Surfaces》

顾名思义，三本专论，虽然都很不深，但要对未知三维模型格式作反向工程前，研读Geomipmapping地形算法论文前，CAD前，还是要看看它们为上，如果没从别处得过到基础的话。

脚本：

先看

《Game Scripting Mastery》

等自己了解了虚拟机的构造，可以设计出简单的脚本解释执行系统了。

再去查Python , Lua ，Ruby的手册吧，会事半半功倍倍的。

《Programming Role Playing Games with DirectX 8.0》

一边教学一边用DirectX写出了一个GameCore库，初具引擎稚形。

《Isometric Game Programming with DirectX 7.0》

三维也是建立在二维的基础上，这就是这本书现在还值得看的原因。

《Visual C++网络游戏建模与实现》

联众的程序员写的，功力很扎实，讲棋牌类游戏编程，特别讲了UML建模和Rotional Rose。

《Object-Oriented Game Development》

套用某人的话：“I like this book.”

Shader:

要入门可先看

《Shaders for Game Programmers and Artists》

讲在RenderMonkey中用HLSL高级着色语言写Shader.

再看

《Direct3D ShaderX : Vertex and Pixel Shander Tips and Tricks》

用汇编着色语言，纯银赤金。

三大宝库：

《Game Programming Gems》

我只见到1-6本，据说第7、8本也出来了？附带的源代码常有bug，不过瑕不掩瑜，这套世界顶级游戏程序员每年一度的技术文集，涉及游戏开发的各个方面，我觉得富有开发经验的人更能在其中找到共鸣。

《Graphics Gems》全五本

图形学编程Bible，看了这套书你会明白计算机领域的科学家和工程师区别之所在。科学家总是说，这个东西在理论上可行。工程师会说，要使问题在logN的时限内解决我只能忍痛割爱，舍繁趋简。

《GPU Gems》出了二本

Nvidia公司召集图形学Gurus写的，等到看懂的那一天，我也有心情跑去Siggraph国际图形学大会上投文章碰运气。

游戏引擎编程：

《3D Game Engine Programming》

是ZFXEngine引擎的设计思路阐释，很平实，冇太多惊喜。

《3D Game Engine Design》

数学物理的理论知识讲解较多，本来这样就够了，还能期待更多吗？

人工智能：

《AI Techniques for Game Programming》

讲遗传算法，人工神经网络，主要用到位数组，图算法。书的原型是根据作者发表到GameDev.net论坛上的内容整理出来的，还比较切中实际。

《AI Game Programming Wisdom》

相当于AI编程的Gems。

《PC游戏编程(人机博弈)》

以象棋程序为蓝本，介绍了很多种搜索算法，除了常见的极大极小值算法及其改进--负极大值算法，还有深度优先搜索以外。更提供了多种改进算法，如：Alpha-Beta,Fail-soft alpha-beta,Aspiration Search, Minimal Window Search,Zobrist Hash,Iterative Deepening,History Heuristic,Killer Heuristic,SSS*,DUAL*,MFD and more.琳琅满目，实属难得。

反外挂：

《加密与解密(第二版)》 看雪论坛站长 段钢

破解序列号与反外挂有关系么？不过，世上哪两件事情之间又没有关系呢？

《UML Distilled》 Martin Fowler

很多人直到看了这本书才真正学懂UML。

Martin Fowler是真正的大师,从早期的分析模式,到这本UML精粹,革命性的重构都是他提出的,后来又写了企业模式一书。现在领导一个软件开发咨询公司，去年JavaOne中国大会他作为专家来华了吧。个人网站：MartinFowler.com

设计模式三剑客：

《Design Patterns Elements of Reusable Object-Oriented Software》

《Design Patterns Explained》

《Head First Design Patterns》 

重构三板斧：

《Refactoring : Improving the Design of Existing Code》

《Refactoring to Patterns》

《Refactoring Workbook》

软件工程:

《Extreme Programming Explained : Embrace Change》第二版

其中Simplicity的Value真是振聋发聩，这就是我什么都喜欢轻量级的原因。

《Agile Software Development Principles,Patterns,and Practices》

敏捷真是炒得够火的，连企业都有敏捷一说，不过大师是不会这么advertising的。

《Code Complete》第二版

名著。

数学：

《数学，确定性的丧失》M.克莱因

原来数学也只不过是人类的发明与臆造，用不着供入神殿，想起历史上那么多不食人间烟火的科学家（多半是数学家），自以为发现了宇宙运作的奥秘，是时候走下神坛了。

物理：

《普通物理学》第一册 += 《Physics for Game Developers》

物理我想就到此为此吧，再复杂我可要用Newton Engine,ODE了，等待物理卡PPU普及的那天，就可充分发挥PhysX的功效了，看过最新的《细胞分裂》游戏Demo演示，成千上万个Box疯狂Collide，骨灰级玩家该一边摸钱包一边流口水了。

二、开源代码：

Irrlicht

著名的鬼火引擎，从两年前第一眼看到它，这个轻量级的三维图形引擎，就喜欢上了它。源代码优雅，高效，且不故弄玄虚。值得每个C++程序员一读，并不限于图形编程者。它的周边中也有不少轻量级的东西。如Lightfeather扩展引擎，ICE、IrrlichtRPG、IrrWizard.还有IrrEdit、IrrKlang、IrrXML可用。（可能是为了效率原因，很多开源作者往往喜欢自己写XML解析库，如以上的IrrXML库,即使有现成的tinyXML库可用。这真会让tomcat里面塞Axis，Axis里面塞JUDDI，弄得像俄罗斯套娃玩具的Java Web Service Coder们汗颜。）

OGRE

排名第一的开源图形引擎，当然规模是很大的，周边也很多。除了以C#写就的OgreStudio ，ofusion嵌入3DS MAX作为WYSWYG式的三维编辑器也是棒棒的，特别是其几个场景、地形插件值得研究。以至于《Pro OGRE 3D Programming》一书专论其用法。搜狐的《天龙八部》游戏就是以其作为图形引擎，当然还另外开发了引擎插块啦。我早知道OGRE开发组中有一个中国人谢程序员，他以前做了很多年的传统软件编程。有一次天龙八部游戏的图形模块的出错信息中包含了一串某程序员的工作目录，有一个文件夹名即是谢程序员的英文名，我据此推断谢程序员即是搜狐北京的主程。看来中国对开源事业还是有所贡献的嘛，王开源哥哥的努力看来不会白费！（^-^）不过我侦测的手法也有些像网站数据库爆库了，非君子之所为作。

RakNet

基于UDI的网络库，竟还支持声音传输，以后和OpenVision结合起来做个视聊程序试试。

Blender

声誉最盛的开源三维动画软件，竟还带一个游戏引擎。虽然操作以快捷键驱动，也就是说要背上百来个快捷键才能熟练使用。但是作为从商业代码变为开源之作，威胁三维商业巨头的轻骑兵，历经十年锤炼，代码达百万行，此代码只应天上有，人间哪得几回看，怎可不作为长期的源码参考？

风魂

二维图形库。云风大哥的成名之作。虽然不代表其最高水平（最高水平作为商业代码保存在广州网易互动的SVN里呢），但是也可以一仰风采了。

圣剑英雄传

二维RPG。几个作者已成为成都锦天的主力程序员。锦天的老总从一百万发家，三年时间身价过亿，也是一代枭雄了。这份代码作为几年前的学生作品也算可以了，因为一个工程讲究的是四平八稳，并不一定要哪个模块多么出彩。反正我是没有时间写这么一个东东，连个美工都找不到，只能整天想着破解别人的资源（^-^）。

Boost

C++准标准库，我想更多的时候可以参考学习其源代码。

Yake

我遇到的最好的轻量级游戏框架了。在以前把一个工程中的图形引擎从Irrlicht换成OGRE的尝试中，遇到了它。OGRE的周边工程在我看来都很庸肿，没有完善文档的情况下看起来和Linux内核差不多。不过这个Yake引擎倒是很喜欢。它以一个FSM有限状态机作为实时程序的调度核心，然后每个模块：物理、图形、网络、脚本、GUI、输入等等都提供一个接口，接口之下再提供到每种具体开源引擎的接口，然后再接具体引擎。通过这样层层抽象，此时你是接Newton Engine,ODE还是PysX都可以；是接OGRE,Crystal Space还是Irrlicht都可以；是接RakNet还是LibCurl都可以；是接Python，Lua还是Ruby都可以，是接CEGUI还是others，是接OIS还是others（呵呵,记不起来others）都可以。所以Yake本质上不是OGRE的周边。虽然用Neoengine的人都倒向了它，但是现在版本还很早。特别是我认为，学习研究时一定要有这种抽象之抽象，接口之接口的东西把思维从具体的绑定打开，而开发时抽象要有限度的，就像蔡学镛在《Java夜未眠》中讲的，面向对象用得过滥也会得OOOO症(面向对象过敏强迫症)。

Quake Doom系列

据说很经典，卡马克这种开源的黑客精神就值得赞许。把商业源代码放出来，走自己的创新之路，让别人追去吧。不过Quake与Unreal引擎的三维编辑器是现在所有编辑器的鼻祖，看来要好好看看了。

Nvidia SDK 9.X

三维图形编程的大宝库，这些Diret3D与OpenGL的示例程序都是用来展示其最新的显卡技术的。硬件厂商往往对软件产品不甚在意，源代码给你看,东西给你用去吧，学完了还得买我的硬件。Intel的编译器，PhysX物理引擎大概也都是这样。Havok会把它的Havok物理引擎免费给别人用吗？别说试用版，连个Demo都看不到。所以这套SDK的内容可比MS DirectX SDK里面那些入门级的示例酷多了，反正我是如获至宝，三月不知愁滋味。不过显卡要so-so哦。我的GeForce 6600有两三个跑不过去,差强人意。

三、网站：

www.CSDN.net

程序员大本营吧，软文与“新技术秀”讨厌了点，blog和社区是精华之所在。

www.GameRes.com

游戏程序员基地，文档库中还有点东西。投稿的接收者Seabug与圣剑英雄传的主程Seabug会是同一个人吗？一个在成都锦天担当技术重担的高手还有时间维护网站吗？我不得而知。

“何苦做游戏”网站

名字很个性，站长也是历尽几年前产业发展初期的艰难才出此名字。

www.66rpg.com

二维游戏图片资源很多，站长柳柳主推的RPGMaker 软件也可以玩一玩吧，但对于专业开发者来说不可当真。

www.GameDev.net

论坛中有不少热心的国外高手在活动。

www.SourceForge.net

不用说了，世界最大的开源代码库，入金山怎可空手而返？看到国外那些学生项目动不动就像模像样的。（DirectX的稚形就是英国的学生项目，在学校还被判为不合格。）

www.koders.com

源代码搜索引擎,支持正则表达式,google Lab中也有。当你某种功能写不出来时,可以看一下开源代码怎么写的,当然不过是仅供参考,开源代码未必都有产品级的强度。说到google,可看《Google Power Tools Bible》一书，你会发现，google的众多产品原来也有这么多使用门道。

这篇小文足足写了一天半的时间，不由得使我对侯捷一样的技术作家长期伏案辛勤劳作深深敬佩了。看来对于书籍或者软件，都应该尊重作者或者programmer的才智劳动

一、剖析C++标准库智能指针(std::auto_ptr)
   
    1.Do you Smart Pointer?
    2.std::auto_ptr的设计原理
    3.std::auto_ptr高级使用指南
    4.你是否觉得std::auto_ptr还不够完美?

二、C++条件,寻找构造更强大的智能指针(Smart Pointer)的
    策略
   
    1.支持引用记数的多种设计策略
    2.支持处理多种资源
    3.支持Subclassing
    4.支持多线程条件下,线程安全的多种设计策略
    5.其它多种特殊要求下,再构造

三、Generic Programming基础技术和Smart Pointer
    1.回首处理资源中的Traits技术
    2.回首多线程支持的设计

四、COM实现中,Smart Pointer设计原理

五、著名C++库(标准和非标准)中的Smart Pointer现状

---------------------------------------------------------------------

一、剖析C++标准库智能指针(std::auto_ptr)
   
    1.Do you Smart Pointer?

      Smart Pointer,中文名：智能指针, 舶来品?
      不可否认,资源泄露(resource leak)曾经是C++程序的一大噩梦.垃圾回收
      机制(Garbage Collection)一时颇受注目.然而垃圾自动回收机制并不能
      满足内存管理的即时性和可视性,往往使高傲的程序设计者感到不自在.
      况且,C++实现没有引入这种机制.在探索中,C++程序员创造了锋利的
      "Smart Pointer".一定程度上,解决了资源泄露问题.

      也许,经常的,你会写这样的代码：
      //x拟为class:
      //            class x{
      //            public:       
      //                   int m_Idata;
      //            public:
      //                   x(int m_PARAMin):m_Idata(m_PARAMin){}
      //                   void print(){ cout<<m_Idata<<endl; }
      //            .....
      //            }
      //
      void fook(){
      x* m_PTRx = new A(m_PARAMin);
      m_PTRx->DoSomething();     //#2
      delete m_PTRx;
      }

      是的,这里可能没什么问题.可在复杂、N行、m_PTRclassobj所指对象生命周
      期要求较长的情况下,你能保证你不会忘记delete m_PTRclassobj吗?生活中,
      我们往往不应该有太多的口头保证,我们需要做些真正有用的东西.还有一个
      更敏感的问题：异常.假如在#2方法执行期异常发生,函数执行终止,那么new
      出的对象就会泄露.于是,你可能会说：那么就捕获异常来保证安全性好了.
      你写这样的程式：

      void fook(){
      A* m_PTRx = new A(m_PARAMin);
      try{
          m_PTRx->DoSomething();
      }
      catch(..){
          delete m_PTRx;
          throw;
      }
      delete m_PTRx;
      }
      哦!天哪!想象一下,你的系统,是否会象专为捕获异常而设计的.

      一天,有人给你建议:"用Smart Pointer,那很安全.".你可以这样重写你的程序：
   
      void fook(){
      auto_ptr<x> m_SMPTRx(new x(m_PARAMin));
      m_SMPTRx->DoSomething();
      }

      OK!你不太相信.不用delete吗?
      是的.不用整天提心吊胆的问自己:"我全部delete了吗?",而且比你的delete
      策略更安全.

      然后,还有人告诉你,可以这样用呢：
      ok1.
      auto_ptr<x> m_SMPTR1(new x(m_PARAMin));
      auto_ptr<x> m_SMPTR2(m_SMPTR1);  //#2
      May be you can code #2 like this :
          auto_ptr<x> m_SMPTR2;
          m_SMPTR2 = m_SMPTR1;     
      ok2.
      auto_ptr<int> m_SMPTR1(new int(32));
     
      ok3.
      auto_ptr<int> m_SMPTR1;
      m_SMPTR1 = auto_ptr<int>(new int(100));
      也可以：
      auto_ptr<int> m_SMPTR1(auto_ptr<int>(new int(100)));
     
      ok4.
      auto_ptr<x> m_SMPTR1(new x(m_PARAMin));
      m_SMPTR1.reset(new x(m_PARAMin1));
     
      ok5.
      auto_ptr<x> m_SMPTR1(new x(m_PARAMin));
      auto_ptr<x> m_SMPTR2(m_SMPTR.release());
      cout<<(*m_SMPTR2).m_Idata<<endl; 
     
      ok6.
      auto_ptr<int> fook(){
      return auto<int>(new int(100));
      }
 
      ok7.............and so on
     
      但不可这样用：
     
      no1.  
      char* chrarray = new char[100];
      strcpy(chrarray,"I am programming.");
      auto_ptr<char*> m_SMPTRchrptr(chrarray);
      //auto_ptr并不可帮你管理数组资源    
      
      no2.
      vector<auto_ptr<x>> m_VECsmptr;
      m_VECsmptr.push_back(auto_ptr<int>(new int(100)));
      //auto_ptr并不适合STL内容.
      
      no3.
      const auto_ptr<x> m_SMPTR1(new x(100));
      auto_ptr<x> m_SMPTR(new x(200));
     
      no4.
      x m_OBJx(300);
      auto_ptr<x> m_SMPTR(&m_OBJx);
     
      no5
      x* m_PTR = new x(100);
      auto_ptr<x> m_SMPTR = m_pTR;
     
      no6..........and so on

      预先提及所有权的问题,以便下面带着疑问剖析代码?

      power1.
      auto_ptr<x> m_SMPTR1(new x(100));
      auto_ptr<x> m_SMPTR2 = m_SMPTR1;
      m_SMPTR2->print();
      //输出：100.
      m_SMPTR1->print();
      //!! 非法的.

      power2.
      auto_ptr<x> m_SMPTR(new x(100));
     
      auto_ptr<x> returnfun(auto_ptr<x> m_SMPTRin){
      return m_SMPTRin;
      }
     
      auto_ptr<x> = returnfun(m_SMPTR);  //#5

      //在上面的#5中,我要告诉你对象所有权转移了两次.
      //什么叫对象所有权呢?
  
    2. std::auto_ptr的设计原理
      
      上面的一片正确用法,它们在干些什么?
            一片非法,它们犯了什么罪?
            一片什么所有权转移,它的内部机智是什么?
      哦!一头雾水?下面我们就来剖析其实现机制.
      基础知识：
              a.智能指针的关键技术：在于构造栈上对象的生命期控制
                堆上构造的对象的生命期.因为在智能指针的内部,存储
                着堆对象的指针,而且在构析函数中调用delete行为.
                大致机构如下：
                x* m_PTRx = new x(100);//#1
                template<typename T>
                auto_ptr{
                private:
                T* m_PTR;//维护指向堆对象的指针,在auto_ptr定位后    
                ....     //它应该指向#1构造的对象,即拥有所有权.
                ~auto(){ delete m_PTR; }
                ....
                }
             b.所有权转移之说
               上面曾有一非法的程式片段如下：
               auto_ptr<x> m_SMPTR1(new x(100));
               auto_ptr<x> m_SMPTR2 = m_SMPTR1;
               m_SMPTR2->print();
               //输出：100.
               m_SMPTR1->print();
               //!! 非法的.
               按常理来说,m_SMPTR->print();怎么是非法的呢?
               那是因为本来,m_SMPTR1维护指向new x(100)的指针,
               可是m_SMPTR2 = m_SMPTR1;auto_ptr内部机制使得m_SMPTR1将对象的地址
               传给m_SMPTR2,而将自己的对象指针置为0.
               那么自然m_SMPTR->print();失败.
               这里程序设计者要负明显的职责的.
               那么auto_ptr为什么采取这样的策略：保证所有权的单一性.
                                               亦保证了系统安全性.
               如果多个有全权的auto_ptr维护一个对象,那么在你消除一个
               auto_ptr时,将导致多个auto_ptr的潜在危险.
     
       下面我们以SGI-STL的auto_ptr设计为样本(去掉了无关分析的宏),来剖析其原理.
       #1  template <class _Tp> class auto_ptr {
       #2  private:
       #3  _Tp* _M_ptr;  //定义将维护堆对象的指针

       #4  public:
       #5  typedef _Tp element_type;  //相关类型定义
       #6  explicit auto_ptr(_Tp* __p = 0) __STL_NOTHROW : _M_ptr(__p) {}
       #7  auto_ptr(auto_ptr& __a) __STL_NOTHROW : _M_ptr(__a.release()) {}
       #8  template <class _Tp1> auto_ptr(auto_ptr<_Tp1>& __a) __STL_NOTHROW
                                                 : _M_ptr(__a.release()) {}
           //#6、#7、#8是auto_ptr构造函数的三个版本.
           //#6注释：传入对象的指针,构造auto_ptr.explicit关键字:禁止隐式转换.
           //        这就是ok2正确,而no5(隐式转换)错误的原因.
           //#7注释：拷贝构造函数.
           //        传入auto_ptr实例,构造auto_ptr. ok1、ok3使用了这个构造式.
           //        它是一个很关键的构造函数,在具体情况下,我们再分析
           //#8注释：auto_ptr的模板成员,可在继承对象重载的基础上,实现特殊功能.
           //  
           //   举例：
           //   class A{ public:
           //          virtual void fook(){cout<<"I am programming"<<endl;
           //          /*..........*/                                   };
           //   class B : public A {
           //          virtual void fook(){ cout<<"I am working"<<endl;
           //         /*...........*/                                  }; 
           //   auto_ptr<A> m_SMPTRa(new A(33));//实质：
           //   auto_ptr<B> m_SMPTRb(m_SMPTRa); //基类的指针可以赋给派生类的指针         
           //             
           //   auto_ptr<B> m_SMPTRb(new B(44));//实质：
           //   auto_ptr<A> m_SMPTRa(m_SMPTRb); //派生类的指针不可赋给基类的指针
           //      
           //   auto_ptr<A> m_SMPTRa(new B(33));  // ok! 
           //   m_SMPTRa->fook()将调用派生类B的fook()
           //   m_SMPTRa->A::fook()将调用基类A的fook()
           //   
           //   auto_ptr<B> m_SMPTRb(new A(33));  // wrong!
           //  
           //  
       #9  auto_ptr& operator=(auto_ptr& __a) __STL_NOTHROW {
       #10 if (&__a != this) { delete _M_ptr;  _M_ptr = __a.release(); }
       #11 return *this;
       #12 }
        
       #13 template <class _Tp1>
       #14 auto_ptr& operator=(auto_ptr<_Tp1>& __a) __STL_NOTHROW {
       #15 if (__a.get() != this->get()) { delete _M_ptr; _M_ptr = __a.release(); }
       #16 return *this;
       #16 } 
          //
          // #9~~#16 两个版本的指派函数.
          //         delete _M_ptr; 在指派前,销毁原维护的对象.
          //         _a.release() ; release操作,详细代码参见#20~~#23.
          //                        用于*this获得被指派对象,
          //                        且将原维护auto_ptr置空.
          //     no3使用了第一种指派.
          //     而权限转移正是_a.release()的结果.
         
       #17 ~auto_ptr() __STL_NOTHROW { delete _M_ptr; }
          //构析函数.消除对象.注意这里对对象的要求!
         
       #17 _Tp& operator*() const __STL_NOTHROW {  return *_M_ptr; }
       #18 _Tp* operator->() const __STL_NOTHROW { return _M_ptr;  }
       #19 _Tp* get() const __STL_NOTHROW { return _M_ptr; }
         //
         //  操作符重载.
         // #17注释：提领操作(dereference),获得对象. 见ok5用法.
         // #18注释：成员运算符重载,返回对象指针.
         // #19注释：普通成员函数.作用同于重载->运算符
         //
       #20 _Tp* release() __STL_NOTHROW {
       #21 _Tp* __tmp = _M_ptr;
       #22 _M_ptr = 0;
       #23 return __tmp;                }
         //上面已经详解     
 
       #24 void reset(_Tp* __p = 0) __STL_NOTHROW {
       #25 delete _M_ptr;
       #26 _M_ptr = __p;                          }
         //
         //传入对象指针,改变auto_ptr维护的对象
         //       且迫使auto_ptr消除原来维护的对象
         //       见ok3用法.

         // According to the C++ standard, these conversions are required.  Most
         // present-day compilers, however, do not enforce that requirement---and,
         // in fact, most present-day compilers do not support the language
         // features that these conversions rely on.
        
         //下面这片段用于类型转化,目前没有任何编译器支持
         //具体技术细节不诉.         

         #ifdef __SGI_STL_USE_AUTO_PTR_CONVERSIONS

      #27 private:
      #28 template<class _Tp1>
      #29 struct auto_ptr_ref { _Tp1* _M_ptr; auto_ptr_ref(_Tp1* __p) : _M_ptr(__p) {}
                             };

      #30 public:
      #31 auto_ptr(auto_ptr_ref<_Tp> __ref) __STL_NOTHROW
                               : _M_ptr(__ref._M_ptr) {}
      #32 template <class _Tp1>
      #33 operator auto_ptr_ref<_Tp1>() __STL_NOTHROW
      #34 { return auto_ptr_ref<_Tp>(this->release()); }
      #35 template <class _Tp1> operator auto_ptr<_Tp1>() __STL_NOTHROW
      #36 { return auto_ptr<_Tp1>(this->release()); }
      #37 #endif /* __SGI_STL_USE_AUTO_PTR_CONVERSIONS */
      #38 };
     
      OK!就是这样了.
      正如上面原理介绍处叙说,
      你需要正视两大特性：
      1.构造栈对象的生命期控制堆上构造的对象的生命期
      2.通过release来保证auto_ptr对对象的独权.
     
     在我们对源码分析的基础上,重点看看：
     no系列错误在何处?
     no1.
         我们看到构析函数template<class _Tp>
                         ~auto_ptr() _STL_NOTHROW
                        { delete _M_ptr; }
         所以它不能维护数组,
         维护数组需要操作：delete[] _M_ptr;
     no2.
        先提部分vector和auto_ptr代码：
        a.提auto_ptr代码
         
        auto_ptr(auto_ptr& __a) __STL_NOTHROW : _M_ptr(__a.release()) {}
       
        b.提vector代码
         
          Part1:
          void push_back(const _Tp& __x) {
          if (_M_finish != _M_end_of_storage) {
          construct(_M_finish, __x);
          ++_M_finish;
          }
          else
         _M_insert_aux(end(), __x);
          }
       
         Part2:
         template <class _T1, class _T2>
         inline void construct(_T1* __p,

         //++++++++++++++++++++++++++++++++
         //         const _T2& __value) { +
         //++++++++++++++++++++++++++++++++
         //  new (__p) _T1(__value);      +
         //++++++++++++++++++++++++++++++++

         }
        
         Part3.
         template <class _Tp, class _Alloc>
         void
         vector<_Tp, _Alloc>::_M_insert_aux
         (iterator __position,

          //++++++++++++++++++++++++++++++++
          //        const _Tp& __x)       ++
          //++++++++++++++++++++++++++++++++  
 
         {
         if (_M_finish != _M_end_of_storage) {
         construct(_M_finish, *(_M_finish - 1));
         ++_M_finish;

         //++++++++++++++++++++++++++++++++
         //     _Tp __x_copy = __x;       +
         //++++++++++++++++++++++++++++++++

         copy_backward(__position, _M_finish - 2, _M_finish - 1);
         *__position = __x_copy;
         }
         else {
         const size_type __old_size = size();
         const size_type __len = __old_size != 0 ? 2 * __old_size : 1;
         iterator __new_start = _M_allocate(__len);
         iterator __new_finish = __new_start;
         __STL_TRY {
         __new_finish = uninitialized_copy
         (_M_start, __position, __new_start);
         construct(__new_finish, __x);
         ++__new_finish;
         __new_finish = uninitialized_copy
        (__position, _M_finish, __new_finish);
        }
        __STL_UNWIND((destroy(__new_start,__new_finish),
                  _M_deallocate(__new_start,__len)));
       destroy(begin(), end());
       _M_deallocate(_M_start, _M_end_of_storage - _M_start);
       _M_start = __new_start;
       _M_finish = __new_finish;
       _M_end_of_storage = __new_start + __len;
       }
       }

       从提取的vector代码,Part1可看出,push_back的操作行为.
       兵分两路,可是再向下看,你会发现,无一例外,都
       通过const _Tp& 进行拷贝行为,那么从auto_ptr提出的片段就
       派上用场了.
       可你知道的,auto_ptr总是坚持对对象的独权.那必须修改
       原来维护的对象,而vector行为要求const _Tp&,这样自然会产生
       问题.一般编译器是可以发觉这种错误的.

       其实,STL所有的容器类都采用const _Tp&策略.
 
       //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
      + 看了sutter和Josuttis的两篇文章中,都提及：                    +
      + STL容器不支持auto_ptr原因在于copy的对象只是获得所有权的对象, +
      + 这种对象不符合STL的要求.可是本人总感觉即时不是真正的复制对象,+
      + 但我用vector<auto_ptr<x> >的目的就在于维护对象,并不在乎      +
      + 所谓的完全对象.而且我用自己写的Smart Pointer配合STL容器工作, +
      + 很正常.那需要注意的仅仅是const问题.                          +
      +                                                              +
      //++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

     no3.
        这个也是auto_ptr隐含的所有权问题引起的.
        const auto_ptr不允许修改.
        随便提及：const对象不代表对象一点不可以改变.
                  在两种const语义下,都有方法修改对象或对象内部指针维护的对象
                 或其它资源.
     no4.
        再看auto_ptr的构析函数.
        delete不可以消除栈上资源.

     no5.
        依赖传入对象指针的构造函数被声明为explicit,禁止隐式转换.

   
    3.auto_ptr高级使用指南
     
      a.类成员auto_ptr,禁止构造函数以构建"完全对象"
        Programme1:
        struct Structx{
               int m_Idata;
               char m_CHRdata;
               /* and so on */
        };
        出于对象编程的理念,
        我们将Structx打造成包裹类：
        class StructWrapper{
        private:
        Structx* m_STRTxptr;
        public:
        StructWrapper():m_STRTxptr(new Structx){}
        ~StructWrapper(){delete m_SMRTxptr; }
        public:
        void Soperator1(){ /* 针对Structx对象的特性操作 */}
        void Soperator2(){ /* 针对Structx对象的特性操作 */}       
        /*  and so on */
        };
       
        Programme2:
        class StructWrapper{
        private:
        auto_ptr<Structx> m_SMPTRx;
        public:
        StructWrapper():m_SMPTRAx(new Structx){}
        public:
        void Soperator1(){ /* 针对Structx对象的特性操作 */}
        void Soperator2(){ /* 针对Structx对象的特性操作 */}       
        /*  and so on */
        };
       
        Programme3:
        StructWrapper::StructWrapper(const StructWrapper& other)
        : M_SMPTRx(new Struct(*other.m_SMPTRx)) { }
        StructWrapper& StructWrapper::operator=(const StructWrapper &other){
        *m_SMPTRx = *other.m_SMPTRx;
        };

        处于对构建于堆中的对象(new Structx)智能维护的需要.
        我们将programme1改造为programme2：
        不错,对象是可以智能维护了.
        对于包裹类(StructWrapper)你是否会有这样的构造或指派操作：
         StructWrapper m_SMPTRWrapper2(m_SMPTRWrapper1);
      
         StructWrapper mSMPTRWrapper2 = m_SMPTRWrapper1;
         那么请注意：
         当你坦然的来一个：M_SMPTRWrapper1->Soperator1();的时候,
         系统崩溃了.
         不必惊讶,所有权还是所有权问题.
         问一下自己：当programme2默认拷贝构造函数作用时,又调用了auto_ptr的
         默认构造函数,那么auto_ptr所有的默认行为都遵循独权策略.对,就这样.
         m_SMPTRWrapper1的对象所有权转移给了m_SMPTRWrapper2.
         M_SMPTRWrapper1->Soperator1();那么操作变成了在NULL上的.
         哦!系统不崩溃才怪.
         那么你需要想,programme3那样利用auto_ptr的提领操作符自己的
         构造"完全对象".

       b.利用const关键字,防止不经意的权限转移
        
         从上面的叙述,你可看出,所有权转移到处可以酿成大祸.
         而对于一般应用来说,独权又是很好的安全性策略.
         那么我们就用const来修饰auto_ptr,禁止不经意的错误.
       
         当然上面提及：并不代表auto_ptr是不可修改的.
         处于需要,从两种const语义,你都可实现修改.

         然,你还希望在函数传入传出auto_ptr那么你可传递auto_ptr的引用,
         那就万无一失了: void fook(const auto_ptr<x>& m_PARAMin);
         在返回后赋予其它时,使用引用是不行的.你得用指针.
         因为引用无论作为lvalue还是rvaluev,都会调用构造或指派函数.

    4.你是否觉得std::auto_ptr还不够完美
     
      在实践中,std::auto_ptr能满足你的需求吗?          
 
      Andrei Alexandrescu在一篇文章中,提及：有关Smart Pointer的技术就像
      巫术.Smart Pointer作为C++垃圾回收机制的核心,它必须足够强大的、具有工业强度和安全性.
      但为了可一劳永逸我们还需要披荆斩棘继续探索.

      下面在需求层面上,我们思索一下我们的智能指针还需要些什么?
 
        a. std::auto_ptr 能够处理数组吗?我们可以用智能指针来管理其它的资源吗?
           譬如一个线程句柄、一个文件句柄 and so on !
        b. 对于我们的对象真的永远实行独权政策吗?
        c. Our 智能指针还需要在继承和虚拟层面上发挥威力 !
        d. 往往,需要扩展Our 智能指针的功能成员函数来满足动态的需要 !
        e. 也许,你需要的还很多.

---------------------------------------------------------------
                       [下续]

二、C++条件,寻找构造更强大的智能指针(Smart Pointer)的
    策略
   
    1.支持引用记数的多种设计策略
    2.支持处理多种资源
    3.支持Subclassing
    4.支持多线程条件下,线程安全的多种设计策略
    5.其它多种特殊要求下,再构造

三、Generic Programming基础技术和Smart Pointer
    1.回首处理资源中的Traits技术
    2.回首多线程支持的设计

四、COM实现中,Smart Pointer设计原理

五、著名C++库(标准和非标准)中的Smart Pointer现状

-----------------------------------------------------------

--------------------------------------------------------------
                          郑重声明：
                 允许复制、修改、传递或其它行为
                 但不准用于任何商业用途.
                      写于  20/3/2003
                      最后修改： 20/3/2003
                         By RedStar81
                      81_RedStar@163.com
-------------------------------------------------------------