说明一下 monkeyispig.com 是本人自己的blog，发在cppblog只为增加人气 ：）所以没有全文转载，转个引子请大家点击一下：


     摘要: 新手在刚接触一些实际项目的遗留代码时会觉得很迷茫（比如我）。相信过来人都知道这种感受——代码量大、注释少、难读懂。这只是最肤浅的认识，随着接手任务需要在代码上做添加和修改的时候那就真的是更难以下手了。一方面是对代码不熟悉，另一方面则是代码已经被修修补补得十分混乱了。  阅读全文      摘要: 场景管理是游戏中非常重要和基础的部分，初次接触场景管理是使用了Ogre中的场景管理器(SceneManager)。其中的场景节点(SceneNode)便是非常好用的一套用于表示场景位置关系的抽象。纵观Ogre的实现，SceneNode是继承与Node类，Node类则主要实现了空间位置关系的操作。

在2D游戏中，同样需要一套犹如SceneNode的场景管理节点，那么如何实现和设计一套用于2D的节点来调整空间关系呢？
  阅读全文      摘要: PyOgre安装以及如何使用Blender导出Ogre的Mesh。  阅读全文      摘要: 蛮喜欢这句话的，当生活中总是充满了各种抱怨的时候，这句话总是让人耳目一新。
当我们抱怨的时候，为什么不动手去改变它呢？有人说太迟了，what's done is done!
反过来思考这个问题，很多事情都已经成了定局才让我们抱怨和后悔，那之前做这些事的时候，或许就没有用正确的方式来做才造成了现在的样子。  阅读全文      摘要: vim, ctags, taglist 的一些基本使用方法的记录～  阅读全文      摘要: 游戏主循环是每个游戏的心跳，输送着整个游戏需要的养分。不幸的是没有任何一篇好的文章来指导一个菜鸟游戏程序员如何为自己的程序供养。不过不用担心，因为你刚好不小心看到了这篇，也是唯一一篇给予这个话题足够重视的文章。

由于我身为游戏程序员，我见过许许多多的手机小游戏的代码。这些代码给我展示了五彩缤纷的游戏主循环实现方法。你可能要问：“这么简单的一个小玩意还能做到千奇百怪？” 事实就是这样，我就会在此文中讨论一些主流实现的优缺点，并且给你介绍在我看来最好的输送养分的解决方案。  阅读全文      摘要: 今天实训的某同学给我看了一段简单的代码，蛮有意思~数组不是越界了么？为什么结果还是正确的呢？  阅读全文 问题是这样的，这个“项目”经历了种种变更，目前需求定格在3D动作类游戏上。
在游戏引擎制作的过程中遇见了现在这样的问题：

某从业人员即一位有经验的XNA开发者告诉我们小型游戏利用XNA来做会比较有效率（相对后一种方案）。
不过现在问题出在对.Net，XNA都不是十分熟悉，去使用XNA必然又比较大的学习代价。

后一种方案：使用OGRE+各种游戏引擎中还需要的其他类库来做自己的游戏引擎
相对于.NET C# XNA，C++应该在语言的熟悉程度上更好一些
OGRE也接触了一些，不算熟悉，但是也能了解基本运用
也就是后者可能在整合的方面会遇见一些更实际的问题，但是大体还熟悉

而前者XNA是一个不错的游戏开发框架，但是却需要付出学习代价

后者的问题…… 其实我也只是听同学提到一个很模糊的说法：“在后期会遇见一些麻烦”
这个说法也是前文中的那位从业人员给我同学的说法。
而实际上，我更倾向于的是后面这种解决方案~
因为从自己的知识层面和项目组成员的知识层面上来说，C++还是比C#要熟悉一些
OGRE对于一个基本完全未知的XNA药熟悉一些。

希望有相关开发经验的大大能够来帮忙解决下心中的疑惑！到底是用XNA+.NET还是OGRE+C++
游戏规模是中小型，平台现在由于各种原因限制在Windows上
这两套解决方案到底孰优孰劣？好又好在什么地方，缺点又有一些什么？
实际应用上，会出现很棘手的麻烦么？

我自己也深知在这种解决方案上去徘徊远不如静下心选定一个方案去解决现实世界的问题来得实际。
不过我自己心中有一个“潜选择”，我怕前者真的是一套好的方案却被放弃掉

希望各位大大支招，谢谢了~！

写了几天代码，怕自己没头没脑一直写下去
还是乖乖的跑去图书馆看书

下面都是一些片段，都是自己觉得有意思的地方，所以还是记下来比较好

TC++PL 15.4.5
Object过于一般，因为它并不对应于应用领域中的任何抽象，还迫使应用程序员去使用一个实现层的抽象。解决这类问题的更好方式是使用容器模板，在其中只保存某一类指针……

TC++PL 15.5
然而，一个指向成员的指针并不像指向一个变量或者指向一个函数的指针，它并不是一个指向一块内存的指针。这种指针更像是一个结构里的偏移量，或者到一个数组里的下标。

这也很好的解释了

typedef (Class::*mem_fun_ptr)(argus..);
的mem_fun_ptr要和一个class的实体结合使用…… 就像把这个 偏移量 施加在这个 结构体 上

mem_fun_ptr mfptr = &Class::one_mem_fun;

Class *p = new Class;
Class instance;

(p->*mfptr)();

TC++PL 18.4.4.1
注释中的 Curring化 正是OwnWaterloo学长正在做的callback_curring ..

f(x,y) 看作 f(x)(y)

TC++PL 17.4.1末尾

std::map::inserat(val)返回std::pair<iterator,bool>
如果val被实际插入（可能由于已经存在的key不能插入）那么bool为true。迭代器引用的是map中的一个元素，
它保存着val的关键吗val.first。

TC++PL 17.4.2
关于multimap中查找某key得到的返回值

void print_numbers(const multimap<string,int>& phone_book)
{
    typedef multimap<string,int>::const_iterator I;
    pair<I,I> result = phone_book.equal_range("name");
    for (I i = result.first; i!=b.second; ++i) cout<<i->second<<endl;
}

关于tri的hash_map，boost是一个好东西
相对于utility pack来升级支持tr1使用boost反而有更好的移植性
#include <boost/tr1/unordered_map.hpp>

std::tr1::unordered_map<key_type,val_type> hashmap;

TC++PL 17章忠告中第10条
尽量使用最小的操作集合，以取得最大的灵活性

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

标准库容器中的元素必须可以复制
在使用 noncopyable 的时候应该注意这一点