映射表类（CMap）是MFC集合类中的一个模板类，也称作为“字典”，就像一种只有两列的表格，一列是关键字，一列是数据项，它们是一一对应的。关键字是唯一的，给出一个关键字，映射表类会很快找到对应的数据项。映射表的查找是以哈希表的方式进行的，因此在映射表中查找数值项的速度很快。映射类最适用于需要根据关键字进行快速检索的场合，我们的程序中就用映射表来保存计时器标志值和类实例指针，用计时器的标志值作为关键字。 他这个有点像数组，比如你要查找a[index]，不必先遍历前面的index个元素，只不过数组的下标是哈希表键值，它是以键值对的形式出现的。
举例如下：
1、定义一个CMAP，向这个CMAP中增加数据项（键-值对）。
CMap<CString, LPCTSTR, CString, LPCTSTR>m_ItemMap;
CString strKey = _T(""), str = _T("");
int i;
for(i = 0; i < 5; i++)
{
strKey.Format("%d", i); //这个是键
str.Format("A%d", i); //键对应的值
m_ItemMap.SetAt(strKey, str);
}
2、遍历整个CMAP的常用方法。
POSITION pos = m_ItemMap.GetStartPosition();
while(pos)
{
m_ItemMap.GetNextAssoc(pos, strKey, str);
cout<< strKey<< ":"<< str<< endl;
}
3、在CMAP中查找相应的数据项。
CString pReset;
if(m_ItemMap.Lookup("1", pReset))
{
cout<<pReset<<endl;
}
偏题三千里，言归正传。
至于C++的性能，似乎一直被OOP的性格所掩盖，而OOP主张的面向对象编程，更让许多窃窃私语的程序员有了足够的底气发言，同时他们宣称，C++显然就是应该由对象统治的世界，其实--大错特错，简直错的一败涂地。C++，归根结底，还是由指针执政，以致我们可以直接的操纵内存，直接和系统底层会话，并且还能实现我们空前强大的令人炫目的多态。所以，我们必须要利用这个得天独厚的资源。
偏题一千里，再言归正传。
现在，我已经知道，直接在C++程序中使用对象，是何等的不专业，显然，我们更应该使用指针，曾经有一位高人，不无自我解嘲的说，他写程序的第一年连一个指针都不敢用，后来又在他的婴幼儿奶粉级的大作中大肆声讨指针，可想他曾经遭受了指针怎样的折磨。
在程序中使用指针，几乎可以使你的程序恢复到C的性能级别，显然我不会回避你正在思考命题，不错，C的性能的确要高于C++，而汇编语言的性能显然要进一步的高于C，只要学过一点编译原理的人，应该不会反对这个早已过时的辩论焦点。关键在于，从C过度到C++，已经是一种编程思维的转变。然而很多人，既没有继承C的高性能性，又未能领悟C++的封装、继承与多态性，却妄图从C直接飞到C++上，却被挂在了C与C++的中间，左右为难，大概停留到了C+这门语言去了。
言归正传。
我们在定义函数的时候，应该尽可能的少传对象，而更应该传指针或者引用，我们知道对于编译器内部来说，引用其实就是一个指针。这最主要的原因是，我们不必再为函数参数的圧栈而苦恼不已；同样，我们也不应该在函数结束之后，用对象来返回，这同样增加了函数圧栈的开销，而更应该适可的返回一个指针或者一个引用，当然，这样的指针和引用，绝对不能指向一个函数体内的临时对象。然而传入CMap中的类型参数，到底应该是什么，这似乎已经上升到了算法的层次，从而使我们对于实化本身的讨论变的毫无意义。
我也许会主张，将CMap实化成这种模样：
typedef CMap<CString*, CString*, CString*, CString*> CStrPtrMap;
个中缘由，当然还是出于对效率的考虑，我们在SetAt之前先new出一个CString对象，然后将其填入CStrPtrMap，这样的好处在于我们在SetAt的时候不需要去调用CString的赋值构造函数，而仅仅作简单的数据拷贝，这样的行为几乎适合所有的复杂数据结构，包括类，结构体。当然，唯一不能忘记的是，必须在必要的时候释放那些new出来的CString对象，否则，将会导致严重的内存泄露！
当然，你可以根据自己的兴趣，去总结到底应该选择怎么样的KEY与ARG_KEY。由于一般来说，KEY都不可能是太大的字符串，从而为了兼顾效果与效率，作为一种折中的方案就是定义这样的一个类似于字典的CMap实化类：
typedef CMap<CString, LPCTSTR, CString*, CString*> CStrPtrMap;
啊，这又是一个长着人身猪脸的八戒啊！不过，既然要去西天取经，八戒就八戒吧。
当然，千叮万嘱的还是，别忘记释放为CString*申请的内存！至于另外两个模板的参数选择，基本上大同小异，并且要比CMap简单，就不再罗嗦了。
-----------------------------------------------------------------(第三部分)---------------------------------------------------------------------------------------------
显然，CMap就是对Hash表的一种实现。对于Hash表来说，我们需要提供成对的Key与Value进行操作，其实，也就是将我们日常使用的数组下标替换成现在Key，至于MFC是采用了什么样的散列函数，我们不必知道。
Hash表可以认为是数组的一种优化，或者说是对数组缺陷的一种弥补，因为我们知道，数组在具备了高效存取性能的同时，无法动态的调整自身的大小，又严重的影响了它的使用效果。这给了Hash表可乘之机，Hash表总是使用了某种算法尽可能的来达到将成对的元素存储到一个额定的离散的内存空间，它既继承了链表对自身的动态调整，又尽可能的使读写维持在高速的水平，当然无论如何还是要比数组慢的多。
现在，我们来看一个CMap的用法，下面是我自己编写的例子：
class Point
{
public:
Point()
{
m_x = 0;
m_y = 0;
}
Point(int x, int y)
{
m_x = x;
m_y = y;
}
public:
int m_x;
int m_y;
};
typedef CMap<const char*, const char*, Point, Point&> CMapPnt; //请在使用之前定义
int main()
{
Point elem1(1, 100), elem2(2, 200), elem3(3, 300), point;
CMapPnt mp;
// insert 3 elements into map， #1
mp.SetAt("1st", elem1);
mp.SetAt("2nd", elem2);
mp.SetAt("3th", elem3);
// search a point named "2nd" from map #2
mp.Lookup("2nd", point);
printf("2nd: m_x: %d, m_y: %d\n", point.m_x, point.m_y);
// insert a new pair into map #3
Point elem4(4, 400);
mp["4th"] = elem4;
cout<<"count: "<<mp.GetCount()<<endl;
// traverse the entire map #4
size_t index = 0;
const char* pszKey;
POSITION ps = mp.GetStartPosition();
while( ps )
{
mp.GetNextAssoc(ps, pszKey, point);
printf("index: %d, m_x: %d, m_y: %d\n", ++index, point.m_x, point.m_y);
}
return 0;
}
代码中，我已经给出了一些注释，我同样建议读者们，用英文在代码中注释，这样的好处实在是太多了。尤其在代码需要在不同编码的操作系统上调试的时候。
对于CMap这个类，我不得不着重啰嗦一下的是：遍历操作以及取下标[]操作，当然还有那个令很多人困惑不已的ARG_KEY到底应该如何选择的问题。
遍历，看注释#4，先使用GetStartPosition()函数获得表头的位置，然后，我们可以使用GetNextAssoc函数来遍历。GetNextAssoc(POSITION& rNextPosition, KEY& rKey, VALUE& rValue)函数的参数值得说明一下，大家看到，3个参数都是引用，而第一个是rNextPosition，顾名思义，在函数返回之后，它将会指像下一个元组，当然这是在表还未遍历完的时候，否则，它将被置为空（NULL）。[]下标取元素的这个操作符，在CMap中被重载，用来返回指定Key值数据的引用，不过在注释#3处，对于先取"4th"这个Point的引用然后赋值的用法，看起来，似乎有点聪明过了头，因为在这之前，我们还没有插入"4th"所对应的元组，但是，程序却能正常的运行！为什么？其实，这样的用法是十分正确的，因为CMap毕竟不是数组，它是没有边界的，当CMap在获得一个它无法查询到的Key值的时候，它会将这个Key以及一个空的数据类型追加到Hash表中去，从而保证了上面的程序可以无误的运行。
我们已经说过，ARG_KEY是作为类型参数传入CMap的，但并不是任何类型都可以作为ARG_KEY传入的。为什么？看样子，这次不得不简单的说说Hash表的散列函数了。每个Hash表，总会使用一些散列函数，用来查找Key所对应的Value，理想状态下，我们当然希望Hash表，就是一个数组，虽然这不可能，不过这样理解，可以帮助我们更好的理解Hash表的物理结构，就让我们暂时把它看成一个数组吧。数组总是使用下标来直接获取元素的存储地址，而下标，显然应该是个非负整数，从而Hash表，也应该具备这样的特性，至少必须存在某种算法可以使传入的Key可以直接的转化为一个非负的整数，这也就是ARG_KEY的选择标准。从而对象、引用无论如何都不应该作为ARG_KEY成为CMap的类型参数，而int、unsigned int、指针以及地址就成为了ARG_KEY的常用类型参数，其实也就是那些类似于整型的数据类型。常常看到一些人在用CMap的时候，试图使用CString作为CMap中ARG_KEY的类型参数，这是应该被纠正的方向性错误，但有些人似乎会理直气壮的反驳我，因为他们发现类型参数KEY是可以使用CString的，这很奇怪吗？我说过KEY不能使用CString吗？之所以KEY可以使用CString而ARG_KEY却用的是LPCTSTR，那是因为CString重载了operator==(const char*)这个判等操作符，当CMap从Hash表中获得KEY之后，它会将ARG_KEY与KEY直接相比较(本人理解为：怕“==”被重载后影响判断)。真正存于CMap内部的是KEY，也就是CString。这也就是为什么，我们经常会看到CMap被实化成CMap<CString, LPCTSTR/*相当于const char*，非Unicode情况下*/, CString，CString&>这样的一个四不像实化类的原因，至于CMap的效率优化问题，我们会在以后的文章中继续与大家探讨。
CMap的确是个很不错的数据结构，尤其在你建立一个字典的时候。
/7 
