flushthink

总结的不错

羡慕死人了，我07年才开始接触电脑编程。

坚强起来，做出点成绩给父亲看看。让他放心。

@viewer
脚本你编译了吗？你是用all的那个工程吗？

goodjob

@viewer
mapviewer
http://wowmapviewer.googlecode.com/svn/trunk
modelviewer
http://wowmodelviewer.googlecode.com/svn/trunk

goodjob

@sqd
要用 svn工具下载

@sqd
这个还是比较稳定的，可以下载下来，测试看看，据说很多商业的sf都是用这个做的。

@xiao_liang
好像不行吧，一般放在cpp的东西都是运行时实现，而模板类或模板函数的实现内容是对某一类型的抽象实现。实现还不存在，在编译的过程中才会发现需要哪些具体类型的运行时实现。

@xx
你对mangos，那些地方怀疑，方便说下嘛？

@xx
这个效率相对来说还是比较高，最起码比mangos高。

@xx
据说单台千人左右。

次级的程序员不懂oo，还老说oo没用。
初级的程序员了解了oo，乱用oo。
中级的程序员理解了oo，用的恰到好处。
高级的程序员心中有oo，却不愿表现出oo来。
神级的程序员完全不懂oo，他用计算机思维解决问题。

程序员分两种：天赋异秉的，浑浑噩噩的。

去看boost的模板元吧。比loki舒服

gluPerspective，gluOrtho，这些都是通过传入的那些参数，变换成一个矩阵，这个矩阵可以叫投影矩阵。gluPerspective表示投射投影，gluOrtho正交投影。理解的不错。

so cool 未来的软件大师。

好样的，一起学习。

qsort
实现的太过简单。。。。。。没啥实际价值。

@foxriver
是的，旋转不还是保证了方向性，而没有保证他的位置性吗？

作者对面向对象的思想理解深刻，面向对象并不一定要用c++，java，c#写。c依然可以写出漂亮的面向对象来（这点我从linux源码中发现，而且它的面向对象抽象基本是零消耗的，但需要很深厚的功底来完成一些技巧），面向对象很好理解，程序的本质还是过程式，所以要把握住对象构造到析构的主干线，理解软件体系中的线程模型。而且对象的抽象要多加思考，是否真的需要抽象这类对象，抽象这类对象是为了什么？能否用聚合组合来替代？过于臃肿的类体系结构扩展性受到影响，而且会增大对象占用空间，明白什么时候upcast，什么时候downcast。好的面向对象抽象一样可以提高效率，而且有时候用好c++效率还会比c高（因为在真正代码执行期间，cpu通过ecx知道c++的类对象上下文），尽量减少或避免虚表重复查找次数。面向对象是一潭深水啊，掉进去一定要出来。

不是每个人都明白奋斗是什么？就

这个每个做程序的，都是这么想的吧？

架构师不只是用uml去画图，也要考虑代码实现，架构师已死不合理，该死的是画出来乱七八糟看似容易而自己不能却妄想别人为他实现的架构师。这种架构师自认为读过二年书，思维比人灵活，实际则饭桶一个。

不过这个改进比较担心。随机数一次多少指令？
首要做的可能是把递归算法改成非递归的。
针对元素低于8个的时候，用插入排序。
下面就是尽可能地让分区平衡。
一个好的快速太难了。

第一题答案对吗？#define Max(a,b) (a/b)?a:b
a = -2, b = -1
这个问题不是这么简单的吧。
考虑到正负数，考虑到无符号情况

gimp用的不咋地啊。

good job!!

good job!!!

good job!! recently, referring to mit's introduction to algorithms. just for basic.

bjam --toolset=msvc-8.0 --link=static --runtime-link=dynamic --threading=multi --with-system --with-regex stage

it's ok

bjam use 3.1.7 ver

我做过，而且在d3d里实现了directshow和cegui界面共同显示。

这些东西没必要去玩，纯粹是瞎胡闹，看到这样做做的代码，只能丢下句：写这样代码的人，只能去当老师。

不同意，没看完你的文章。因为你没理解真正的协作。矛盾是进步的源泉，并不一定，观点完全是你提出的，完全就是你一个人的战场。战场上除了需要纯粹浴血奋战，还需要战略方针，衣食住行，甚至敌我间谍。
队伍不能协作好，只可能是水平参差不齐，目标不统一，内忧外患。

good!!!

bu cuo

不如专门抽象出一个抽象类，比如StateMachine，然后Player持有StateMachine的指针来控制Player的状态切换。

我感觉你这样没有拓展性，用fsm来更好点，首先对于player来说，应该是从GameObject泛化而来的。

用ogre开发不是那么简单的，我感觉，ogre只给你提供了图形渲染引擎，如果你要使用ogre进行游戏开发，就必须对ogre进行封装，而封装的过程你还需要游戏运行环境，游戏对象属性、操纵方法、事件处理等，数据序列化，如果要是mmo的话，你可能还需要对仿真模拟，进程间通信，线程模型等做一系列工作。
如果用xna的话，说实话，没用过xna，c#是动态语言，需要运行时支持效率不知道如何？但是我想微软既然推出他，效率这方面就不需要特别考虑。
反正做游戏不是那么简单的，不管用xna还是ogre，但是我相信用xna比用ogre来的简单，就算你没学过c#。

很受鼓舞。我也比较喜欢李小龙。