在我自己写的一个工厂类实现中，每个产品会注册创建接口到这个工厂类。工厂类使用这些
注册进来的创建接口来完成产品的创建。其结构大致如下：

product *factory::create( long product_type )
{
    creator c = m_creators[product_type];
    return c();
}

factory::instance().register( PRODUCT_A_TYPE, productA::create );
...
factory::instance().create( PRODUCT_A_TYPE );

这个很普通的工厂实现中，需要写上很多注册代码。每次添加新的产品种类时，也需要修改
这些的注册代码。而恰好，这些注册代码可能会被放在一个统一的地方。为了消除这个地方
，我使用了偶然间看到的<Modern C++ design>里的做法：

const bool _local = factory::instance().register( PRODUCT_A_TYPE,...

也就是说，通过对全局常量_local的自动初始化，来自动完成对该产品的注册。

结果，因为这些代码全部被放置于一个静态库。最终的代码文件结构大致为：

lib
    - product_a.cpp : 定义了全局常量_local
    - product_a.h
    - factory.cpp
    - factory.h
exe
    - main.cpp

现在看起来世界很美，因为factory甚至不知道世界上还有个跟上层逻辑相关的product_a。
这种模块耦合几乎为0的结构让我窃喜。

悲剧的事情首先发生于，开VC调试器，发现打在product_a.cpp里的断点失效。就是那个总
是提示说没有为该文件加载调试符号。开始还不在意，以为又是代码和调试符号文件不匹配
的原因，折腾了好久，不得其果。

后来分析了下，发现这个调试提示，就像我开着调试器打开了一个非本工程的代码文件，而
断点就打在这个文件里一样。也就是说，VC把我product_a.cpp当成不是这个工程里的代码
文件。

按照这个思路写些实验代码，最终发现问题所在：VC链接器根本没链接进product_a.cpp里
的代码。表现出来的情况就是，该编译单元里的全局常量（全局变量一样）根本没有得到初
始化，因为我跟到factory::register并没有被调用到。为什么VC不链接这个编译单元对应
的目标文件？或者说，为什么VC不初始化这个全局常量？

原因就在于，product_a.cpp太独立了。一个在整个编译链接阶段都无法确定该文件是否被
使用的文件，VC就直接不链接了。相反，当在factory.cpp里写下类似代码：

void test()
{
    product_a obj;
}

虽然说test函数不会被调用，一切情况也变得正常了。好了，不扯了，给最后我的结论：

1、如果静态库中某个编译单元在编译阶段被确认为它并没有被外部使用，那么当这个静态
库被链接进可执行文件时，链接器忽略掉该编译单元里的代码，那么，链接器自然也不会为
该编译单元里出现的全局变量常量生成初始化代码（关于这部分初始化代码可以阅读
<linker and loader>一书）；
2、上面那条结论存在一种传染性，意思是，当可执行文件里的代码使用到静态库中文件A里
的代码，A里又有地方使用到B里的代码，那么B依然会被链接。这种依赖性，应该可以让编
译器在编译阶段就发现（显然，上面我举的例子里，factory只有在运行期间才会依赖到
product_a.cpp里的代码）

这个内存泄露工具最基本的原理就是利用宏替换掉标准的malloc、free（暂不考虑其他内存分配函数，
如realloc、strdup），记录下每次内存分配和释放动作。因为宏的处理发生在预处理阶段，所以可以
很容易地用你自己的malloc函数替换掉标准的malloc。例如：

/**//* lib.h */
#define malloc my_malloc
#define free my_free 

/**//* lib.c */
/**//* disable these macro in this compile unit */
#undef malloc
#undef free 

static int count = 0; 

void *my_malloc( size_t size )
{
    ++count;
    return malloc( size );
} 

void my_free( void *a )
{
    --count;
    free( a );
} 

要使用以上代码，用户在使用时就需要包含lib.h，从而可以使用宏将用户自己写的malloc替换
为my_mallo。当程序退出时，如果count大于0，那么可以肯定的是有内存泄露。当然，如果
count为负数，则很可能对同一个指针进行多次free。

但是以上代码的功能太局限了。一个真正的内存泄露检测库（工具），至少需要报告泄露的代码
文件、函数、行数等信息。当然，如果能报告调用堆栈，就更好了。不过这就依赖于具体的平台，
需要使用特定的系统接口才可以获取出。

要实现以上功能也很简单，只需要在每次调用malloc的时候，通过编译器预定义宏__FILE__、
__LINE__、__FUNCTION__(__func__)就可以得到文件名、函数、行号等信息。将这些信息保存
起来，然后在free的时候移除相应的信息即可。

最简单的实现方式，就是保存一个表，表里记录着每次分配内存的信息：

struct memRecord
{
    char file[MAX_FILE_NAME];
    char func[MAX_FUNC_NAME];
    size_t lineno;
    void *address;
    size_t size;
}; 

struct memRecord mem_record[MAX_RECORD]; 

但是，通过单单一个free函数的void*参数，如何获取出对应的分配记录呢？难道：

for( size_t i = 0; i < MAX_RECORD; ++ i )
{
    if( address == mem_record[i].address ) 
    {
        /**//* shit */
    }
} 

虽然可行，但是很stupid。这里提供一个小技巧：

void *my_malloc( size_t size )
{
    void *a = malloc( size + sizeof( size_t ) );
    return (char*)a + sizeof( size_t );
} 

void my_free( void *a )
{
    /**//* actually, 'a' is not the real address */
    char *p = ((char*)a - sizeof( size_t ) );    
    free( p );
}

意思就是说，我多分配了4字节内存（sizeof( size_t ) ），用于保存这次分配记录在mem_record
中被保存的索引。在释放内存的时候，通过一些地址偏移计算，就可以获取出真正的系统malloc
返回的地址，从而安全释放（别给我说这里的计算存在平台和编译器的限制，没认真看文章的SB才说）。

另一个问题是，我们如何处理每次分配释放时，对于分配记录那个数据结构，也就是mem_record。
每一次free的时候，移除的记录可能位于mem_record的任何位置。一定时间后，mem_record内部
将出现很多漏洞（已经没用的数组位置）。解决这个问题最直接当然还是最stupid的方法，就是每次
free移除记录时重新整理一遍mem_record。如果你这样做了，那你的malloc/free比微软的还慢。

我的解决方法是：
size_t free_index[MAX_RECORD];
用于保存这些出现漏洞的index。每一次free移除记录时，就把这个记录对应的inex保存进来，表示
这个index指向的mem_record[]可用。每一次malloc的时候，先从这里取index，如果这里没有，那
可以直接从mem_record的末尾取。

具体细节就不阐述了，典型的空间换时间方法。整个库很简单，代码100来行。我也只进行过粗略的
测试。我肯定这100来行代码是有问题的，相信自己的代码存在问题是对bug的一种觉悟，哈哈哈。

这个东西只检测C语言的内存泄露，其实要检测C++的也很简单，只需要重载new和delete就可以了。

要放春节假了，在公司的最后几个小时实在无聊，才做了这个东西，前后花了1个多小时，写起来感觉
不错。

struct MyLess
{
    bool operator() ( long left, long right )
    {
        //...
    }
};

DEBUG模式下编译没问题，RELEASE模式下却出现C3848的错误。这就有点奇怪了，如果确实存在语法错误，
那么DEBUG和RELASE应该一样才对。查了下MSDN，C3848的错误是因为const限定符造成的，如：

const MyLess pr;
pr(); // C3848

于是，在operator()后加上const，就OK了。看了下VC std::map相关代码，以为是DEBUG和RELEASE使用了不
同的代码造成。但是我始终没找到不同点。另一方面，就STL内部的风格来看，应该不会把predicator处理
成const &之类的东西，全部是value形式的。奇怪了。

第二个问题，涉及到静态变量。这个东西给我的印象特别深刻，因为以前去一家外企应聘时被问到，当时
觉得那个LEADER特别厉害。回来后让我反思，是不是过多地关注了C++里的花哨，而漏掉了C里的朴素？导致
我至今对纯C存在偏好。

说正题，我现在有如下的文件关系：

// def.h
struct Obj
{
    Obj()
 {
  ObjMgr::AddObj( id, this );
 }
 int id;
};

struct ObjMgr
{
    static void AddObj( int id, Obj *t )
 {
  ObjTable[id] = t;
 }
 static std::map<int, Obj*> ObjTable;
};

static Obj _t;

// ObjMgr.cpp
#include "def.h"

static std::map<int, Obj*>::ObjMgr ObjTable;

// main.cpp
#include "def.h"

这里举的例子可能有点不恰当，我在一台没有编译器的机器上写的这篇文章。忽略掉这些旁支末节。我的意思，
就是想让Obj自己自动向ObjMgr里添加自己。我们都知道静态变量将在程序启动时被初始化，先于main执行之前。

上面代码有两个问题：

一、
代码没有按照我预期地执行，如果你按照我的意思做个测试，你的程序甚至在进main之前就crash了。我假定你
用的是VC，因为我没在其他编译器上试验过。问题就在于，Obj的构造依赖于ObjTable这个map对象。在调试过程
中我发现，虽然ObjTable拥有了内存空间，其this指针有效，但是，map对象并没有得到构造。我的意思是，Obj
的构造先于ObjTable构造（下几个断点即可轻易发现），那么在执行map::operator[]时，就出错了，因为这个时候
map里相关数据还没准备好。

那是否存在某种机制可以手动静态变量的初始化顺序呢？不知道。我最后怎样解决这个问题的？

二、
在还没有想到解决办法之前（不改变我的设计），我发现了这段代码的另一个问题：我在头文件里定义了静态
变量：static Obj _t; 这有什么问题？想想预编译这个过程即可知道，头文件在预编译阶段被文本展开到CPP
文件里，然后，ObjMgr.cpp和main.cpp文件里都将出现static Obj _t;代码。也就是说，ObjMgr.obj和main.obj
里都有一个文件静态变量_t。

看来，在头文件里放这个静态变量是肯定不对的。于是，我将_t移动到ObjMgr.cpp里：

// ObjMgr.cpp
#include "def.h"

static std::map<int, Obj*>::ObjMgr ObjTable;
static Obj _t;

按照这样的顺序定义后，_t的构造居然晚于ObjTable了。也就是说，放置于前面的变量定义，就意味着它将被
首先构造初始化。这样两个问题都解决了。

但是，谁能保证这一点特性？C标准文档里？还是VC编译器自己？

    关于BOOST，撞车，严重撞车。每一次都让我有点无语。
    第一次是我所谓的宏递归，其实就是一个macro library，有一天就不小心在BOOST的library list上
看到了这个东西。当然，BOOST很牛，别人的这个macro是真的library。但是，我们的需求撞车，我们的
实现手段撞车。于是下定决心下次想要实现个什么东西的时候，先去看看BOOST，可以省掉不少脑力。
    本来就没有做好，何必吃力不讨好？
    第二次，当我写下类似的模板代码时：

    template <typename _Tp>
    void func( _Tp t );

    我总要花掉几秒钟时间去决策func的参数是用_Tp&还是_Tp，也就是所谓的究竟是按值传送还是按引用
传送。如果按值传送，当_Tp为一个类时，复制的东西过多时，显然效率上过不去。作为func的实现者，良
心上更过不去。后来一想，STL的各种算法里到处都是按值传送，这样做总有它的理由吧？
    但是，这样做就是不够完美。
    于是想起了boost::ref。但是这个时候我并不知道boost::ref是个什么东西。我只是以前在各种地方
看到过这个东西。我还是决定自己实现一个。
    实现一个什么？考虑有：

    template <typename _Tp>
    void func( _Tp t );

    而我这个时候要传递一个类对象过去CBaseObject obj。为了效率，我写下如下的代码：

    template <typename _Tp>
    class ref_wrapper
    {
    public:
        ref_wrapper( _Tp &p ) : _obj( &p ) { }
        operator _Tp& () { return *_obj; }    
    private:
        _Tp *_obj;
    };

    然后再使用func时，func( ref_wrapper<CBaseObject>( obj ) );这样，发生复制操作的最多就是这
个ref_wrapper，基本上也就是复制了一个指针，而不会复制整个obj。当然，这里可以写一个模板函数去
简化func的调用，如：

    template <typename _Tp>
    ref_wrapper<_Tp> ref( _Tp &t )
    {
        return ref_wrapper<_Tp>( t );
    }

    这样调用的时候就简单了：func( ref( obj ) );
    其实这就是boost的ref库，按照其官方文档，ref库就是：
    The Ref library is a small library that is useful for passing references to function
templates (algorithms) that would usually take copies of their arguments.

    然后我就懵了。于是我不得不在kl_ref.h里写上check out boost::ref for more information的字眼。

    好，接下来说说第三次。
    第三次我遇到了这样一种需求，我需要一个容器，就像你知道的std::list。但是与std::list甚至STL
中所有容器都不同的是，这个容器里保存的东西具有不同的类型。
    这个时候我想起了tuple。我没有实现过tuple。大致上这个东西的实现原理就是利用类型递归来保存
数据，就像loki的type list。另一方面，tuple的尺寸似乎不能动态增长。
    于是我有了自己撇脚的实现：

    class base_type
    {
        virtual ~base_type() { }
    };
    template <typename _Tp>
    class var_wrapper
    {
    public:
        var_wrapper( const _Tp &t ) : _t( t )  {}
        operator _Tp& () { return _t; }
    private:
        _Tp _t;
    };   

    class var_list
    {
    public:
        typedef std::vector<base_type*> TypeList;
    public:
        
        template <typename _Tp>
        void add( const _Tp &t )
        {
            var_wrapper<_Tp> *var = new var_wrapper<_Tp>( t );
            _list.push_back( t );
        } 

        template <typename _Tp>
        _Tp &get( size_t index )
        {
            base_type *base = _list.at( index );
            typedef var_wrapper<_Tp> var_type;
            var_type *var = static_cast<var_type*>( base );
            return *var;
        }
    private:
        TypeList _list;
    }; 

    说白了，我就是利用一个包装类将各种类型包装其中，然后利用基类指针实现统一管理。直白地说，我
对这个组件不满意。让人诟病的是，get接口是类型不安全的。例如：

    int a; 
    CBaseObject obj;
    var_list my_var_list;
    my_var_list.add<int>( a );
    my_var_list.add<CBaseObject>( obj );

    取出值的时候：

    int b = my_var_list.get<int>( 0 );
    CBaseObject cobj = my_var_list.get<CBaseObject>( 1 );

    但是，因为get没有类型检查，即使你：

    CBaseObject cobj = my_var_list.get<CBaseObject>( 0 );

    也不会出错，编译器不会给予你警告。
    事情到此结束，这个类型不安全的组件只能依靠程序员自己的谨慎去生存。

    然后，又是一个不小心，我在boost里看到了any。boost::any库同boost::ref库一样，是一个tiny
library。几十行的代码一目了然。
    boost::any有一个placeholder基类，有一个template <typename ValueType> holder派生类，然后有
一个提供给外部的any类。看了代码后有一种让我喷血的感觉。其实现原理和我自己的完全一致。
    比较而言，我觉得我的var_list撇脚到了极致。因为我封装了容器，而这显然是没必要的，并且限制
了其使用范围。而boost::any则是仅仅封装了类型。
    数据转换方面，boost::any提供了any_cast和unsafe_any_cast。unsafe_any_cast和我这里用的转换
差不多，也就是我说的类型不安全。而他的any_cast呢？则是用到了typeid，多了次类型检查而已。
    没办法，看来var_list需要被删掉，直接搬boost::any过来吧，同样地check out boost::any for more
information...
    现在看来，boost真的很强大。我感觉再怎么偏门的需求，都能在boost里找到个实现。痛定思痛，决定
把boost doc长期开着。

Preface

    本文可能是<代码自动生成-宏带来的奇技淫巧>的续写。我尽力阐述如何让宏递归（或者说重复）地有规律地产生一
些符号，而让我们少写很多重复代码，也许这些代码只有那么一点点的不同。将这项小技巧用于底层库的编写，会让代码
看起来干净不少，同时文件尺寸也会骤然下降。

Problem

    如果你曾经写过functor，那么你肯定对某些代码进行粘贴复制然后修改。更让人郁闷的是，这些代码基本是一样的。
例如，一个典型的functor可能为：

    template <typename Prototype>
    class functor;
    template <typename R, typename P1>
    class functor<R(P1)>;
    template <typename R, typename P1, typename P2>
    class functor<R(P1,P2)>;

    //好，接下去你可能厌烦了，可能会复制一个带有两个参数的functor，然后修改为处理3个参数的。
    这只是一个很简单的问题。宏不是c++里的东西，本文自然也不是讨论各种花哨的模板技术的。如果我之前那篇关于
宏的文章只是让你去分析问题以及更深层次地认识宏，那么现在我将分享我的这部分思想给你。
    关于上面的问题，我们期待得到这样的解决方案：

    template <typename R, DEF_PARAM( 2 )>
    class functor<R( DEF_ARG( 2 ) )>;

    那么，它将自动生成：

    template <typename R, typename P1, typename P2>
    class functor<R(P1,P2)>; 

    也就是说，DEF_PARAM(n)这个宏将根据n值自动生成一串符号，例如DEF_PARAM(2)就生成typename P1, typename P2。
同样，DEF_ARG(n)也会根据参数生成类似于P1,P2,...,Pn的符号串。

思考

    仔细思考下，我们可以看出DEF_PARAM和DEF_ARG这样的宏具有一种递归的特性（其实说成重复可能更合适）：每次展
开的内容基本一样，不断调用自身直到遇到终止条件。
    那么，我们的目标锁定于，用宏来实现递归。

Pre-Implement

    在开始之前，我需要告诉你一些基本的东西：
    在阅读一个宏时，你最好按照预处理的处理方式去逐个展开。当我说到展开时，我的意思是把宏替换为宏体。预处理器
展开宏的过程大致为：如果宏参数也是个宏，那么先将宏参数全部展开，再展开该宏；这个时候会扫描展开后的宏，如果
遇到其他宏，则继续展开。例如有一下宏：

#define PI 3.14
#define MUL_PI( n ) n * PI
#define TWO 2

    当我们写下MUL_PI( TWO )时，预处理发现MUL_PI的参数TWO 是个宏，那么先将TWO展开得到2，然后将2放进宏体展开
得到 2 * PI；预处理器对 2 * PI 进行扫描，发现还有宏PI，于是对PI做展开，得到 2 * 3.14。这个过程是递归的。
    但是也有例外，如果MUL_PI对宏参数进行了#或者##，那么该宏参数不会被展开。（参见以前那篇文章吧）
    任何时候，你可以通过以下宏去查看某个宏展开后的样子，可以方便你调试你的宏：

#define TO_STRING( x ) TO_STRING1( x )
#define TO_STRING1( x ) #x 

    （为什么要写个TO_STRING1，因为这是为了让x充分展开，避免上面提到的那个例外）   

    其他规则我会在文中需要的地方提出来。
实现

    就像大部分介绍递归函数时候给的例子，这里我也将阶乘作为例子。考虑如下典型的阶乘函数：

    int fac( int n )
    {
        if( n == 1 ) return 1;
        return n * fac( n - 1 );
    } 

    其核心部分在于 n * fac( n - 1 )，我们假设我们的宏也可以写成这样的的形式：

    #define FAC( n ) n * FAC( n - 1 )

    但是这样的宏是有问题的：
    当宏被展开时，如果遇到了自身，那么将被处理为一般符号，例如展开FAC( 3 )时，会遇到 FAC( 2 )，那么就把FAC
( 2 )中的FAC当成了一搬符号。
    这样的限制注定了我们无法让宏真正地调用自身来实现递归。于是，我们不得不写下以下丑陋的符号，从而去模拟递
归的每一次符号调用：

#define FAC_1( n ) 1
#define FAC_2( n ) n * FAC_##(n-1)( n - 1 )
#define FAC_3( n ) n * FAC_##(n-1)( n - 1 ) 

    这系列宏有点别扭（如果你足够细心），因为我们明显知道FAC_2返回的将是2，而FAC_3返回的当时6。我们这里只是
模拟，同样，这使得我们可以把FAC_1作为递归的终止条件。
    我们的预想是，当调用FAC_3时，它把n-1的值2合并到FAC_中，从而调用FAC_2，以此类推。
    但是这依然有问题，编译器会提示‘找不到符号FAC_’。导致这个问题的原因在于：宏展开只是单纯的字符替换，是我们
想太多了，预处理器并不会去计算( n - 1 )的值是多少，也就是我们无法得到FAC_2这个宏。

    所以，FAC_3( 3 ) 会被初次替换为 3 * FAC_(3-1)( 3 - 1 )。这个时候编译器就把FAC_当成了一个普通符号。我们可以
自己定义个FAC_来证明这一点：

#define FAC_( n ) T 

    那么，FAC_3( 3 )就被替换为 3 * T(3-1)( 3 - 1 )。

    解决这个问题的办法关键在于，让预处理器自动计算出( n - 1 )。记住，我们解决问题的唯一办法是：字符替换。
所以，我们可以写下如下代码：

#define DEC_1 0
#define DEC_2 1
#define DEC_3 2 

#define DEC( n ) DEC_##n 

    通过，DEC( n )这个宏，我们可以获取到一个( n -1 )的数。例如，DEC( 3 )被替换为 DEC_3，继续替换为 2。

    于是，我们新的FAC系列宏变为：

#define FAC_1( n ) 1
#define FAC_2( n ) n * FAC_##DEC( n )( n - 1 )
#define FAC_3( n ) n * FAC_##DEC( n )( n - 1 ) 

    不好意思，这样依然是不正确的！预处理器直接把FAC_和DEC( n )连接成符号了，而不是单个地先处理他们，最后再
合并他们。

    OK，先解决这个问题：先处理FAC_和DEC( n )，再合并他们，而不是先合并他们。要解决这个问题，可以通过第三个宏
来实现：

#define CHR( x, y ) x##y 

    作为连接两个符号为一个符号的宏，这个宏显然是不正确的，因为宏展开还有个规则：如果宏体对宏参数使用了#或##，
那么宏参数不会被展开，也就是说：如果CHR( FAC_, DEC( 3 ) 那么得到的只会是 FAC_DEC( 3 )。通常情况下我们是
再写个宏：

#define CHR( x, y ) CHR1( x, y )
#define CHR1( x, y ) x##y 

    从而可以保证在正式连接x和y前，x和y都被完全展开。

    这个时候，我们的FAC系列宏变为：

#define FAC_1( n ) 1
#define FAC_2( n ) n * CHR( FAC_, DEC( n ) )( n - 1 )
#define FAC_3( n ) n * CHR( FAC_, DEC( n ) )( n - 1 ) 

    结果呢？结果还是有问题。= =
    我们假设CHR( FAC_, DEC( n ) )已经真的按我们预想展开为 FAC_2了，那么FAC_3( 3 )会被展开为什么呢？
被展开为 3 * FAC_2( 3 - 1 )。这是错误的，传给 FAC_2 的参数是 3 - 1就意味着错误。我们又臆想预处理器会
帮我们计算 3 - 1的结果了。我们必须保证传给 FAC_2的参数是个数字2。解决这个问题的办法就是通过DEC(n)宏。

   于是，FAC系列宏变为：

#define FAC_1( n ) 1
#define FAC_2( n ) n * CHR( FAC_, DEC( n ) )( DEC( n ) )
#define FAC_3( n ) n * CHR( FAC_, DEC( n ) )( DEC( n ) ) 

    这个时候，FAC_3( 3 )将会被替换为：3*2*1。这就是我们要的结果。

In practice

    以上只是向你展示一个过程，用宏去计算阶乘，就像用模板去计算阶乘（模板元编程）一样，只是一个用于展示的东西，
没有什么实际价值。接下来我们开始有实际的工作，完成之前的预想：

template <typename R, typename P1, typename P2, typename P3>
class functor<R (P1, P2, P3)> 

    直接:

template <typename R, PARAM( 3 )>
class functor<R (ARG( 3 ))> 

    先考虑PARAM宏，该宏的任务就是生成类似于：typename P1, typename P2, typename P3这样的符号。我们假象它每一次
递归都生成 typename Pn, 的字符串，那么当他递归完时，可能就生成typename P1, typename P2, typename P3, 结果
多了个逗号，也许最后一次结果不该有逗号。

    ARG宏和PARAM宏本质上相同，只是重复的符号不是typename Pn，而是Pn。

    最直接想到的是：

#define PARAM_1( n ) typename P##n
#define PARAM_2( n ) CHR( PARAM_, DEC( n ) )( DEC( n ) )##,typename P##n
#define PARAM_3( n ) CHR( PARAM_, DEC( n ) )( DEC( n ) )##,typename P##n 

    结果我们得到了个错误的展开结果：
typename PDEC( 2 ),typename PDEC( 3 ),typename P3

    这个问题出在：PARAM_3( 3 )当替换为 PARAM_2( DEC( n ) )时，因为PARAM_2(n)宏对于宏参数n使用了##，也就是那个
typename P##n，所以这里不会把 DEC( n )展开，而是直接接到P后面。所以就成了typename PDEC( 3 )。

    为了消除这个问题，我们改进PARAM为：

#define TYPE( n ) ,typename P##n
#define PARAM_1( n ) CHR( typename P, n )
#define PARAM_2( n ) CHR( CHR( PARAM_, DEC( n ) )( DEC( n ) ), TYPE( n ) )
#define PARAM_3( n ) CHR( CHR( PARAM_, DEC( n ) )( DEC( n ) ), TYPE( n ) ) 

    之所以加入TYPE(n)，是因为 ,typename P##n 这个宏本身存在逗号，将其直接用于宏体会出现问题。

    于是，我们得到了正确的结果。

    其实，PARAM系列宏宏体基本是一样的，除了终止条件那个宏，为什么我们要写这么多呢？理由在于宏体不能自己调用
自己，所以才有了PARAM_3, PARAM_2。

    我们可以将上面的一系列宏抽象化，使其具有可复用性：

#define PARAM( n ) ,typename P##n
#define PARAM_END typename P 

#define ARG( n ) ,P##n
#define ARG_END P 

#define PARAM_1( n ) CHR( typename P, n )
#define PARAM_2( n ) CHR( CHR( PARAM_, DEC( n ) )( DEC( n ) ), TYPE( n ) )
#define PARAM_3( n ) CHR( CHR( PARAM_, DEC( n ) )( DEC( n ) ), TYPE( n ) ) 

#define REPEAT_1( n, f, e ) CHR( e, n )
#define REPEAT_2( n, f, e ) CHR( CHR( REPEAT_, DEC( n ) )( DEC( n ), f, e ), f( n ) )
#define REPEAT_3( n, f, e ) CHR( CHR( REPEAT_, DEC( n ) )( DEC( n ), f, e ), f( n ) ) 

#define DEF_PARAM( n ) REPEAT_##n( n, PARAM, PARAM_END )
#define DEF_ARG( n ) REPEAT_##n( n, ARG, ARG_END ) 

    我们创建了可重用的REPEAT系列宏，用于创建诸如typename P1, typename P2, typename P3或者P1,P2,P3之类的符号，
通过更上层的DEF_PARAM(n)和DEF_ARG(n)，就可以直接创建出我们上面所需要的符号串，例如：

    DEF_PARAM( 3 ) 就得到 typename P1, typename P2, typename P3
    DEF_ARG( 3 ) 就得到 P1, P2, P3

More in practice

    下载中提供了我使用这个宏递归技术写的lua_binder(如果你看过<实现自己的LUA绑定器-一个模板编程挑战 >)，你
可以与上一个版本做一下比较，代码少了很多。
    同样，我希望你也能获取这种宏递归的思想。   

相关下载

   使用宏递归的lua_binder

SGI实现的STL里，所有的容器都使用SGI自己定义的allocator。这个allocator实现了一个small object的内存池。
Loki里为了处理小对象的内存分配，也实现了类似的内存管理机制。

该内存池大致上，就是一大块一大块地从系统获取内存，然后将其分成很多小块以链表的形式链接起来。其内部
有很多不同类型的链表，不同的链表维护不同大小的内存块。每一次客户端要求分配内存时，allcator就根据请求
的大小找到相应的链表(最接近的尺寸)，然后从链表里取出内存。当客户端归还内存时，allocator就将这块内存
放回到对应的链表里。

我简单地画了幅图表示整个结构：

allocator内部维护一个链表数组，数组元素全部是链表头指针。链表A每一个节点维护一个8bytes的内存块，链表
B每一个节点维护一个16bytes的内存块。

当客户端请求分配10bytes的内存时，allocator将10调整为最接近的16bytes(只能大于10bytes)，然后发现16bytes
这个链表(链表B)里有可用内存块，于是从B里取出一块内存返回。当客户端归还时，allocator找到对应的链表，将
内存重新放回链表B即可。

大致过程就这么简单，也许有人要说用链表维护一块内存，链表本身就会浪费一些内存(在我很早前接触内存池时，
总会看到类似的论点= =|)，其实通过一些简单的技巧是完全可以避免的。例如，这里allocator维护了很多内存块，
反正这些内存本身就是闲置的，因此我们就可以直接在这些内存里记录链表的信息(下一个元素)。

还是写点代码详细说下这个小技巧：

struct Obj
    {
        Obj *next;
    }; 

    void *mem = malloc( 100 );
    Obj *header = (Obj*) mem;
    Obj *cur_obj = header;
    Obj *next_obj = cur_obj;
    for( int i = 0; ; ++ i )
    {
        cur_obj = next_obj;
        next_obj = (Obj*)((char*)next_obj + 10 );
        if( i == 9 )
        {
            cur_obj->next = 0;
            break;
        }
        else
        {
            cur_obj->next = next_obj;
        }
    }
    free( mem );

这样，通过header指针和next域，就可以逐块(这里是10byts)地访问mem所指向的内存，而这些链表的节点，都
是直接保存在这块内存里的，所以完全没有额外消耗。

我用C模仿着SGI的这个allocator写了个可配置的内存池，在其上按照STL的标准包装了一个allocator，可以直接
用于VC自带的STL里。测试代码稍微测试了下，发现在不同的机器上有明显的差距。

这里所说的VC下的错误对话框时指在VC中开调试器运行程序时，IDE弹出的对话框。

1.不是错误的错误：断言 .

将断言视为错误其实有点可笑，但是因为有些同学甚至不知道这个，所以我稍微提一下。断言对话框大致上类似于：

断言对话框是由assert引起的，在对话框上通常会给出表达式，例如assert( 0 ); 弹出对话框时就会将0这个表达式显示出来（Expression:0)。关于assert的具体信息建议自己google。这里稍微提一下一个技巧：有时候为了让assert提供更多的信息，我们可以这样写一个assert:

assert( expression && "Function : invalid argument!" );

因为字符串被用在布尔表达式中时，始终为true，不会妨碍对expression的判断，当断言发生时(expression为false) 时，断言对话框上就会显示这个字符串，从而方便我们调试。

要解决这个问题，首先要确定断言发生的位置，如果是你自己设置的断言被引发，就很好解决，如果是系统内部的函数产生的，那么一般是因为你传入的函数参数无效引起。

2.内存相关：最简单的非法访问：

C、C++程序中经常误用无效的指针，从而大致各种各样的非法内存访问（写/读）。最简单的情况类似于：

这样的情况由类似以下代码引起：

char *p = 0;

*p = 'a';

当你看到类似于“写入位置XXXX时发生访问冲突“时，那么你大致可以断定，你的程序在某个地方访问到非法内存。开调试器对调用堆栈进行跟踪即可找出错误。

3.内存相关：不小心的栈上数组越界：

当你写下类似以下的代码时：

char str[3];

strcpy( str, "abc" );

就将看到如下的对话框：

对话框大致的意思就是说str周围的栈被破坏了，因为str本身就被放在栈上，所以strcpy(str,"abc")多写入的'\0'就写到非法的栈区域。看到这样的对话框可以根据调用堆栈定位到错误发生的函数，然后检查此函数内部定义的数组访问，即可解决问题。

4.内存相关：不小心的堆上数组越界：
并不是每次数组越界都会得到上面所描述的错误，当数组是在堆上分配时，情况就变得隐秘得多：

char *str = new char [2];

strcpy( str, "ab" ); //执行到这里时并不见得会崩溃

delete [] str;//但是到这里时就肯定会崩溃

以上代码导致的错误对话框还要诡异些：

似乎不同的DAMAGE对应的错误号（这里是47）都不一样，因为这里的错误发生在delete，而delete跟new很可能在不同的地方，所以这个错误调试起来不是那么容易，很多时候只能靠经验。

当看到类似的对话框时，根据调用堆栈跟到delete时，你就可以大致怀疑堆上数组越界。

5.调用相关：函数调用约定带来的错误：

这是所有我这里描述的错误中最诡异的一种，先看下对话框大致的样子：

对话框大致的意思就是说（没开调试器时对话框样式可能不一样），通过函数指针调用某个函数时，函数指针的类型（函数原型）可能与函数指针指向的函数的类型不一样。这里的类型不一致主要是调用约定(call conversation）不一样。如果函数类型（参数个数，返回值）不一样，一般不会出错。

调用约定是指调用一个函数时，函数参数的压入顺序、谁来清理栈的内容等。例如默认的C、C++调用约定__cdecl，对于函数的参数是从右往左压入。而__stdcall（WIN API的调用约定）则是从左向右压。我这里所说的函数类型不一样，就是指一个函数是使用__cdecl，还是__stdcall。例如以下代码：

#include <iostream> 

void __stdcall show( const char *str )

{

} 

void __stdcall show2()

{

} 

int main()

{

typedef void (*Func)( const char *);

void *p = show;

Func my_func = (Func) p;

my_func( "kevin" );

return 0;

} 

因为Func默认地被处理为__cdecl，而show是__stdcall的，所以当通过函数指针my_func时，就导致了以上对话框的出现。但是当p指向show2时，又不会出错，这是因为show2没有参数，不同的调用约定不影响这个规则。

6.异常相关：默认终止程序

当我们使用C++库时，因为库本身可能会抛出C++异常，如果你不捕获这个异常，那么C++默认就会调用abort（或者exit）函数终止程序。例如：

void test()
{
    throw std::exception( "some exceptions" );
}

当你调用test函数时，如果不catch这个异常，开调试器就会得到类似的错误对话框：

而如果不开调试器，则会得到：

当你看到类似于“This application has requested the Runtime to terminate it…”之类的字眼时，那就表明程序调用了abort（或exit）函数，导致程序异常终止。其实这个错误只要开调试器，一般可以准确定位错误的发生点。

7.VC运行时检查-未初始化变量

VC的调试器会对代码进行运行时检查，这可能会导致VC弹出对你看上去正确的代码。这也许不是一个错误。例如：

int test_var;

if( test_var == -1 )
{
    test_var = 0;
}

test_var没有初始化就进行if判断，当运行以上代码开调试器时，就会得到如下对话框：

8.破坏的堆

VC对于在堆上分配的内存都做了记录，我想这主要用于free释放内存时做归还处理。

char *p = (char*) malloc( 100 );
p += 10;
free( p );

当执行以上代码时，因为p的值已经改变，提交到free的指针值变化，VC就会给出以下错误提示：

众多C++书籍都忠告我们C语言宏是万恶之首，但事情总不如我们想象的那么坏，就如同goto一样。宏有
一个很大的作用，就是自动为我们产生代码。如果说模板可以为我们产生各种型别的代码(型别替换)，
那么宏其实可以为我们在符号上产生新的代码(即符号替换、增加)。

关于宏的一些语法问题，可以在google上找到。相信我，你对于宏的了解绝对没你想象的那么多。如果你
还不知道#和##，也不知道prescan，那么你肯定对宏的了解不够。

我稍微讲解下宏的一些语法问题(说语法问题似乎不妥，macro只与preprocessor有关，跟语义分析又无关)：

1. 宏可以像函数一样被定义，例如：
   #define min(x,y) (x<y?x:y) //事实上这个宏存在BUG
   但是在实际使用时，只有当写上min()，必须加括号，min才会被作为宏展开，否则不做任何处理。
  
2. 如果宏需要参数，你可以不传，编译器会给你警告(宏参数不够)，但是这会导致错误。如C++书籍中所描
   述的，编译器(预处理器)对宏的语法检查不够，所以更多的检查性工作得你自己来做。

3. 很多程序员不知道的#和##
   #符号把一个符号直接转换为字符串，例如：
   #define STRING(x) #x
   const char *str = STRING( test_string ); str的内容就是"test_string"，也就是说#会把其后的符号
   直接加上双引号。
   ##符号会连接两个符号，从而产生新的符号(词法层次)，例如：
   #define SIGN( x ) INT_##x
   int SIGN( 1 ); 宏被展开后将成为：int INT_1;

4. 变参宏，这个比较酷，它使得你可以定义类似的宏：
   #define LOG( format, ... ) printf( format, __VA_ARGS__ )
   LOG( "%s %d", str, count );
   __VA_ARGS__是系统预定义宏，被自动替换为参数列表。

5. 当一个宏自己调用自己时，会发生什么？例如：
   #define TEST( x ) ( x + TEST( x ) )
   TEST( 1 ); 会发生什么？为了防止无限制递归展开，语法规定，当一个宏遇到自己时，就停止展开，也就是
   说，当对TEST( 1 )进行展开时，展开过程中又发现了一个TEST，那么就将这个TEST当作一般的符号。TEST(1)
   最终被展开为：1 + TEST( 1) 。

6. 宏参数的prescan，
   当一个宏参数被放进宏体时，这个宏参数会首先被全部展开(有例外，见下文)。当展开后的宏参数被放进宏体时，
   预处理器对新展开的宏体进行第二次扫描，并继续展开。例如：
   #define PARAM( x ) x
   #define ADDPARAM( x ) INT_##x
   PARAM( ADDPARAM( 1 ) );
   因为ADDPARAM( 1 ) 是作为PARAM的宏参数，所以先将ADDPARAM( 1 )展开为INT_1，然后再将INT_1放进PARAM。
  
   例外情况是，如果PARAM宏里对宏参数使用了#或##，那么宏参数不会被展开：
   #define PARAM( x ) #x
   #define ADDPARAM( x ) INT_##x
   PARAM( ADDPARAM( 1 ) ); 将被展开为"ADDPARAM( 1 )"。

   使用这么一个规则，可以创建一个很有趣的技术：打印出一个宏被展开后的样子，这样可以方便你分析代码：
   #define TO_STRING( x ) TO_STRING1( x )
   #define TO_STRING1( x ) #x
   TO_STRING首先会将x全部展开(如果x也是一个宏的话)，然后再传给TO_STRING1转换为字符串，现在你可以这样：
   const char *str = TO_STRING( PARAM( ADDPARAM( 1 ) ) );去一探PARAM展开后的样子。

7. 一个很重要的补充：就像我在第一点说的那样，如果一个像函数的宏在使用时没有出现括号，那么预处理器只是
   将这个宏作为一般的符号处理(那就是不处理)。

我们来见识一下宏是如何帮助我们自动产生代码的。如我所说，宏是在符号层次产生代码。我在分析Boost.Function
模块时，因为它使用了大量的宏(宏嵌套，再嵌套)，导致我压根没看明白代码。后来发现了一个小型的模板库ttl，说的
是开发一些小型组件去取代部分Boost(这是一个好理由，因为Boost确实太大)。同样，这个库也包含了一个function库。
这里的function也就是我之前提到的functor。ttl.function库里为了自动产生很多类似的代码，使用了一个宏：

#define TTL_FUNC_BUILD_FUNCTOR_CALLER(n)  \
 template< typename R, TTL_TPARAMS(n) > \
 struct functor_caller_base##n \
        ///...
该宏的最终目的是：通过类似于TTL_FUNC_BUILD_FUNCTOR_CALLER(1)的调用方式，自动产生很多functor_caller_base模板：
template <typename R, typename T1> struct functor_caller_base1
template <typename R, typename T1, typename T2> struct functor_caller_base2
template <typename R, typename T1, typename T2, typename T3> struct functor_caller_base3
///...
那么，核心部分在于TTL_TPARAMS(n)这个宏，可以看出这个宏最终产生的是：
typename T1
typename T1, typename T2
typename T1, typename T2, typename T3
///...
我们不妨分析TTL_TPARAMS(n)的整个过程。分析宏主要把握我以上提到的一些要点即可。以下过程我建议你翻着ttl的代码，
相关代码文件：function.hpp, macro_params.hpp, macro_repeat.hpp, macro_misc.hpp, macro_counter.hpp。

so, here we go

分析过程，逐层分析，逐层展开，例如TTL_TPARAMS(1)：

#define TTL_TPARAMS(n) TTL_TPARAMSX(n,T) 
=> TTL_TPARAMSX( 1, T )
#define TTL_TPARAMSX(n,t) TTL_REPEAT(n, TTL_TPARAM, TTL_TPARAM_END, t)
=> TTL_REPEAT( 1, TTL_TPARAM, TTL_TPARAM_END, T )
#define TTL_TPARAM(n,t) typename t##n,
#define TTL_TPARAM_END(n,t) typename t##n
#define TTL_REPEAT(n, m, l, p) TTL_APPEND(TTL_REPEAT_, TTL_DEC(n))(m,l,p) TTL_APPEND(TTL_LAST_REPEAT_,n)(l,p)
注意，TTL_TPARAM, TTL_TPARAM_END虽然也是两个宏，他们被作为TTL_REPEAT宏的参数，按照prescan规则，似乎应该先将
这两个宏展开再传给TTL_REPEAT。但是，如同我在前面重点提到的，这两个宏是function-like macro，使用时需要加括号，
如果没加括号，则不当作宏处理。因此，展开TTL_REPEAT时，应该为：
=> TTL_APPEND( TTL_REPEAT_, TTL_DEC(1))(TTL_TPARAM,TTL_TPARAM_END,T) TTL_APPEND( TTL_LAST_REPEAT_,1)(
TTL_TPARAM_END,T)
这个宏体看起来很复杂，仔细分析下，可以分为两部分：
TTL_APPEND( TTL_REPEAT_, TTL_DEC(1))(TTL_TPARAM,TTL_TPARAM_END,T)以及
TTL_APPEND( TTL_LAST_REPEAT_,1)(TTL_TPARAM_END,T)
先分析第一部分：
#define TTL_APPEND( x, y ) TTL_APPEND1(x,y) //先展开x,y再将x,y连接起来
#define TTL_APPEND1( x, y ) x ## y
#define TTL_DEC(n) TTL_APPEND(TTL_CNTDEC_, n)
根据先展开参数的原则，会先展开TTL_DEC(1)
=> TTL_APPEND(TTL_CNTDEC_,1) => TTL_CNTDEC_1
#define TTL_CNTDEC_1 0  注意，TTL_CNTDEC_不是宏，TTL_CNTDEC_1是一个宏。
=> 0 ， 也就是说，TTL_DEC(1)最终被展开为0。回到TTL_APPEND部分：
=> TTL_REPEAT_0 (TTL_TPARAM,TTL_TPARAM_END,T)
#define TTL_REPEAT_0(m,l,p)
TTL_REPEAT_0这个宏为空，那么，上面说的第一部分被忽略，现在只剩下第二部分：
TTL_APPEND( TTL_LAST_REPEAT_,1)(TTL_TPARAM_END,T)
=> TTL_LAST_REPEAT_1 (TTL_TPARAM_END,T) // TTL_APPEND将TTL_LAST_REPEAT_和1合并起来
#define TTL_LAST_REPEAT_1(m,p) m(1,p)
=> TTL_TPARAM_END( 1, T )
#define TTL_TPARAM_END(n,t) typename t##n
=> typename T1  展开完毕。

虽然我们分析出来了，但是这其实并不是我们想要的。我们应该从那些宏里去获取作者关于宏的编程思想。很好地使用宏
看上去似乎是一些偏门的奇技淫巧，但是他确实可以让我们编码更自动化。

参考资料：
macro语法: http://developer.apple.com/documentation/DeveloperTools/gcc-4.0.1/cpp/Macros.html
ttl(tiny template library) : http://tinytl.sourceforge.net/

base functor包括: unary_function, binary_function,分别表示只有一个参数的函数和有两个参数
的函数。实际上STL里还有一个所谓的generator，代表没有参数的函数。因为STL泛型算法一般最多
只会使用两个参数的函数，所以这里并没有定义更多参数的base functor。

可被functor adaptor使用的functor又称为adaptable function，根据参数的个数，会被命名为诸如
adaptable unary function, adaptable binary function。

一个返回值为bool的functor又被称为predicate，可被用于functor adaptor的predicate被称为
adaptable predicate。其实所谓的adaptable，只需要在类型内部typedef一些类型即可，一般包括
first_argument_type, second_argument_type, result_type。functor adaptor会使用这些定义。

预定义的functors都是些很简单的functor，基本上就是封装诸如plus, minus, equal_to之类的算术
运算，列举一个predefined functor的代码：
 

template <class _Tp>
  struct plus : public binary_function<_Tp, _Tp, _Tp>
  {
     _Tp operator()(const _Tp& __x, const _Tp& __y) const   
     { 
         return __x + __y; 
     }    
  };

因为从binary_function(即我所谓的base functor)派生，因此这些predefined functor也是adaptable
function。

functor adaptors里有很多有趣的东西，其实functor adaptor也是一些functor(从SGI的观点来看，一般
的C函数，函数指针都算作functor)。所不同的是，他们通常会适配(adapt)一种functor到另一种。例如：
std::binder1st，严格地说它是一个函数模板，它会把一个adaptable binary function转换为一个
adaptable unary function，并绑定一个参数。又如: std::ptr_fun，它会将一个只有一个参数的C函数
适配成一个pointer_to_unary_function的functor。

下面列举一些具体的代码：
关于base functor，基本上就只有unary_function, binary_function :
 

template <class _Arg, class _Result>
  struct unary_function
  {
      typedef _Arg argument_type;                    
      typedef _Result result_type; 
  };
  

关于predefined functor，如之前列举的plus一样，再列举一个：

template <class _Tp>
 struct greater : public binary_function<_Tp, _Tp, bool>
 {      
     bool operator()(const _Tp& __x, const _Tp& __y) const
     { 
         return __x > __y; 
     }    
 };

 
关于functor adaptors，也是我觉得比较有趣的部分，多列举几个：

template <class _Operation, class _Tp>
  inline binder1st<_Operation>
  bind1st(const _Operation& __fn, const _Tp& __x)
  {
      typedef typename _Operation::first_argument_type _Arg1_type;
      return binder1st<_Operation>(__fn, _Arg1_type(__x));
  }
  

 
bind1st返回的binder1st定义为：

 template <class _Operation>
  class binder1st : public unary_function<typename _Operation::second_argument_type, 
  typename _Operation::result_type>
  {
  protected:
      _Operation op;
      typename _Operation::first_argument_type value;
  public:
      binder1st(const _Operation& __x, const typename _Operation::first_argument_type& __y): 
        op(__x), value(__y) 
      {}
      typename _Operation::result_type 
      operator()(const typename _Operation::second_argument_type& __x) const
      { 
         return op(value, __x); 
      }
     typename _Operation::result_type 
     operator()(typename _Operation::second_argument_type& __x) const
     { 
        return op(value, __x); 
     }
  };

 
值得一提的是，ptr_fun以及相关的pointer_to_unary_function, pointer_to_binary_function，基本上
就是用来绑定C函数的组件，不过这里采用了很基础的模板技术，因此只实现了绑定一个参数和两个参数
的C函数。这种组件类似于loki中的functor，以及boost中的bind，只是功能弱很多。与之相关的还有
mem_fun, mem_fun_ref, mem_fun1, mem_fun1_ref等，这些都是用于绑定成员函数的。另一方面，与其说
是绑定，还不如说适配，即将函数适配为functor(特指重载operator()的类)。( Mem_fun_t is an adaptor
 for member functions )采用这些(ptr_fun, mem_fun之类的东西)组件，客端程序员可以很容易地将各种
运行体(Kevin似乎很喜欢发明各种名字)(C函数、成员函数)适配成functor，从而与STL泛型算法结合。
例如, SGI文档中给出的mem_fun例子：

struct B {
 virtual void print() = 0;
};

struct D1 : public B {
 void print() { cout << "I'm a D1" << endl; }
};

struct D2 : public B {
 void print() { cout << "I'm a D2" << endl; }
};

int main()
{
 vector<B*> V;

 V.push_back(new D1);
 V.push_back(new D2);
 V.push_back(new D2);
 V.push_back(new D1);

 for_each(V.begin(), V.end(), mem_fun(&B::print));
}

注：以上分析基于dev-cpp中自带的stl，源代码见stl_functional.h。