事情的起因是，想找个跨 Windows 和 Mac 的构建方案。第一考虑自然是 CMake，毕竟基本上是事实标准了。

但是研究了一下 Modern CMake，也就是以 target 为核心的理念。但发现看了好几天文档，也折腾出了可用的东西，但仍然是没梳理清楚什么理念、原理。然后 CMake 本身语法就很复杂，再加上搞 target 一套概念，要给 target 设置各种属性之类的，有点强行 OOP 的感觉……但其实我们只是需要一个 include_dir 和 lib_dir 而已，其他都是浮云~

但如果退回到传统模式，不用 Modern 概念呢，好像可以将就，但第一不去用一个工具的最新模式，好像有点不上进的感觉（python 2 除外）；第二，CMake 的两大痛点——语法特立独行、文档晦涩难懂——还是让人有点不爽。

那跳出来看别的选择呢？目前相对成熟的也只有 Google 的 gn+ninja 方案了。gn 这套东西在 Chromium 里是完全配置好的，用起来还算顺手，但要是独立拿出来呢，就没那么便宜了。关键是它的 toolchain 是要自己定义的。

之前还在公司搞客户端的时候，大家就从 Chromium 里面把 build、build_overrides 等等东西全部拷出来，好家伙，几百 MB 甚至上 G。但是公司里嘛，没人管干不干净，怎么快怎么来。后来又看到 Google 自家的 Crashpad 里面也用了这套构建，但工具链被简化了一下，叫 mini_chromium。这个比 Chromium 里的小多了，是可以拿过来直接用的，缺少一些配置可以自己加。但是呢，像我们这种洁癖，仍然是受不鸟的。所以呢，我们要干干净净的建立一套工具链。

构建系统安装

首先，我们明确定位。gn 和 ninja 都是开发机上需要预装的，不是软件提供的。Chromium 的搞法是自己提供，gn 的文档也说让开发者提供工具。但这套思路跟传统的理念是冲突的。同时，自己安装工具成本是比较低的：

• linux
  • ninja 在主流包管理系统里已经有了，包名可能是 ninja 或 ninja-build，直接安装就可以
  • gn 在部分包管理系统有，尝试包名 gn 或 gn-build 等，没有的话可以下载二进制版本，或者从源代码自行编译
• mac
  • ninja 在 brew 里包名叫 ninja，在 MacPorts 里包名叫 ninja-build
  • gn 在 brew 里没有，可以下载二进制版本；在 MacPorts 里叫 gn-devel
• win
  • ninja 可以在 GitHub 下载二进制版本，gn 可以在 gn 官网下载二进制版本

自己下载的设置到 PATH，测试 gn --version 以及 ninja --version，能运行即可

目标

希望做到提供一个 git repo，使用者 clone 到自己项目的 build 目录，然后使用者只要在 .gn 文件里配置

buildconfig = "//build/BUILDCONFIG.gn"

就可以使用我们提供的工具链，在 PC 三端进行构建。

使用者的唯一负担就是编写自己的 BUILD.gn

工具链搭建

首先我们看 gn 的文档，以及它的例程 simple_build 里的工具链配置：

https://gn.googlesource.com/gn/+/HEAD/examples/simple_build/build/toolchain/BUILD.gn

这个是可以直接用的，只不过只有 linux 端（当然 mac 也能用）。我们再结合 chrome 里的工具链配置，进行一些完善。

基础概念

首先我们了解 gn 体系需要的最小配置是什么。

第一，它需要在根目录写一个 .gn 文件，在里面定义 buildconfig，指到另一个文件，一般是

buildconfig = "//build/BUILDCONFIG.gn"

第二、BUILDCONFIG.gn 里面需要设置默认工具链，也就是写一行

set_default_toolchain("//build/toolchain:gcc")

第三、定义工具链，如上例的 //build/toolchain:gcc。

需要在 build/toolchain 下建立 BUILD.gn 文件，内容是

toolchain("gcc") {
	# ...
}

最后在 toolchain 里定义各种 tool。

工具链中的工具

这部分文档在这里：https://gn.googlesource.com/gn/+/main/docs/reference.md#func_tool

简单复述一下，可被定义的工具有：

• 编译工具:
  "cc": C 编译器
  "cxx": C++ 编译器
  "cxx_module": 支持 module 的 C++ 编译器
  "objc": Objective C 编译器
  "objcxx": Objective C++ 编译器
  "rc": Windows 资源脚本编译器
  "asm": 汇编器
  "swift": Swift 编译器
• 链接工具:
  "alink": 静态库链接器
  "solink": 动态库链接器
  "link": 可执行文件链接器

（其他的就先不看了）

我们来看一下 https://gn.googlesource.com/gn/+/HEAD/examples/simple_build/build/toolchain/BUILD.gn 的一些关键配置：

toolchain("gcc") {
  tool("cc") {
    command = "gcc -MMD -MF $depfile {{defines}} {{include_dirs}} {{cflags}} {{cflags_c}} -c {{source}} -o {{output}}"
    outputs = [ "{{source_out_dir}}/{{target_output_name}}.{{source_name_part}}.o" ]
    # ...
  }
  tool("cxx") {
    command = "g++ -MMD -MF $depfile {{defines}} {{include_dirs}} {{cflags}} {{cflags_cc}} -c {{source}} -o {{output}}"
    outputs = [ "{{source_out_dir}}/{{target_output_name}}.{{source_name_part}}.o" ]
    # ...
  }
  tool("alink") {
    command = "rm -f {{output}} && ar rcs {{output}} {{inputs}}"
    outputs = [ "{{target_out_dir}}/{{target_output_name}}{{output_extension}}" ]
    # ...
  }
  tool("solink") {
    command = "g++ -shared {{ldflags}} -o $sofile $os_specific_option @$rspfile"
    outputs = [ sofile ]
    # ...
  }
  tool("link") {
    command = "g++ {{ldflags}} -o $outfile -Wl,--start-group @$rspfile {{solibs}} -Wl,--end-group {{libs}}"
    outputs = [ outfile ]
    # ...
  }
  tool("stamp") {
    command = "touch {{output}}"
  }
  tool("copy") {
    command = "cp -af {{source}} {{output}}"
  }
}

可以看到，cc 和 cxx 执行 command 后，生成 .o 文件，然后这些 .o 文件可以作为 alink、solink、link 的 inputs，被它们 command 继续使用，最后输出静态库、动态库以及可执行文件。

其余属性可以查文档了解含义。

对比 Chromium 中的配置

Linux

主要配置在这里：https://source.chromium.org/chromium/chromium/src/+/main:build/toolchain/gcc_toolchain.gni

也是 gcc 的，与 simple_build 里的大同小异，没有特别的。

Mac

主要配置在这里：https://source.chromium.org/chromium/chromium/src/+/main:build/toolchain/apple/toolchain.gni

区别有：

• 用 clang 系列编译工具，而不是 gcc
• alink 不是用 ar，而使用 libtool
• solink 的默认扩展名改成了 dylib
• 用了一个 linker_driver.py 来支持生成 dSYM，在里面调用了 dsymutil 和 strip

Win

• 编译用 cl，静态库链接用 lib，动态库和可执行文件的链接用 link
• lib_switch = ""，lib_dir_switch = "/LIBPATH:"；前两者 lib_switch = "-l"，lib_dir_switch = "-L"

建立我们的工具链

基本上是根据上面分析的要点配置，最终结果在此：https://github.com/Streamlet/gn_toolchain

新增的一些差异有：

• 增加全局参数 is_debug，可以在 gn gen out --args="is_debug=true"传入。默认 is_debug 为 false，开启所有优化。

• mac 下生成 dSYM 不使用 python 脚本，直接是 $ld ... && dsymutil ... && strip

• mac 下加了一个 template：app_bundle，用来生成 xxx.app，主要配置来自于 create_bundle 文档里的例子

• win 下增加了一些配置集

  • 动态/静态链接 CRT：//build/config/win:console_subsystem、//build/config/win:static_runtime

  • 控制台程序、Win32 程序：//build/config/win:console_subsystem、//build/config/win:windows_subsystem

    这个其实一般情况下用不着，只要入口函数是 main/WinMain，link 默认就是控制台程序/Win32 程序

  • XP 支持：//build/config/win:console_subsystem_xp、//build/config/win:windows_subsystem_xp

    具体实现是链接参数加 /SUBSYSTEM:CONSOLE,5.01 或 /SUBSYSTEM:WINDOWS,5.01。关键是后面的版本号 5.01，为了加版本号则必须指定子系统名称，所以分了 console_subsystem_xp 和 windows_subsystem_xp。又，xp 这里提供了两个 subsystem 的配置集，非 xp 也提供两个。

    但是我们没有加 _WIN32_WINNT=0x0501、WINVER=0x0501、_USING_V110_SDK71_，也没有指定必须使用 7.0 版本的 SDK，这些都是非必须的，只要不用到 XP 以后添加的 API 即可。使用者可以在自己的 target 里面定义这些宏。

使用案例

提供一个使用案例：https://github.com/Streamlet/gn_toolchain_sample

因为它以 git submodule 形式引用了 https://github.com/Streamlet/gn_toolchain，所以 git clone 以后，需要 git submodule update --init一下。

然后在根目录执行：（确保 gn 和 ninja 已经在 PATH 中）

gn gen out
ninja -C out

即可。

Mac 下会额外生成一个 objc 项目 objc_console_application 以及一个 app_bundle：ns_application.app。

Win 会额外生成一个 Win32 项目 win32_application。

Win 下需要先执行一下 Visual Studio 带的命令行环境，如 VS 2022 Community 的 “x64 Native Tools Command Prompt for VS 2022”，cl 等工具才会可用。

如果要测试 XP（32位），用“x86 Native Tools Command Prompt for VS 2022”进入，CD 到项目目录，执行：

gn gen out --args="target_cpu=\"x86\""
ninja -C out

总结

我们只用几十 KB 的大小完成了跨端支持，是很轻量的一个配置。如果您觉得实用并认可这种方式，欢迎一起来维护、完善。

这次是因为傻逼大微软改了 System32\IME\shared 里的东西，导致旧系统拷过来的文件与 System32\IME\shared 的东西不兼容了。解决方式很暴力：从以前的版本复制 System32\IME\shared 过来。

下载：https://www.streamlet.org/software/mspyforever/

（原发于 GitHub Pages，2018-10-13 13:36:04）

首先贴个图，大家来一起念台词~

念完了木有？很激情澎湃义愤填膺有木有？

这事情最早追溯到前年 8 月的一篇文章《十个步骤找回 Win8 中的微软拼音新体验模式》，其实就是手工注册一个COM完事，只是傻逼大微软刻意弄了注册表权限来屏蔽，操作起来略微繁琐。到目前为止，Win8重装系统已经不下十次了，每次都是这样手工操作，我已经厌倦了。

另外还有Win8.1上的问题，由于傻逼大微软已经完全删除了文件，就没法这么搞了，就算从Win8拷过文件来，也无法简单注册使用。加上我对8.1非常非常不感冒，一直没去研究。前些天看到之前的那篇文章里 Charles Leigh 回复了两篇文章（ePig 那篇是原创吧貌似，感谢），提供了解决方案。于是上个周末到现在就捣鼓个一键恢复工具，方便自己以后重装用，也方便广大微拼党。

微拼党（包括我）孜孜不倦的追求微拼长句模式的情怀，让我非常感动。希望傻逼大微软看到我们的心声。别搞什么破词组输入法了，你搞不过本土这么多厂家的，你的下限也没有本土厂家低，唯一的优势可能就是没广告没弹窗了吧。至于输入算法什么的，在词组模式里面根本不足以体现得太多，长句模式才是考验啊。回头吧！

下载页面：http://www.streamlet.org/Software/MSPYForever/

CodePlex 项目页面：https://mspyforever.codeplex.com/

请微拼党们多传播。有 Bug 及时反馈。

比较的对象是std::regex，暂时只比较两项：

1、解析正则表达式的速度

2、使用解析好的正则表达式去匹配字符串的速度。

测试代码如下： 

前两则是分别使用std::wregex和xl::RegExp解析"http://([a-zA-Z0-9\\-]+.)+[a-zA-Z]+/"十万次，后两则是拿来匹配http://w-1.w-2.w-3.streamlet.org/十万次。

结果如下：

匹配速度差很多，解析速度差不多。

考虑到在解析“?”“+”“*”的时候，引入了很多ε边，于是对那部分做点优化，去除不必要的ε边和节点构造，然后再测试：

可以看到有所提高，但是解析速度还是跟std:wregex的差很多，匹配速度有明显领先。目前只解析到ε边、-NFA，如果再做状态机转化，虽然会提高匹配速度，可是解析速度会进一步下降。因此，一开始就要考虑使用一种更高效的状态机存储方法。

这两天着凉生病了，好难受啊……

（所有内容针对 VC 编译平台）

一、x86

二、x64

64位编译环境下，可以指定 __cdecl、__stdcall、__fastcall，但是编译器会忽略它们。两个显示指定了不同调用约定的函数不构成重载，而构成重定义错误。

可是，C 风格的到底有什么坏处？C++的这些 cast 又有什么好处呢？

昨天以前，我连这些 cast 是什么都不知道（很惭愧）。昨天因为同事们提到这件事，于是小小研究了一下。一些实验代码如下：

1、无继承的类型转换

2、const_cast

从第1点的试验，加上外界资料的说明，看上去const_case 只允许具有不同cv限定符的同类型之间的转换。

值得注意的是，如果类型A不是指针或引用，不能使用const_cast（使用了也无意义，见 A a2 = (A)a 这一行）

在 const_cast 可以使用的情形，(T)value 形式都可以使用，(T)value 在功能上完全覆盖 const_cast。

2、reinterpret_cast

看上去，reinterpret_cast 可以理解为在指针和数值之间转换的一种方式，无关任何运算符重载，仅仅把指针转为字面值，或者把数字转为指针，转换的过程中值没有任何改变，只是告诉编译器不要报类型不匹配而已。

另外，在reinterpret_cast可以使用的情形，static_cast 是不可以使用的，除非定义了相应的类型转换运算符。

在 reinterpret_cast 可以使用的情形，(T)value 的方式同样可以完全胜任，(T)value 在功能上完全覆盖 reinterpret_cast。

dynamic_cast 我自认为还是理解的，就不试了。

综上，我的理解如下：

1、static_cast + const_cast + reinterpret_cast = (T)value

C++ 把原来C风格的的这三个cast拆分成了三个，三者相互正交。大多数情况下，应该是 static_cast 在取代着 (T)value；只是在去除 cv 限定符的时候，换用 const_cast；在取指针字面值的时候，换用 reinterpret_cast。类型转换运算符 operator T() 由 static_cast 负责执行。

2、dynamic_cast 是 C++ 新增的，用于多态的情形，且只允许转换具有多态关系的继承树上的类型的指针和引用，不允许转换类型本身。它不是针对 (T)value而出现的，两者没有任何竞争关系，只是取决于不同的需求。

（不知这样理解是否正确，请批评指正~）

至于网上推崇用新写法，是不是为了更细化而容易理解？有没有什么是 (T)value 做不到而 *_cast 能做到的？或者反过来？

左值和右值

1 Every expression is either an lvalue or an rvalue.

表达式不是左值就是右值。

2 An lvalue refers to an object or function. Some rvalue expressions—those of class or cv-qualified class type—also refer to objects. 47)

左值是指一个对象或者函数。某些右值（那些带或不带cv限定符的类类型）也是对象。

3 [Note:
some built-in operators and function calls yield lvalues. [Example: if E is an expression of pointer type, then *E is an lvalue expression referring to the object or function to which E points. As another example, the function
int& f();
yields an lvalue, so the call f() is an lvalue expression. ] ]

[注意：某些内置运算符以及一些函数调用会返回左值。[例1：如果 E 是一个指针类型的表达式，那么 *E 是一个左值表达式，指示指针 E 所指向的那个对象或者函数。例2：函数
int& f();
返回左值，所以函数调用 f() 是一个左值表达式。] ]

4 [Note: some built-in operators expect lvalue operands. [Example: built-in assignment operators all expect their left hand operands to be lvalues. ] Other built-in operators yield rvalues, and some expect them. [Example: the unary and binary + operators expect rvalue arguments and yield rvalue results. ] The discussion of each built-in operator in clause 5 indicates whether it expects lvalue operands and whether it yields an lvalue. ]

[注意：某些内置运算符需要左值操作数。[例：所有内置的赋值运算符的左操作数都必须是左值。] 有些内置运算符会返回右值结果，有些会需要右值操作数。[例：一元运算符“+”和二元运算符“+”都需要右值操作数，并且返回右值结果。] 我们在条款 5 中会对所有内置运算符进行讨论，指出它们的操作数和返回结果是左值还是右值。]

5 The result of calling a function that does not return a reference is an rvalue. User defined operators are functions, and whether such operators expect or yield lvalues is determined by their parameter and return
types.

调用返回值为非引用类型的函数，结果是右值。用户自定义的运算符也是函数，这些运算符的操作数以及结果是左值还是右值，取决于（运算符重载）函数的参数和返回值类型。

6 An expression which holds a temporary object resulting from a cast to a nonreference type is an rvalue (this includes the explicit creation of an object using functional notation (5.2.3)).

对非引用类型的转换表达式（包括使用函数式的记号进行显示创建）是右值，它将返回一个临时对象。

__________________
47) Expressions such as invocations of constructors and of functions that return a class type refer to objects, and the implementation can invoke a member function upon such objects, but the expressions are not lvalues.

有些表达式，比如调用构造函数的表达式，以及调用返回类类型的函数的表达式，它们也是对象，且可以对它们调用成员函数，但这种表达式不是左值。

____________________________________华丽的分页符____________________________________

7 Whenever an lvalue appears in a context where an rvalue is expected, the lvalue is converted to an rvalue; see 4.1, 4.2, and 4.3.

如果在一个需要右值的场合出现了左值，这个左值将被转换成右值。
见 4.1、4.2、4.3。

8 The discussion of reference initialization in 8.5.3 and of temporaries in 12.2 indicates the behavior of lvalues and rvalues in other significant contexts.

12.2 中关于引用的初始化和关于临时对象的讨论，也指出了左右值在其他重要场合的行为。

9 Class rvalues can have cv-qualified types; non-class rvalues always have cv-unqualified types. Rvalues shall always have complete types or the void type; in addition to these types, lvalues can also have incomplete types.

类类型的右值可以具有 cv 限定符；非类类型的右值不能被 cv 限定符修饰。右值通常是完整类型或者 void 类型，而对于左值来说，除了完整类型和 void 类型外，还可以是不完整类型。

10 An lvalue for an object is necessary in order to modify the object except that an rvalue of class type can also be used to modify its referent under certain circumstances. [Example: a member function called for an object (9.3) can modify the object. ]

通常情况下，如果要修改一个对象，它必须是左值。但在某些特定的场合，右值形式的类对象也可以被修改。[例：调用一个对象的成员函数（9.3），可以修改对象本身。]

11 Functions cannot be modified, but pointers to functions can be modifiable.

函数（对象）不能（在运行时）被修改，但是函数指针可以。

12 A pointer to an incomplete type can be modifiable. At some point in the program when the pointed to type is complete, the object at which the pointer points can also be modified.

指向一个不完整类型的指针可能是可修改的。当这个被指向的类型某时某刻成为完整类型后，这个指针所指向的那个对象也是可修改的。

13 The referent of a const-qualified expression shall not be modified (through that expression), except that if it is of class type and has a mutable component, that component can be modified (7.1.5.1).

被 const 限定的表达式所对应的对象不能（通过该表达式）被修改；除非这个对象是类类型并且含有 mutable 成员，此时该 mutable 成员可以被修改。

14 If an expression can be used to modify the object to which it refers, the expression is called modifiable. A program that attempts to modify an object through a nonmodifiable lvalue or rvalue expression is illformed.

如果一个表达式可以被用来修改此表达式对应的对象，那么这个表达式被称为可修改的。企图通过一个不可修改的左值者右值表达式去修改一个对象，是非法的。

15 If a program attempts to access the stored value of an object through an lvalue of other than one of the following types the behavior is undefined 48):
— the dynamic type of the object,
— a cv-qualified version of the dynamic type of the object,
— a type that is the signed or unsigned type corresponding to the dynamic type of the object,
— a type that is the signed or unsigned type corresponding to a cv-qualified version of the dynamic type of
the object,
— an aggregate or union type that includes one of the aforementioned types among its members (including,
recursively, a member of a subaggregate or contained union),
— a type that is a (possibly cv-qualified) base class type of the dynamic type of the object,
— a char or unsigned char type.

如果程序通过下列类型之外类型的左值访问一个对象的值，其行为是未定义的：

——对象的动态类型；
——CV 限定的对象动态类型；
——对象的动态类型对应的有符号或无符号类型；
——CV 限定的对象动态类型有符号或无符号类型；
——一个成员中含有聚合或者联合类型的聚合或者联合类型（包括递归形式的定义以及成员中有子聚合类型或者包含一个联合）
——对象的动态类型的基类类型（可以被 cv 限定符修饰）
——char 或 unsigned char 类型

__________________
48) The intent of this list is to specify those circumstances in which an object may or may not be aliased.
给出这份列表的目的是指明一些特定情形，在这些情形下对象可能被重叠，但也有可能不是，我们无法预知。

____________________________________华丽的分隔符____________________________________

以上，求指正，包括理解误区和语言组织不合理的，欢迎指出~ ^_^

排版方面的大概有，如何缩进，如何使用空格、换行，等等。命名方面的包括变量、函数、类、文件的取名等等。书写逻辑方面的就比较多了，可能包括：
是否全面使用异常、出错处理资源清理如何组织、如何利用编译提示防止常见错误……

一时间列不全。网上常见的文档我会参考的。除此之外，想从大家这里征求下，以上几个大方面之外，还有没有比较重要的方面？大家日常工作中有没有遇到一些特别希望别人也使用和自己一样的方式做的事？以及，哪些规定比较容易被推动？哪些规定不容易被推动？如果有一个规则强加在你头上，你会有怎样的心理？等等……

如果您有想法，请回复下，我们讨论讨论^_^

----------

顺便再问个问题，Windows 上的开发，大家喜欢动态链接 CRT（/MD、/MDd） 还是静态链接 CRT（/MT、/MTd）？为什么？个人倾向于哪种？在公司里又是怎样做的？

稍微解释下，因为有可能有人会误会：放新线程里面去不就可以了？这没有解决问题。如此的话，你那个线程函数怎么写？或者线程函数里调用的某个任务函数怎么写？总之，多线程虽然总是出现在这些问题的解决方案中，但不是多线程解决了这个问题。嗯……不知道说清楚了没？

目前我心里的答案只有这一种模式：

bool DoTask(HANDLE hQuitSignal)
{
    while (!QuitCondition)
    {
        if (WaitForSingleObject(hQuitSignal, 0) == WAIT_OBJECT_0)
        {
            return false;
        }

        // Do something
    }

    return true;
}

其中，“// Do something”部分要细化到瞬间执行完成的细度。

但是我很困惑的是，如果这些任务很繁重，难道我必须每进行一些操作就 if (WaitForSingleObject(hQuitSignal, 0) == WAIT_OBJECT_0) 检查下吗？这样岂不是这种检测代码充斥在任务中了？

不知各位有何经验和体会，求教~

很多时候我们需要返回/传入一堆参数，所以不得不每次定义一些为了数据传输的结构。Tuple 就是用来解决这一问题的，它提供即时构造一个这样的结构体的功能。而所付出的代价是，丧失各个成员的明确含义，只留下成员的序号。

两个元素的 Tuple 就是 Pair，如 std::pair。下面我们来建立针对有限个元素的 Tuple。对于一个元素、两个元素、三个元素，我们可以分别如下实现：

template <typename T0>
struct Tuple
{
    T0 _0;
};

template <typename T0, typename T1>
struct Tuple
{
    T0 _1;
    T1 _1;
};

template <typename T0, typename T1, typename T2>
struct Tuple
{
    T0 _1;
    T1 _1;
    T2 _2;
};

但是这三个写在一起，就会出错。为此，我们可以先定义一个含足够多模版参数的 Tuple，然后上面三个分别作为偏特化版本：

template <typename T0 = NullType, typename T1= NullType, typename T2= NullType, typename T3= NullType, typename T4= NullType>
struct Tuple;

template <typename T0>
struct Tuple<T0>
{
    T0 _0;
};

template <typename T0, typename T1>
struct Tuple<T0, T1>
{
    T0 _1;
    T1 _1;
};

template <typename T0, typename T1, typename T2>
struct Tuple<T0, T1, T2>
{
    T0 _1;
    T1 _1;
    T2 _2;
};

如果手写的话，这也可以。如果不手写，我们可以继续用之前《C++ 下 Function 对象的实现（下）》中的宏循环方案。此方案的一个正式版本见 xlMacros.h。

定义带默认值 NullType 的模版参数声明序列如下：

#define XL_TUPLE_TYPENAME_DECLARE_NT_PATTERN(n)     typename T##n = NullType
#define XL_TUPLE_TYPENAME_DECLARE_NT(n)             XL_REPZ(XL_TUPLE_TYPENAME_DECLARE_NT_PATTERN, n, XL_COMMA)

它将被展开为： typename T0 = NullType, typename T1 = NullType, typename T2 = NullType, …, typename Tn = NullType

定义不带默认值的模版参数声明序列如下：

#define XL_TUPLE_TYPENAME_DECLARE_PATTERN(n)        typename T##n
#define XL_TUPLE_TYPENAME_DECLARE(n)                XL_REPZ(XL_TUPLE_TYPENAME_DECLARE_PATTERN, n, XL_COMMA)

它将被展开为：typename T0, typename T1, typename T2, …, typename Tn

定义模版参数使用序列如下：

#define XL_TUPLE_TYPENAME_LIST_PATTERN(n)           T##n
#define XL_TUPLE_TYPENAME_LIST(n)                   XL_REPZ(XL_TUPLE_TYPENAME_LIST_PATTERN, n, XL_COMMA)

它将被展开为 T0, T1, T2, …, Tn

定义成员变量声明序列如下：

#define XL_TUPLE_MEMBER_DECLARE_PATTERN(n)          T##n _##n;
#define XL_TUPLE_MEMBER_DECLARE(n)                  XL_REPZ(XL_TUPLE_MEMBER_DECLARE_PATTERN, n, XL_NIL)

它将被展开为：T0 _0; T1 _1; T2 _2; … Tn _n;

现在我们开始组装：

#ifndef XL_TUPLE_DEFINE_MAX
#define XL_TUPLE_DEFINE_MAX  20
#endif

template <XL_TUPLE_TYPENAME_DECLARE_NT(XL_INC(XL_TUPLE_DEFINE_MAX))>
struct Tuple;

template <XL_TUPLE_TYPENAME_DECLARE(n)>
struct Tuple<XL_TUPLE_TYPENAME_LIST(n)>
{
    XL_TUPLE_MEMBER_DECLARE(n)
};

其中后一个还带有宏参数 n。我们将这整一个定义成宏，然后进行宏循环：

#define XL_TUPLE_IMPLEMENT_PATTERN(n)   \
                                        \
template <XL_TUPLE_TYPENAME_DECLARE(n)> \
struct Tuple<XL_TUPLE_TYPENAME_LIST(n)> \
{                                       \
    XL_TUPLE_MEMBER_DECLARE(n)          \
};                                      \

#define XL_TUPLE_IMPLEMENT(n)    XL_REPY(XL_TUPLE_IMPLEMENT_PATTERN, n, XL_NIL)

之后再使用这个宏：

XL_TUPLE_IMPLEMENT(XL_TUPLE_DEFINE_MAX)

到此为止，上文一开始提出的 Tuple 已经实现，并支持到最大约 20 个元素左右。

然后我们可以考虑增加各种方便使用的功能。

1. 默认构造函数。
   
2. 带有 n 个参数的构造函数。相关宏定义：
   #define XL_TUPLE_INITIALIZE_LIST_PATTERN(n)         _##n(_##n)
   #define XL_TUPLE_INITIALIZE_LIST(n)                 XL_REPZ(XL_TUPLE_INITIALIZE_LIST_PATTERN, n, XL_COMMA)
   
3. 拷贝构造函数。相关宏定义：
   #define XL_TUPLE_INITIALIZE_LIST_COPY_PATTERN(n)    _##n(that._##n)
   #define XL_TUPLE_INITIALIZE_LIST_COPY(n)            XL_REPZ(XL_TUPLE_INITIALIZE_LIST_COPY_PATTERN, n, XL_COMMA)
   
4. 赋值函数：
   #define XL_TUPLE_ASSIGN_PATTERN(n)                  this->_##n = that._##n;
   #define XL_TUPLE_ASSIGN(n)                          XL_REPZ(XL_TUPLE_ASSIGN_PATTERN, n, XL_NIL)
   
5. 各种比较函数。请注意对各元素的相应比较运算符的依赖。这里定义成，Tuple 的 < 只依赖于各元素的 <，Tuple 的 != 也只依赖于各元素的 !=，如此类推。
   
   #define XL_TUPLE_EQUAL_PATTERN(n)                   this->_##n == that._##n
   #define XL_TUPLE_EQUAL(n)                           XL_REPZ(XL_TUPLE_EQUAL_PATTERN, n, &&)

#define XL_TUPLE_NOT_EQUAL_PATTERN(n)               this->_##n != that._##n
#define XL_TUPLE_NOT_EQUAL(n)                       XL_REPZ(XL_TUPLE_NOT_EQUAL_PATTERN, n, ||)

#define XL_TUPLE_LITTER_PATTERN(n)                  if (this->_##n < that._##n)         \
                                                    {                                   \
                                                        return true;                    \
                                                    }                                   \
                                                    else if (that._##n < this->_##n)    \
                                                    {                                   \
                                                        return false;                   \
                                                    }
#define XL_TUPLE_LITTER(n)                          XL_REPZ(XL_TUPLE_LITTER_PATTERN, n, XL_NIL)

#define XL_TUPLE_GREATER_PATTERN(n)                 if (this->_##n > that._##n)         \
                                                    {                                   \
                                                        return true;                    \
                                                    }                                   \
                                                    else if (that._##n > this->_##n)    \
                                                    {                                   \
                                                        return false;                   \
                                                    }
#define XL_TUPLE_GREATER(n)                         XL_REPZ(XL_TUPLE_GREATER_PATTERN, n, XL_NIL)

同时 Tuple 中也增加相应的函数，即可。

最终代码见 xlTuple.h，这里不贴了。

请多多指正。

template <typename T1, typename T2>
XXX Min(T1 t1, T2 t2)
{
    return (t1 < t2 ? t1 : t2);
}

其中 XXX 是我们要推导出的类型。

以下是一个失败的尝试。

我记得 Loki 里有关于如何判断某个类型能否隐式转换为另一个类型的东西，大意如下：

template <typename T, typename U>
class Conversion
{
private:
    typedef char Small;
    class Big { char XXX[2]; };
    static Small Test(U);
    static Big Test(...);
    static T MakeT();
public:
    enum
    {
        Exists = (sizeof(Test(MakeT())) == sizeof(Small)),
    };
};

如此，Conversion<T, U>::Exists 就能判断 T 到 U 的转换是否存在了。

然后再搞个选择：

template <bool Condition, typename TypeIfTrue, typename TypeIfFalse>
struct Select
{
    typedef TypeIfFalse Type;
};

template <typename TypeIfTrue, typename TypeIfFalse>
struct Select<true, TypeIfTrue, TypeIfFalse>
{
    typedef TypeIfTrue Type;
};

最后，再来个：

struct NullType;

template <typename T, typename U>
struct CommonType
{
    typedef typename Select<Conversion<T, U>::exists,
                                        U,
                                        typename Select<Conversion<U, T>::exists,
                                                                T,
                                                                NullType>::Type
                                       >::Type Type;
};

那么 CommonType<T1, T2> 就是 T1 和 T2 之间哪个是他们的共有类型了。

测试：

int main()
{
    CommonType<int, double>::Type m = 0;

    return 0;
}

调试，确认 m 是 double 的。但是反过来写 CommonType<double, int>::Type m = 0;，m 却是 int 的。

这说明这套机制一开始就有问题，Test(U) 和 Test(…) 两个重载函数中，Test(…) 不会在需要 double 转 int 时胜出。这是第一个问题。

第二个问题，当写下如下代码的时候：

template <typename T1, typename T2>
CommonType<T1, T2>::Type Min(T1 t1, T2 t2)
{
    return (t1 < t2 ? t1 : t2);
}

编译无法通过。原因是返回类型中的 CommonType 中的模板参数 T、U 无法接受此时还不能确定的 T1、T2。

(更正：不是这个原因，返回类型前加 typename 即可。现在问题还是第一个问题。)

请教各位，有没有什么方法做到？欢迎指教~

C++ 0x 中就能很方便做到了：

template <typename T1, typename T2>
auto Min(T1 t1, T2 t2) -> decltype(t1 + t2)
{
    return (t1 < t2 ? t1 : t2);
}

int main()
{
    int a = 2;
    double b = 1.0;
    auto m = Min(a, b);

    return 0;
}

不知大家有没有发现，当使用 VS 来调试代码的时候，那些 STL 容器的信息会以比较看得懂的方式显示出来：

而我们自己写的，它只能按照数据成员来显示，如果数据结构稍微复杂点，看这些直接显示的内容得到的有用信息就会很少了：

那么，是否有办法能让 IDE 按照我们设想的方式来显示数据呢？答案是肯定的。这个配置就位于 autoexp.txt 中（具体路径为 X:\Program Files\Microsoft Visual Studio 10.0\Common7\Packages\Debugger\autoexp.dat，如果是 VS 不同版本，“Microsoft Visual Studio 10.0”中的版本号换成其他的即可，VS 2005 以上版本都支持）。

在里面搜索 vector，可以找到作用于 vector 的调试信息显示方式的语句：

这个语法的详细官方说明好像没有，不过大体上可以猜出来。

第一行 std::vector<*> 是类型，说明下面的内容针对 std::vector，并且适用于任意模版参数。紧接着是一个大括号括起来的段落。

preview 开始的那一段表示当该变量单行显示的时候该如何显示，也就是下图第二列的样子：

IDE 会依次显示 preview(#( … )) 括号内的以逗号分隔的内容，加引号的会原样显示，变量用 $e 引用（将 $e 视为该类型的一个变量）。

除了直接引号，变量的运算结果外，这里还可以写一些高级点的玩意儿，如 #array，#list，#tree。

#array 的格式为：
#array(
    expr: … ,
    size:  …
)
其中 expr 里可以使用 $i，$i 为元素 index，size 表示元素个数。最终的结果为：
$i=0时的expr, $i=1时的expr, …, $i=size时的expr。

假设有一个结构：
struct Vector
{
    int *pData;
    int nCount;
};
其中 p 是指向一块 count 个 int 的内存。如果要依次显示这 count 个数字，preview 中应该写：
preview (
    #(
        #array(
            expr: $e.pData[$i],
            size: $e.nCount
        )
    )
)

#list 的格式为：
#list(
    head: … ,
    size: … ,
    next: …
) : …
其中 head 是指向第一个 Node 的指针，size 表示元素个数，next 表示 Node 中指向下一个 Node 的分量名，最后冒号后面还要写一个 Node 中的值分量，也就是要显示的那个变量。

假设有结构：
struct ListNode
{
    int nData;
    ListNode *pNext;
};
struct List
{
    ListNode *pHead；
    int nCount;
};
preview 的写法为：
preview (
    #(
        #list(
            head: $e.pHead,
            size: $e.nCount,
            next: pNext
        ) : $e.nData    // 注意，这里的 $e 代表 ListNode，上面两个 $e 都代表 List
    )
)

#tree的格式为
#tree(
    head: …,
    left: …,
    right: …,
    size: …
) : …
其中 head 是指向根节点的指针，left 和 right 分别是指向左右子树的分量名，size 表示元素个数，最后冒号后面写节点中的值分量。IDE会对整棵树做中序遍历。

假设有结构：
struct TreeNode
{
    int nData;
    TreeNode *pLeft;
    TreeNode *pRight;
};
struct Tree
{
    TreeNode *pRoot;
    int nCount;
};
preview 的写法为：
preview (
    #(
    #tree(
        head: $e.pRoot,
        left: pLeft,
        right: Right,
        size: $e.nCount
        ) : $e.nData // 注意，这里的 $e 代表 TreeNode，上面两个 $e 都代表 Tree
    )
)

preview 的格式就到此。接下来是 children，它用于描述点击变量左边的加号后，展开的内容怎么显示，如图：

IDE 会依次显示 children(#( … )) 括号内的以逗号分隔的内容，每个显示为一行。刚才的 #array, #list, #tree 都可以用，会显示成第一列索引第二列值的样子。
另外可以用 #(first, second) 的格式，first 会原样显示在第一列，second 会求值显示在第二列。

了解以上这些内容，我们已经可以针对 STL 的那些数据结构做自定义显示了，对一些别的数据结构作简单的自定义显示也不难。

最后给个效果图，定义了我自己的那些容器的显示方式。怎么样，看上去一定比开头给出的那个冷冰冰的样子好很多吧？

C++ 下 Function 对象的实现（上）
C++ 下 Function 对象的实现（下）

上篇中，我们实现了一个支持 R () 型函数的 Function。补充说明一下，在我们对成员函数的支持中，我们是这样定义的：

template <typename R, typename T>
class MemberFunction0 : public FunctionBase0<R>
{

private:
    R (T::*m_pMemFun)();
    T *m_pObj;
};

Loki 特意在著作中提醒我们，这里的 T 最好不要是函数类型，改为函数指针类型，如此该类的支持范围将扩大。如下：

template <typename R, typename P, typename T>
class MemberFunction0 : public FunctionBase0<R>
{
public:
    R Invoke()
    {
        return (m_pObj->*m_pMemFun)();
    }

public:
    MemberFunction0(P pObj, R (T::*pMemFun)())
        : m_pObj(pObj), m_pMemFun(pMemFun)
    {

    }

private:
    R (T::*m_pMemFun)();
    P m_pObj;
};

于是，P 和 T 的关系不那么紧密了，P 不一定非要 T* 不可，也可以是诸如 SmartPtr<T> 之类的玩意儿。原本只支持传入一个对象和该对象的成员函数的，现在变成传入一个具有指针概念的东东和一个成员函数，只要这个“指针”使用运算符 –> 去调用那个成员函数合乎语法即可。

接下来，我们来扩展这个 Function，以支持拥有数目在给定上限内的任意参数的函数。

我们先来手工写一下，看看如何支持带一个参数的函数。首先定义一个虚基类：

template <typename R, typename T0>
class FunctionBase1
{
public:
    virtual R Invoke(T0) = 0;
    virtual ~FunctionBase1() {}
};

实现两个版本，分别支持非成员函数和成员函数：

template <typename R, typename T0, typename T>
class Function1 : public FunctionBase1<R, T0>
{
public:
    R Invoke(T0 v0)
    {
        return m_Fun(v0);
    }

public:
    Function1(const T &fun)
        : m_Fun(fun)
    {

    }

private:
    T m_Fun;
};

template <typename R, typename P, typename T, typename T0>
class MemberFunction1 : public FunctionBase1<R, T0>
{
public:
    R Invoke(T0 v0)
    {
        return (m_pObj->*m_pMemFun)(v0);
    }

public:
    MemberFunction1(P pObj, R (T::*pMemFun)(T0))
        : m_pObj(pObj), m_pMemFun(pMemFun)
    {

    }

private:
    R (T::*m_pMemFun)(T0);
    P m_pObj;
};

增加一个函数引用萃取的偏特化版本：

template <typename RetType, typename T0>
struct FunctionTraits<RetType (T0)>
{
    typedef RetType (&ParamType)(T0);
};

增加一个 Function 类的偏特化版本：

template <typename R, typename T0>
class Function<R (T0)>
{
public:
    template <typename T>
    Function(const T &fun)
        : m_pFunBase(new Function1<R, T0, typename FunctionTraits<T>::ParamType>(fun))
    {
       
    }

    template <typename P, typename T>
    Function(P pObj, R (T::*pMemFun)(T0))
        : m_pFunBase(new MemberFunction1<R, P, T, T0>(pObj, pMemFun))
    {

    }

    ~Function()
    {
        delete m_pFunBase;
    }

    R operator ()(T0 v0)
    {
        return m_pFunBase->Invoke(v0);
    }

private:
    FunctionBase1<R, T0> *m_pFunBase;
};

现在，我们可以跑一下测试代码了：

Function<int (int)> f1(&intfun1);
Function<int (int)> f1_(intfun1);
Function<int (int)> f2(intfunctor1);
Function<int (int)> f3(&test, &Test::intmem1);

f1(1);
f1_(1);
f2(2);
f3(3);

当然，void 函数也是支持的。

观察上面的这些代码，和我们在上一篇中的代码高度一致，不同的是那些模版参数、偏特化参数、函数调用参数等地方。

假如有这么一组宏：
TYPENAME_DECLARE(n) 被定义为 typename T0, typename T1, …, typename Tn
TYPENAME_LIST(n) 被定义为 T0, T1, …, Tn
TYPENAME_VARIABLE(n) 被定义为 T0 v0, T1 v1, …, Tn vn
VARIABLE_LIST(n) 被定义为 v0, v1, …, vn

那么我们可以使用一个 n 就写出支持所有具有参数的函数的 Function 了。我们抛弃掉上面的 1 系列的所有类，仅保持上篇留下来的代码，然后利用上面 4 个宏将所有数字尾巴去掉，于是代码变成：

template <typename R, TYPENAME_DECLARE(n)>
class FunctionBase_##n
{
public:
    virtual R Invoke(TYPENAME_LIST(n)) = 0;
    virtual ~FunctionBase_##n() {}
};

template <typename R, TYPENAME_DECLARE(n), typename T>
class Function_##n : public FunctionBase_##n<R, TYPENAME_LIST(n)>
{
public:
    R Invoke(TYPENAME_VARIABLE(n))
    {
        return m_Fun(VARIABLE_LIST(n));
    }

public:
    Function_##n(const T &fun)
        : m_Fun(fun)
    {

    }

private:
    T m_Fun;
};

template <typename R, typename P, typename T, TYPENAME_DECLARE(n)>
class MemberFunction_##n : public FunctionBase_##n<R, TYPENAME_LIST(n)>
{
public:
    R Invoke(TYPENAME_VARIABLE(n))
    {
        return (m_pObj->*m_pMemFun)(VARIABLE_LIST(n));
    }

public:
    MemberFunction_##n(P pObj, R (T::*pMemFun)(TYPENAME_LIST(n)))
        : m_pObj(pObj), m_pMemFun(pMemFun)
    {

    }

private:
    R (T::*m_pMemFun)(TYPENAME_LIST(n));
    P m_pObj;
};

template <typename RetType, TYPENAME_DECLARE(n)>
struct FunctionTraits<RetType (TYPENAME_LIST(n))>
{
    typedef RetType (&ParamType)(TYPENAME_LIST(n));
};

template <typename R, TYPENAME_DECLARE(n)>
class Function<R (TYPENAME_LIST(n))>
{
public:
    template <typename T>
    Function(const T &fun)
        : m_pFunBase(new Function_##n<R, TYPENAME_LIST(n), typename FunctionTraits<T>::ParamType>(fun))
    {
       
    }

    template <typename P, typename T>
    Function(P pObj, R (T::*pMemFun)(TYPENAME_LIST(n)))
        : m_pFunBase(new MemberFunction_##n<R, P, T, TYPENAME_LIST(n)>(pObj, pMemFun))
    {

    }

    ~Function()
    {
        delete m_pFunBase;
    }

    R operator ()(TYPENAME_VARIABLE(n))
    {
        return m_pFunBase->Invoke(VARIABLE_LIST(n));
    }

private:
    FunctionBase_##n<R, TYPENAME_LIST(n)> *m_pFunBase;
};

当然上面这样子的代码是没法跑的咯。如果我们将整段代码定义为一个宏 BODY(n)，然后用类似刚才四个宏的方式定义宏 FUNCTION_IMPLEMENT(n)，使得它的含义为 BODY(0), BODY(1), …, BODY(n)，所有工作就都完成了。最后只需要丢下一句 FUNCTION_IMPLEMENT(20)，就可以支持 0 到 21 个参数了。

最后归结为，如何使用宏搞出“T0, T1, …, Tn” 的形式。

暴力点，我们可以这样：

#define T_0 T0
#define T_1 T_0, T1
#define T_2 T_1, T2
#define T_3 T_2, T3
#define T_4 T_3, T4
#define T_5 T_4, T5
#define T_6 T_5, T6
#define T_7 T_6, T7
#define T_8 T_7, T8
#define T_9 T_8, T9

#define T(n) T_##n

这样子，对于上面四个宏可以，但是对于最后的 X(n)，人工代码量还是太大了。嗯？X(n)？对，这个 X，必须在 _1、_2、_3 系列宏里面占据一个参数地位，这样才有那么一点点扩展性。考虑换成这样：

#define REP_0(macro, n) macro(0)
#define REP_1(macro, n) REP_0(macro, n), macro(1)
#define REP_2(macro, n) REP_1(macro, n), macro(2)
#define REP_3(macro, n) REP_2(macro, n), macro(3)
#define REP_4(macro, n) REP_3(macro, n), macro(4)
#define REP_5(macro, n) REP_4(macro, n), macro(5)
#define REP_6(macro, n) REP_5(macro, n), macro(6)
#define REP_7(macro, n) REP_6(macro, n), macro(7)
#define REP_8(macro, n) REP_7(macro, n), macro(8)
#define REP_9(macro, n) REP_8(macro, n), macro(9)

#define REP(macro, n)   REP_##n(macro, n)

然后：

#define TYPENAME_LIST_PATTERN(n)    T##n
#define TYPENAME_LIST(n)            REP(TYPENAME_LIST_PATTERN, n)

这个 TYPENAME_LIST 就是符合上文要求的宏。接下来如法炮制其余三个：

#define TYPENAME_DECLARE_PATTERN(n)     typename T##n
#define TYPENAME_DECLARE(n)             REP(TYPENAME_DECLARE_PATTERN, n)

#define TYPENAME_VARIABLE_PATTERN(n)    T##n v##n
#define TYPENAME_VARIABLE(n)            REP(TYPENAME_VARIABLE_PATTERN, n)

#define VARIABLE_LIST_PATTERN(n)        v##n
#define VARIABLE_LIST(n)                REP(VARIABLE_LIST_PATTERN, n)

最后，我们在 #define FUNCTION_IMPLEMENT(n)  REP(BODY, n) 中还存在一点点问题。因为 BODY 中会含有 TYPENAME_DECLARE 之类的宏的使用，而 TYPENAME_DECLARE 正是使用 REP 定义的。这涉及到宏的递归展开，C++预处理器的规则是，遇到这样的情况就停止展开。比如，我们 定义 BODY(n) 为 TYPENAME_DECLARE(n)，于是 FUNCTION_IMPLEMENT(2) 会被展成：

REP(TYPENAME_DECLARE_PATTERN, 0), REP(TYPENAME_DECLARE_PATTERN, 1), REP(TYPENAME_DECLARE_PATTERN, 2)

上面的 REP 不会被继续展开了。

为此，一个不太聪明的办法就是，再定义一组 REP2。嗯，是个办法，就这么办吧。另外我们刚才的 REP 系列没有将分隔符作为参数，默认使用逗号，而最后一不的 FUNCTION_IMPLEMENT 的重复中是不能用逗号的。考虑提取出来作为参数。最后我们的所需要的宏系统是：

#define NIL
#define COMMA ,

#define REP_0(macro, splitter, n) macro(0)
#define REP_1(macro, splitter, n) REP_0(macro, splitter, n) splitter macro(1)
#define REP_2(macro, splitter, n) REP_1(macro, splitter, n) splitter macro(2)
#define REP_3(macro, splitter, n) REP_2(macro, splitter, n) splitter macro(3)
#define REP_4(macro, splitter, n) REP_3(macro, splitter, n) splitter macro(4)
#define REP_5(macro, splitter, n) REP_4(macro, splitter, n) splitter macro(5)
#define REP_6(macro, splitter, n) REP_5(macro, splitter, n) splitter macro(6)
#define REP_7(macro, splitter, n) REP_6(macro, splitter, n) splitter macro(7)
#define REP_8(macro, splitter, n) REP_7(macro, splitter, n) splitter macro(8)
#define REP_9(macro, splitter, n) REP_8(macro, splitter, n) splitter macro(9)

#define REP(macro, splitter, n)   REP_##n(macro, splitter, n)

#define REP2_0(macro, splitter, n) macro(0)
#define REP2_1(macro, splitter, n) REP2_0(macro, splitter, n) splitter macro(1)
#define REP2_2(macro, splitter, n) REP2_1(macro, splitter, n) splitter macro(2)
#define REP2_3(macro, splitter, n) REP2_2(macro, splitter, n) splitter macro(3)
#define REP2_4(macro, splitter, n) REP2_3(macro, splitter, n) splitter macro(4)
#define REP2_5(macro, splitter, n) REP2_4(macro, splitter, n) splitter macro(5)
#define REP2_6(macro, splitter, n) REP2_5(macro, splitter, n) splitter macro(6)
#define REP2_7(macro, splitter, n) REP2_6(macro, splitter, n) splitter macro(7)
#define REP2_8(macro, splitter, n) REP2_7(macro, splitter, n) splitter macro(8)
#define REP2_9(macro, splitter, n) REP2_8(macro, splitter, n) splitter macro(9)

#define REP2(macro, splitter, n)   REP2_##n(macro, splitter, n)

#define TYPENAME_DECLARE_PATTERN(n)     typename T##n
#define TYPENAME_DECLARE(n)             REP(TYPENAME_DECLARE_PATTERN, COMMA, n)

#define TYPENAME_LIST_PATTERN(n)        T##n
#define TYPENAME_LIST(n)                REP(TYPENAME_LIST_PATTERN, COMMA, n)

#define TYPENAME_VARIABLE_PATTERN(n)    T##n v##n
#define TYPENAME_VARIABLE(n)            REP(TYPENAME_VARIABLE_PATTERN, COMMA, n)

#define VARIABLE_LIST_PATTERN(n)        v##n
#define VARIABLE_LIST(n)                REP(VARIABLE_LIST_PATTERN, COMMA, n)

#define FUNCTION_IMPLEMENT(n)  REP2(BODY, NIL, n)

最后，定义一下 FUNCTION_IMPLEMENT(5)，就可以支持到 6 个参数了。为了支持更多参数，把上面的 REP 以及 REP2 系列多定义一点，比如到 50，那么 FUNCTION_IMPLEMENT 的括号中就可以填 50 以内的任意数了。考虑到宏展开对编译速度的影响，以及实际应用中函数参数的个数，定为 20 左右比较合适。

到这里，我们的Function已经实现了预期目标。接下来我本来想说说 TypeList 的。可是现在发现没有 TypeList，Function 跑的通；有了 TypeList，Function 也不能写的漂亮多少，虽说那些重复部分有一定的减少。Loki 的 Functor 的参数类型是一个返回值类型加上一个 TypeList，是由用户直接传入 TypeList 的，不用由散的类型组合出一个TypeList（但还是要从TypeList中萃取各个参数类型），因此用在他那里看上去美妙一点点。当然，Loki 也在 Functor 外头包了一层 Function，以支持函数签名作为模版参数的使用方式。有一点不算改观的改观是，用了 TypeList 以后，就不会再有 FunctionBase_1, FunctionBase_2 这样的玩意儿了，取而代之的是一个统一的 FunctionBase 外加许多偏特化版本，Function* 和 MemberFunction* 可以分别统一为一个，但是每一个里头都需要实现 N 个 Invoke。加上篇幅关系，我想这里就不说这个 TypeList 了。

代码清单太长了，就不贴了，有意者自然能凑起来。我目前在 xlLib 中的最终实现见 xlFunction.h。

关于宏，我不知道可以怎样改进。BOOST_PP_REPEAT 貌似可以调用自身？不知道如何实现的，求指教。另外@vczh貌似说“实现了一门可以自己递归自己和内置列表处理的另一个宏”，求分享呀求分享。

2010-01-18 补充：将最外层 Function 的构造函数中的 const T & 直接改为 T，并且抛弃 FunctionTraits，函数实体类型将在传递过程中直接退化为函数指针，这样就能特化出正确的 FunctionHandler。同时带来另一点影响：如果传入 Functor，字面上将多一次拷贝动作。抛开这一点微小的性能来讲，这比刚才的 FunctionTraints 要好得多了。

C++ 下 Function 对象的实现（上）
C++ 下 Function 对象的实现（下）

起因在上一篇已经说过了。现在让我们直接进入主题。本文的目标是，让以下代码能顺利跑起来：

int intfun0()
{
    return 1;
}

struct _intfunctor0
{
    int operator()()
    {
        return 2;
    }

} intfunctor0;

struct Test
{
    int intmem0()
    {
        return 3;
    }

} test;

int main()
{
    Function<int ()> f1(&intfun0);
    Function<int ()> f1_(intfun0);
    Function<int ()> f2(intfunctor0);
    Function<int ()> f3(&test, &Test::intmem0);

    f1();
    f1_();
    f2();
    f3();

    return 0;
}

除了上述例子中显示的，还要支持有返回值的函数和没返回值的函数，以及有0个、1个、2个、……、MAX 个参数的函数，参数类型无限制。最后实现的 Function 对象仅仅可以执行就好。（至于是否可拷贝、是否可判断相等 等问题，都是小事，本文暂不考虑。）最后，Bind 概念也不在本文讨论范围之内。

对于这个问题，我们一开始考虑的可能是怎样统一三种不同形式。有两个选择，第一，使用 C++ 的多态机制，最后统一到基类指针的类型；第二，允许类内部有冗余变量以及必要的 Flag，用于判断是哪种形式的函数，要如何执行。这样看起来，第一种方案比第二种爽一点。于是，最初想到的实现有可能是这样的：

先定义一个虚基类：

template <typename R>
class FunctionBase0
{
public:
    virtual R Invoke() = 0;
    virtual ~FunctionBase0() {}
};

然后实现一个普通函数/仿函数的版本：

template <typename R, typename T>
class Function0 : public FunctionBase0<R>
{
public:
    R Invoke()
    {
        return m_Fun();
    }

public:
    Function0(const T &fun)
        : m_Fun(fun)
    {

    }

private:
    T m_Fun;
};

这里需要说明的是，如果是普通函数，T会被特化成 R() 或者 R (&)() 或者 R(*)()，取决于使用的时候传入 fun 还是传入 &fun。所以不必另外实现针对 R(*)() 的版本。Loki （姑且就以作品名称乎 Loki 的作者吧，他那个真名实在是太长）在他的书中称之为“做一个，送一个”。不过对于他书中所说的，我有一个疑惑。Loki 说传入 fun，模版参数 T 会被特化成 R (&)()，于是一切顺利。可是我在操作过程中发现 T 一直被特化成 R ()，于是上述 class 中的 m_Fun 被认为是成员函数而不是成员变量。不知道是为什么，有知道者请不吝指教哈。因为以上原因，本文中我一直用 &fun 的形式对待普通函数。

再实现一个成员函数的版本：

template <typename R, typename T>
class MemberFunction0 : public FunctionBase0<R>
{
public:
    R Invoke()
    {
        return (m_pObj->*m_pMemFun)();
    }

public:
    MemberFunction0(T *pObj, R (T::*pMemFun)())
        : m_pObj(pObj), m_pMemFun(pMemFun)
    {

    }

private:
    R (T::*m_pMemFun)();
    T *m_pObj;
};

最后是一个包装类。如果你可以接受 Function<int> 表示 int()， Function<int, int> 表示 int (int)，…，那么这里没有多少技巧可言。boost 的那个 function 使用的是函数签名作为模版参数，即 Function<int()>，Function<int (int)> 等形式。如果不太研究语法，可能会像我一样，一开始会对尖括号里的 int (int) 之类的玩意儿不太熟悉，觉得很牛逼。可是了解了以后，不过是个函数类型而已，没什么大不了的。Loki 的 Functor 的使用方式是 Functor<int, TYPELIST_0()>，Functor<int, TYPELIST_1(int)>。其中第一个模版参数始终是返回值，第二个模版参数是参数类型列表，Loki 使用了他创造的玩意儿 TypeList 使得所有函数参数只占一个坑，这在等下的支持多参数的扩展中能够带来一些美观。我比较喜欢 boost 的使用方式，让使用者直接以语言规定的形式填入函数签名，而不是一些额外的约定（“第一个模版参数表示返回值”，“第二个到最后的模版参数表示参数”，“第二个模版参数以 TypeList 形式表示函数参数”等）。

为了达到这个目标，我们要玩一些偏特化技巧。关于偏特化，我一直以来的肤浅认识都是错误的。我原以为，对于模版类：

template <typename T0, typename T1>
class Foo;

我如果特化其中一个参数 T1：

我以为只有这样才叫偏特化，以为偏特化的过程总是减少模版参数的。而实际上，只要用某个/些类型占据原始模版参数的位置，就可以了。比如，对于上述 Foo，我可以特化一个 class<T0, std::map<U0, U1>>，消去一个 T1，而新增 U0、U1：

原来 T1 的位置被 std::map<U0, U1> 占据了，这也是偏特化。当然最后的模版参数数量也可以不变，如：

以及

其中后者是实现类型萃取的主要方式。只要特化以后，这个类依然带有至少一个模版参数，就是偏特化。如果最后产生了 template<> 的形式，那就是完全特化。

回到我们刚才的主题，我们要提供给用户的是这样一个类：

template <typename Signature>
class Function;

其中参数 Signature 会被实际的函数类型所特化。但是我们只知道整体的一个 Signature 并没有用，我们必须知道被分解开来的返回值类型、参数类型。于是，引入一个偏特化版本：

template <typename R>
class Function<R ()>

这里使用 R () 特化原始的 Signature，引入一个新的参数 R。于是返回值类型 R 就被萃取出来了。实现如下：

template <typename R>
class Function<R ()>
{
public:
    template <typename T>
    Function(const T &fun)
        : m_pFunBase(new Function0<R, T>(fun))
    {
       
    }

    template <typename T>
    Function(T *pObj, R (T::*pMemFun)())
        : m_pFunBase(new MemberFunction0<R, T>(pObj, pMemFun))
    {

    }

    ~Function()
    {
        delete m_pFunBase;
    }

    R operator ()()
    {
        return m_pFunBase->Invoke();
    }

private:
    FunctionBase0<R> *m_pFunBase;
};

如果对上面说的“普通函数的使用方式必须是函数指针而不是函数本身”耿耿于怀，可以再引入一个的构造函数：

typedef R (FunctionType)();

Function(const FunctionType &fun)
    : m_pFunBase(new Function0<R, FunctionType &>(fun))
{

}

这里 FunctionType 是 R(&)() 类型，强制使用它来特化 Function0 中的 T。该构造函数在重载决议中会取得优先权从而使普通函数本身的传入成为可能。不过，以函数本身形式传入的普通函数会丧失一些特性，比如 Function<int()> 只能接受 int() 类型的普通函数而不能接受 char () 型的普通函数，因为这种情况下不会走我们刚才新定义的构造函数。

还有一种做法，就是针对全局函数，强制特化出模版参数为其引用类型的类。定义如下元函数：

template <typename Signature>
struct FunctionTraits
{
    typedef Signature ParamType;
};
   
template <typename RetType>
struct FunctionTraits<RetType ()>
{
    typedef RetType (&ParamType)();
};

然后构造函数改为：

用以上方法，所有的特性都不会丢失。

到这儿，我们的 Function 已经可以小试牛刀了：

Function<int ()> f1(&intfun0);

f1();
f1_();
f2();
f3();

上面这段代码已经能够正常运行了。

来，继续做一个，送一个。下面的代码居然也能跑（voidfun0、voidfunctor0、Test::voidmem0类似int版本定义）：

f4();
f4_();
f5();
f6();

这说明了，在类里面写一个返回值为该类型的函数，并在里面写下 return XXX; 然后以 void 为模版参数传入该模版类，是符合语法的。验证一下：

template <typename T>
class Foo
{
public:
    T Bar()
    {
        printf("%s invoked\n", __FUNCTION__);
        return T();
    }
};

int main()
{
    Foo<void> f1;
    f1.Bar();

    Foo<int> f2;
    int i = f2.Bar();

    return 0;
}

运行结果：

Foo<void>::Bar invoked
Foo<int>::Bar invoked

到此为止，我们已经实现了 0 个参数的函数支持，也即 R () 类型的所有函数的支持。接下来还要实现对具有 1 个、2 个、3 个直至任意有限个参数的函数支持。也许您也发现了，接下来的工作可以是体力活，我们可以照葫芦画瓢，搞出一堆 FunctionBaseN、FunctionN、MemberFunctionN，并在最后的 Function 中再实现 N 个偏特化版本。是，不错，大致上原理就是这样。限于篇幅，我想暂时写到这里，下篇将继续谈谈宏、TypeList，以及怎样少花点力气实现其余 N 个版本。最终达到的效果是，只要改一个宏定义，就可以提高参数上限。

在本文所涉及的内容中，我比较纠结的是，可否在不用多态机制的情况下达到比较优雅的形式统一？

欢迎讨论。