如果把用户的各种信息都抽象成“物品”、“个数”，那么所有的游戏逻辑都是用户之间的物品交换。

为了方便描述，我来自定义一套语法表示这种交换。这里用的是类BNF语法，如果没耐心可跳过。

物品交换 := 物品描述 “=>” 物品描述

物品描述 := 物品描述 “+” 单个物品描述 | 单个物品描述

单个物品描述 := 用户 “(” 物品 “,” 数量 附加属性 “)”

物品 := 物品名称 | 物品函数

物品函数 := rand “(” 物品列表 “)”

物品列表 := 物品列表 “,” 物品 | 物品

附加属性 :=”,” “{” 附件属性列表 “}” | “”

附加属性列表 := 附加属性列表 “,” 属性 | 属性

属性 := 属性名 “:” 属性值

数量 := 数字 | 数字函数

数字 := 非负整数 | MAX

数字函数 := auto_change “(” 初始值 “,” 每秒变化步长 “,” 边界值 “)”
| max “(” 数字列表 “)”

数字列表 := 数字列表 “,” 数字 | 数字

函数说明：

• rand代表在一系列物品名称中返回任意选一个物品名称。
• MAX代表该物品最大数量值
• max代表从一系列数字中返回最大值
• auto_change代表从初始值开始，每隔1秒时间就加上步长，直到达到边界值为止不再变化。auto_change并非如其名一般会自动变化，而是在下次请求该物品数量的时候才计算当前值。步长可以为负。

希望不要看这些BNF晕了头……直接看例子其实也可以。

列举一下常见的游戏场景背后的数字逻辑：

• 用户A用100游戏币买一个桌子获得10点经验：
  • A (游戏币, 100) => A (桌子, 1) + A (经验, 10)
  • 注：这里把游戏币、经验都当做物品来处理，从程序角度来说这没有问题，虽然直观上有点怪。
• 用户A使用10点幸运点打开一个宝箱得到一个物品，这个物品是玩具1、玩具2、玩具3中随机的一个：
  • A (宝箱, 1) + A (幸运点, 10) => A (rand(玩具1, 玩具2, 玩具3), 1)
• 用户A送用户B一个玩具，留言“my present”，获得10点经验：
  • A (玩具, 1) => B (礼物, 1, {留言: my present, 关联物品: 玩具, 关联数量: 1, 时间: YYYY-MM-DD}) + A (经验, 10)
  • B (礼物, 1, {留言: my present, 关联物品: 玩具, 关联数量: 1, 时间: YYYY-MM-DD}) => B (玩具, 1)
• 用户A在一号树坑种下一棵树，将在3000秒后长成桃子共4颗，其中最多2个可以被偷走，而B偷走了1个获得10点经验，A则收走了剩下3个，获得20点经验：
  • A (树种子, 1) => A (成长中的桃子, auto_change(0, 1, 3000), {土地号: 1})
  • A (成长中的桃子, 3000, {土地号: 1}) => A (私有桃子, 2, {土地号: 1}) + A (公有桃子, 2, {土地号: 1})
  • A (公有桃子, 1, {土地号: 1}) => B (桃子, 1) + B (经验, 10)
  • A (公有桃子, 1, {土地号: 1}) + A (私有桃子, 2, {土地号: 1}) => A (桃子, 3)
  • 注：当任何一个可以看到桃子树状态的用户刷新状态且第二步中输入的数值满足要求时，第二步物品交换就会发生。
• 用户A接了一个任务X，用玩具1和玩具2，可以换得100游戏币和10点经验，任务有效时间为30,000秒，且A最多能接5个任务：
  • A (可接任务, 1) => A (任务X, auto_change(30000, -1, 0))
  • A (任务X, max(1, MAX)) + A (玩具1, 1) + A (玩具2, 2) => A (游戏币, 100) + A (经验, 10) + A (可接任务, 1) + A (已完成的任务X, 1)
  • A (任务X, MAX) => A (可接任务, 1)
  • 注1：A的初始可接任务设置为5就能限制A最多接5个任务
  • 注2：第三步为取消任务逻辑
• 用户A将一个桌子从储物箱里面挪到1号房间，又从1号房挪到了2号房：
  • A (桌子, 1) => A (桌子, 1, {x: 10, y: 0, room: 1})
  • A (桌子, {x: 10, y: 0, room: 1}) => A (桌子, {x: 20, y: 10, room: 2})

仅仅通过这些很基本的物品交换逻辑，（理论上）就可以实现一个比较复杂的游戏数值逻辑了。只要实现一个服务，把所有这些可能的物品交换逻辑都放在某个配置里面，游戏核心就出来了。

这种做法也有不足，有些时候客户端需要从右边推导出左边的可选值就比较麻烦。比如物品1可以由游戏币或充值币其一换得，客户端需要根据物品1反查出游戏币和充值币各自需要的数量。这在技术上其实可行，只是需要花费更多精力去想明白里面的需求。

Firefox拥有众多的扩展（Extension），开发扩展也非常容易，不过有一些事情还是无法用扩展解决，需要访问操作系统的底层功能，这就需要写插件（plugins）。例如flash就是一个插件而不是扩展。

Mozilla提供了一系列的教程和文档，虽然很不详尽，众多重要的API语焉不详，但至少是一个好的开始。

最需要阅读的是plugins API和使用入门。这是一个相当长的文档，如果看完所有的内容会花费大量的时间而且还会很晕，这里列一些重点供参考。

• plugins基础概念
• 写第一个插件（只需要关注Writing Plug-ins这一节所谈到的内容）
• 获得一份firefox的源码，比如firefox 3.6。plugins的例子可以在源码里找到（modules/plugin/sdk/samples），如果出了问题还可以自己编译一个debug版的firefox来调试。
• 了解浏览器能提供什么功能
• 制作插件的安装程序，推荐用扩展的方式安装插件，有无数的好处

完成以上这些内容以后差不多就已经可以实现自己的插件了，一般而言，参照着例子来做开发不会有什么问题，只是有不少细节需要留意。

Firefox plugins开发的众多奇怪的约定（假设plugins已经被正确安装）

有些约定非常奇怪，不要问我为什么，天晓得开发firefox的牛人们怎么想的。

在Windows下，plugins必须满足以下条件才能被firefox检测到：

• 插件的名字必须是np*.dll，也就是必须以np开头，.dll结尾
• 插件dll资源的语言必须为LANG_ENGLISH，code page必须为1252。在rc文件里是这么写的：
  
LANGUAGE LANG_ENGLISH, SUBLANG_ENGLISH_US
#pragma code_page(1252)

• 插件dll的VERSION_INFO里面必须包含以下值：

  VALUE "MIMEType", "application/x-your-mimetype"

  这个MIME就是<object>标签引用插件的唯一凭证。

在Linux下，plugins必须满足以下条件才能被检测到：

• 插件的名字必须是lib*plugin.so，即以lib开头，plugin.so结尾
• 插件必须实现NP_GetMIMEDescription和NP_GetPluginVersion，并返回合适MIME字符串。注意，这个字符串并不是普通的MIME，是有特殊规则的，详见前面这个链接的内容。
• 插件so不要静态链接gtk、opensll、pthread、z等系统库，这会在不同linux平台上因为符号表的问题遇到各种运行时错误

特别需要说明的是，NP_GetPluginVersion、NP_GetEntryPoints等关键函数没有任何官方文档介绍它们，只能根据例子来猜，反正没事就别改它们的实现，copy例子中的代码就好。

firefox插件开发注意事项

写firefox插件的一个基本习惯是，经常编译代码并运行它，保证你的插件还能工作。只要firefox无法加载dll/so，或者加载出现任何错误，都会悄无声息的忽略这个插件。时常关注一下about:plugins，看看插件是不是还在这个列表里。

firefox插件从窗口模式上可分为windowless和windowed两种。其中，windowless模式的文档较多较全，是firefox比较推荐的模式，坑比较少，这里就不多说了。windowed模式则相反，需要好好说说。

无论在Windows还是Linux上，windowed的插件都拥有独立于浏览器页面的窗口。firefox会通过插件的NPP_SetWindow来告诉插件当前窗口的情况。

关于windowed插件有两个诡异问题需要注意：

• Windows平台下，插件窗口默认会响应WM_CTLCOLOREDIT、WM_CTLCOLORLISTBOX、WM_CTLCOLORBTN、WM_CTLCOLORSTATIC消息，并设置一个默认的背景色。这本来没问题，但在Windows XP下，这个颜色居然永远是黑色，而不是默认系统背景色（通常是白色）。最好subclass这个窗口并且拦截这些消息，不要让firefox去处理它们。对于插件来说，firefox处理这些消息只是帮倒忙而已。至于firefox还帮了哪些倒忙，可以去源码widget/src/windows/nsWindows.cpp的nsWindow::ProcessMessage()去围观。
• Linux平台下，NPP_SetWindow传入的NPWindow指针中虽然有一个ws_info成员，这个成员里面也确实有一个display变量指向X Window的Display结构，但绝对不要真正使用它，否则可能会导致firefox直接退出，据说这可能是firefox的一个bug。

测试firefox插件小技巧，测试方面的高手可以无视

测试插件前建议先在firefox里面创建一个新的profile（帐号）。这样可以创造一个最干净的开发环境，避免被其他扩展/插件干扰。

默认的profile名叫default，在命令行里输入firefox -p default就可以使用这个profile。如果只是输入firefox -p，会弹出一个对话框用于选择profile。这个命令在Windows和Linux下都可使用。

无论是哪个平台，调试插件的方法都很类似。

Windows下可以用VC以调试方式启动firefox，载入插件时调试器会自动载入对应的符号，捕捉发生的异常或者设断点都很方便。

Linux下直接用gdb就好，细节应该不用多说。有一点需要注意，系统默认安装的firefox命令（默认放在/usr/bin/firefox）是一个shell脚本，真正的可执行文件名字需要打开这个脚本自行查找。

实现firefox插件的基本功能

firefox为插件提供的接口十分原始，很多功能默认没有实现，下面提供了一些思路和方法。

• 让插件接受焦点：默认情况下，<object>标签不能获得焦点，必须指定tabindex。
• 在插件中使用tab键跳到下一个element：没有好办法，必须自己手动将焦点还给浏览器窗口（Linux下不必如此），然后自己用NPN_*系列函数找到应该获得focus的DOM element，然后调用这个element的focus()方法。
• 隐藏和显示插件：直接设置<object>标签的style.display = “none”即可，但这里有个严重的副作用，firefox会调用插件的NS_PluginShutdown，销毁这个插件。如果不期望造成这种效果，要么别用这种方式隐藏插件，要么把插件状态保存在js里，再次显示的时候把状态设回去。
• 触发DOM事件：firefox没有提供任何便利的方法触发DOM事件，要在插件中做到这点，必须自己模拟js触发DOM事件的过程。例如，对于HTML事件，假设self是DOM element，js会这么做。
  
evt = document.createEvent("KeyboardEvent");
evt.initKeyEvent(
"blur", // in DOMString typeArg,
false, // in boolean canBubbleArg,
false); // in boolean cancelableArg,
self.dispatchEvent(evt);

  对应的C代码就是

void FireHTMLEvent(NPP npp, const string & name)
{
    NPVariant result;
    NPObject *window;
    NPVariant vDoc;

    NPN_GetValue(npp, NPNVWindowNPObject, &window);

    // 也许页面已经跳转了……
    if (!window) {
        return;
    }

    NPIdentifier sDocument = NPN_GetStringIdentifier("document");
    NPN_GetProperty(npp, window, sDocument, &vDoc);
    NPN_ReleaseObject(window);

    // evt = document.createEvent("KeyboardEvent");
    NPVariant evt;
    NPObject* npDoc = NPVARIANT_TO_OBJECT(vDoc);
    NPIdentifier createEvent = NPN_GetStringIdentifier("createEvent");
    NPVariant eventArgs[1];
    STRINGZ_TO_NPVARIANT("HTMLEvents", eventArgs[0]);
    NPN_Invoke(npp, npDoc, createEvent, eventArgs, 1, &evt);
    NPN_ReleaseObject(npDoc);

    // evt.initKeyEvent(
    //    "blur",      //  in DOMString typeArg,
    //    false,            //  in boolean canBubbleArg,
    //    false);            //  in boolean cancelableArg,
    NPObject * npEvt = NPVARIANT_TO_OBJECT(evt);
    NPIdentifier initKeyEvent = NPN_GetStringIdentifier("initEvent");
    NPVariant initArgs[3];
    STRINGZ_TO_NPVARIANT(name.c_str(), initArgs[0]);
    BOOLEAN_TO_NPVARIANT(false, initArgs[1]);
    BOOLEAN_TO_NPVARIANT(false, initArgs[2]);
    NPN_Invoke(npp, npEvt, initKeyEvent, initArgs, 3, &result);
    NPN_ReleaseVariantValue(&result);

    // this.dispatchEvent(evt);
    NPObject * self;
    NPN_GetValue(npp, NPNVPluginElementNPObject, &self);
    NPIdentifier dispatchEvent = NPN_GetStringIdentifier("dispatchEvent");
    NPVariant dispatchArgs[1];
    dispatchArgs[0] = evt;
    NPN_Invoke(npp, self, dispatchEvent, dispatchArgs, 1, &result);
    NPN_ReleaseVariantValue(&result);
    NPN_ReleaseObject(npEvt);

    NPN_ReleaseObject(self);
}

暂时先写到这里，如果还有什么疑难杂症，欢迎评论，我继续添加。

最原始框架一定是最基本的。从广义上来说，操作系统就是一个框架，它封装了每一个程序需要完成的基本任务，管理内存、磁盘IO、中断、输入输出等。不过操作系统能封装的东西有限，最关键的是，封装总是略显简单。比如，需要写一系列服务器程序，每个程序都要访问网络、保持长连接、管理连接池等，这些机制并不是几行代码就可以实现，需要一个稍微高一点层次的框架来解决这个问题。于是很自然的，层次的概念就出来了。

当框架有了层次概念之后，大家就可以各司其职，为完善各自的框架而奋斗，直到最终框架已经极为好用，每写一个程序就像冲杯奶茶一样容易。大家都很高兴。

到现在为止，软件架构似乎还非常的简单直白，但随着时间发展，复杂的需求涌现出来了，架构也就突破原来软件框架的范畴，变成更复杂的东西。

还是拿那一系列服务器程序为例，假设它们是一个在线交易平台的后台服务。某个程序员完成了个人转账业务的代码，另一个程序员完成了商户转账业务的代码，互相一比对发现，嘿，大家怎么写的大同小异，应该优化。不过这样的优化存在着风险，因为谁都不能完全确定，未来这两个业务会怎么发展。

保守的程序员会让这两份代码独立，静观其变，反正框架已经足够好，重写一份这种业务也花不了多少时间。这并没有错，不过会错失让架构突破框架限制的机会。

喜欢挑战的程序员会仔细思考这两个业务逻辑，从业务的层面来分析其中的异同以及未来变化的趋势。

比如转账这件事，无论是个人业务还是商户业务，创建交易、记账这些事情总少不了吧，这或许可以抽象出来，但是检查账户权限、验证密码这些事情肯定会不一样，这些东西保持尽可能的可变。如此这般，业务层面的封装逐渐成形，所谓的架构终于有了架构的意思。

在引入业务之前，前面提到的“架构”只是一个放之四海皆可用的程序员的玩具；引入业务之后，架构终于得以走向成熟，摆脱程序员的束缚，反过来影响程序员的思维。

真正让架构腾飞的是引入领域知识（domain knowledge）的概念。作为一个具有业务功能的系统，要维护业务的纯正性不容易。还是拿转账来说事，如果提供了创建交易和记账的业务抽象，再假设转账是一气呵成的，从代码上来说，先创建交易还是先记账其实没有太大区别。但这事搁在包含了领域知识的架构里面可不行，因为账务要求，必须先有单据再有流水。

领域知识把程序员变成业务专家，渐渐的程序员就更能明白什么是业务、什么算框架，也可以开始用业务接口包装子系统，理解子系统之间的逻辑，让架构日臻完善。

P.S. 上面这些文字并没有涉及具体的设计原则、方法。

P.S.S. 再完美的架构也需要持续改进，况且这世界上恐怕还不存在所谓“完美”的架构。

这个函数实在是太好用了，以至于我的测试函数每个地方都用这个函数而不用rpc_call()。我非常满意，觉得已经万事OK了。

世界上唯一不变的是变化。

后来，我发现学xUnit那样每个测试用例打个点表示成功实在是无趣，而且如果真出了什么错就完全没法调试，于是我增强了这个函数。

function assert_rpc_call($cmd, $input, $logid, $expected_err_code = 0) {
    $ret = rpc_call($cmd, $input, $logid);
这样一来，默认情况下我的assert_rpc_call每次都会把返回的信息打印出来，成功输出绿色的PASS，失败返回红色的FAIL，煞是好看。我非常满意。

    $output = “”;

    if ($ret['result'] === $expected_err_code) {
        $output .= “\033[1;32mPASS\033[m\n";
    } else {
        $output .= "\033[1;31mFAIL\033[m\n";
    }

    $output .= print_r($ret, true);
    echo $output;
    return $ret;
}

工具如果太好用了，它一般会被滥用。

可是需求还在变化。不久，我发现有时候我为了初始化一个用于自动测试的环境需要调用很多肯定不会失败的接口，每次把它们的返回打印出来实在是扰乱视听，我需要有一个开关切换回原来的assert_rpc_call()行为。于是我加了一个参数和一些丑陋的代码实现这个功能。再接着，我又想在某些情况下获得返回的数组，在另外一些情况下返回bool值，而且还要在某些情况下打印输入的参数……我知道把这些矛盾的功能全部加到一个函数里面是非常丑陋的，也许应该拆成几个函数更为合适，但因为这个函数已经在很多地方调用，我实在懒得把每个地方都改好。

最终，代码变成了这样。

function assert_rpc_call($cmd, $input, $logid, $expected_err_code = 0, $return = false, $just_need_bool_value = false) {
    $ret = rpc_call($cmd, $input, $logid, !$return);
    $check = array();
    $output = "";
最终这个函数非常的丑陋，它变成现在的模样实际上经历了三步：

    if ($ret['result'] === $expected_err_code) {
        $output .= “\033[1;32mPASS\033[m\n";
        $check['passed'] = true;
    } else {
        $output .= “\033[1;31mFAIL\033[m\n";
        $check['passed'] = false;
    }

    $output .= print_r($ret, true);
    $check['output'] = $output;

    if (!$return) {
        echo $output;
    }

    if ($just_need_bool_value) {
        return $check["passed"];
    } else {
        if (!$check["passed"]) {
            return false;
        }
    }

    return $check;
}

1. 函数太方便了，很多地方都开始引用
2. 需求变化，恰好这个代码通过简单的修改就能基本满足要求
3. 需求继续变化，代码已经发出bad smell，但因为牵扯过多，无法重构

具有讽刺意味的是，万恶之源竟然是函数一开始写的太方便了，这本来应是件好事。真正造成问题的则是第二步，需求缓慢的变化、不断积累，就像温水煮青蛙一样，最终使我失去重构的动力，一错再错，终究写出丑陋的代码。

幸好，任何时候都不算晚，就算今天开始也行。不过，我考虑一会之后还是觉得直接把它commit到cvs里面去——我要遵循KISS原则，何必对这种测试用例代码那么计较呢。

有了这种阿Q式的KISS精神之后，这世界上就很少有不能忍的丑陋了。

我自己是一个极度喜欢保持职责单一的人，面对康神设计的接口单一但内部逻辑较复杂的模块，多少有点想重构的冲动。其实这两种设计哲学都没太大问题，确实得看需求来确定到底用什么。

接口单一的设计，最典型例子的就是大家都知道的printf，这个东西博大精深，可以组合打印任意格式的文字，如果C标准委员会乐意，还可以通过扩展格式字符串来实现更多的打印选项，同时保证100%向下兼容。还有很多接口，它们通过传递一个结构来传递参数，这个结构拥有众多成员，每次调用接口时只用其中一部分。这些接口也能像printf一样易扩展，康神设计的就是后面这种接口。

这样设计的好处是保持整个系统接口的统一和稳定，这对于一个大型工业系统来说至关重要，因为牵一发动全身，改变任何一个通用接口都会付出很大代价。但它的缺点也十分明显，主要体现是效率不高和模块职责不明。

可以想象，printf的运行效率并不高，对于%以及后面参数的解析是在运行时完成的，每次运行都会在解析格式字符串上花时间。传结构的缺点是内存使用效率不高，并且随着业务逻辑不断变复杂，结构会大到不能接受的地步，最终肯定在结构中设置一个类似于格式字符串或者表达式的东西，逐渐转变成printf的设计模式。

同时，由于接口过于强大，在接口背后隐藏的逻辑也必定复杂无比。想想解析格式字符串或解析结构时该需要多少烦人的if…else，就知道要实现这种设计将会写出多少逻辑复杂的代码，会产生多少的bad smell，给后来维护的人造成不少困扰，甚至会引入不少潜在的错误。

反观职责单一的设计，没有接口单一设计的缺点，但劣势也很明显，就是没有统一的接口，使得整个系统模块之间的调用方式始终难以稳定。如果整个系统由一个人开发还好，如果多人协作，则会大大降低开发效率，会将大量时间用在沟通接口和解决联调问题上面。公平的说，职责单一的设计也可以用facade模式来提供统一接口，但是facade模式的实现代码又会变得和接口统一时一样，没有根本改变，只是一个折中和权衡。

那是否说明“完美”的职责单一的设计不适合大型开发呢？也不一定，因为我们有C++和无比变态的模板技巧。

比如我们可以设计出一个这样的print，功能类似于printf。注意，这个函数设计成只在print的时候才输出，expression类不会造成任何输出。

pattern p = builder() << "uid: " << uid << " uname: " << name;
uid = 1000;
name = "realdodo";
print(p); // 打印出"uid: 1000 uname: realdodo"

如果熟悉boost.spirit的朋友肯定觉得这个代码很眼熟，没办法，谁要我是这个库的忠实粉丝呢。在这里，pattern_builder类只是一个模板生成器，而不进行任何计算（不同于sstream这样的类），它用<<运算符针对各种类型生成各种特化的模板类，类似于一个嵌套的pair<>。这些模板类层层嵌套，但是pattern类可以轻松搞定，方法就是设计一个concrete_pattern类。

struct concrete_pattern_base
{
    concrete_pattern_base() {}
    virtual ~concrete_pattern_base() {}
    virtual string to_string() const = 0;
};

tempate <typename builder>
struct concrete_pattern : public concrete_pattern_base
{
    builder builder_;
    concrete_pattern(const builder & b)
        : builder_(b)
    {}

    virtual string to_string() const
    {
        // 用模板特化的方法实现to_string()方法，这里略去
    }
};

这样，pattern的实现就非常简单。

class pattern
{
    concrete_pattern_base * pattern_;

public:
    template <typename builder>
pattern(const builder & b)
    {
        pattern_ = new concrete_pattern(b);
    }

public:
    // 其他方法……如果需要获得当前字符串，只需调用pattern_->to_string()
};

注意，按照print的语义，pattern虽然也要实现一个类似于to_string()的方法，但它完全没有必要从concrete_pattern_base派生。

这种设计的好处是在保证职责单一的时候同时维护了接口统一。实际上，那个复杂的接口逻辑还是存在，但是由编译器在编译期间完成了。程序员只用关注builder、pattern和print的实现，它们三个一个负责生成表达式，一个负责计算表达式，一个负责输出，职责明确，泾渭分明，超级高效，实现各种新的需求也毫无问题。

可惜，这世界上没有银弹，这种滥用模板技巧的方法也有很大的问题。最大问题是可维护性。模板编程的复杂度远超过普通面向对象编程的复杂度，如果开发/维护者没有很深的基础，很可能都无法看懂这些代码。次要问题是扩展成RPC调用非常困难。对于大型工业应用，很可能一个接口因为某种原因要变成跨进程甚至于跨机器的调用，这就需要序列化所有的参数。模板是静态技巧，要序列化就一定会生成不亚于printf格式字符串的东西，而且还要实现一个客户端解析这个烦人的东西，那真是吃力不讨好，还不如直接实现一个printf好呢。

所以，最后的结论是没有结论，设计要随着需求而定，这才是王道。没有万能的设计，只有最符合需求的设计，并且设计要随着需求改变而改变，不能止境。

IE8中最显著的改变莫过于对CSS 2.1的全面支持。正因为现在亲近标准而以前疏离标准，IE8引入了兼容模式这种复杂的新功能，来兼容以前那些不标准的网页。在外界看来，IE8这么痛苦的在标准支持和兼容性方面抉择，简直就是搬起石头砸自己的脚——早知现在，何必当初呢。

我曾经问过负责CSS 2.1标准支持的IE PM，为什么现在才开始做标准支持而以前不做，为什么不做DOM而选择CSS。他对此也感觉有心无力，毕竟无论是支持什么新标准，对IE来说都是一次大手术。IE是在标准产生之前确定的架构，现在能做到如此强大的功能还能支持那么多标准已经很不容易。就比如说对CSS 2.1的支持，IE重写了很多核心代码，花了大量的时间去保证正确性、性能和兼容性，已经有点精力不够。相比而言，还是开发WebSlice和 Accelerator更加省心省力。

现在的IE已经很有点像当年的NetScape。有谁能想到，当IE 5全面打败NetScape时，IE是世界上最标准的浏览器，它全面支持HTML 4和CSS 1，而且它还十分的小巧，比NetScape小一个数量级。IE的胜利绝对不仅仅因为它与Windows绑定，而是因为它实在比NetScape好太多了。NetScape当年拖着沉重的历史包袱，每一个升级都不敢做太大的变动，生怕那些使用了自己独有特性的网站出问题，至于标准，当然是抛在脑后。这何其像现在的IE。

时过境迁，多年之后，Firefox从当年NetScape的残骸之中诞生，Firefox成了当年的IE，IE成了当年的NetScape。当 Firefox一身轻松快速开发新版本的时候，IE还要考虑兼容IE6这样古董的浏览器。当Firefox毫无忌惮的通过自动更新强制用户更新浏览器版本的时候，IE还要修IE6的bug、还要发布IT工具方便众多公司阻止IE升级版本。唉，开发IE真累啊。

有很多人希望有朝一日Firefox能打败IE，解放现在身处“水深火热”之中的Web前端开发者。可是我觉得，这绝对不是未来的趋势，Firefox或者说Mozilla基金会绝不愿意这么做。浏览器世界的盟主不是那么好当的，站在风口浪尖，不但赚不到钱，还要花力气赔名声，得不偿失。

就拿修浏览器漏洞这件事情来说，Vista下的IE7已经做得非常安全，比Firefox好上无数倍，基本上对缓冲区溢出和DEP免疫了，可是大家还是会觉得Firefox更安全，根本原因是舆论导向。IE造好了一座坚固的城池，如果依然能将它攻破，对于攻击者来说，自然很有成就感。同时，新闻也总关注 IE的安全，毕竟它一出问题，全世界大部分电脑都处于危险之中，这绝对是大新闻。一来二去，IE不安全的口碑也就建立。至于Firefox究竟有多安全，那还真不见得。用XPCOM做的Firefox插件真的比ActiveX安全？还真不见得。从技术上来讲，做Firefox版的流氓插件不存在任何技术问题。

从我和IE PM聊天中得到的信息，IE现在最关注的领域是企业级应用和RIA。这两方面，恰好是Firefox最弱的地方。而在这个领域，IE真正的对手是 Google Chrome，所以下一个版本的IE会针对Google Chrome的特性采取很多动作。也许还要再经历3个版本，IE才能够脱胎换骨，不过那时，其他竞争者早不知道发展到什么程度了。对IE来说，是时候考虑学习一下Firefox，来个凤凰涅磐了。我猜，五年之后必有大变，我会拭目以待。

这个Nabialek trick其实并不是编译期间的技巧，而是利用查表的方式将一些静态的类型推导变成简单的运行时调用，用性能损失换取编译期间的复杂，是一种相反的过程。可以说，Nabialek trick给人的感觉是完完全全的没有意义，要知道C++的template就是为了提升运行时性能而增加编译期间运算，这个反其道而行意义何在？其实说白了，意义就在于：消除模板技巧带来的疯狂的自动类型推导，以及解除对某些类型的静态绑定。前者意义在于可以提升编译速度，而且也可以避免达到模板嵌套上限（比如MSVC 7.1，最多只能嵌套256层，这已经算不错了），后者意义在于可以让复杂的表达式变得更容易匹配、更快的执行和更加灵活（所谓的将“线性非决定式”转化为“决定式”，将“或”逻辑从表达式中剔除，避免不必要回溯以加快速度），但是由于创建查找表的过程涉及到内存分配，所以后者并不能总是达到很好效果。

我们再从正面来想想Expression Templates给编程带来的困难，请看下面的示例代码（来自boost.spirit的帮助/libs/spirit/doc/techniques.html，我做了一些简化和修改）：


r =
"//" >> *(anychar_p - 'n') >> 'n'
| "/*" >> *(anychar_p - "*/") >> "*/"
;


在这里，r的类型就是：


alternative<sequence<sequence<strlit<const char*>, kleene_star<difference<anychar_parser, chlit<char> > > >, chlit<char> >, sequence<sequence<
strlit<const char*>, kleene_star<difference<anychar_parser, strlit<const char*> > > >, strlit<const char*> > >


是的，我没指望任何人能够看懂……不过假如做一下的赋值：

line1 = "//" >> *(anychar_p - 'n') >> 'n';
line2 = "/*" >> *(anychar_p - "*/") >> "*/";
r = line1 | line2;


这样的代码应该好理解一些，但是没有本质不同。再来改改：


line1 = "//" >> *(anychar_p - 'n') >> 'n';
line2 = "/*" >> *(anychar_p - "*/") >> "*/";
some_helper helper; // some_helper并不是boost.spirit的类，是我虚构出来的。
helper.add("//", &line1);
helper.add("/*", &line2);
r = helper;


这里可以清晰地看到，只要这个some_helper的add()能够支持line1和line2类型，并且line1和line2的类型都实现了一个公共的抽象接口，那么r的类型就很单纯了。不过boost.spirit出于各种考虑，整个类体系非常复杂，包括rule<>、parser<>、abstract_parser<>、sequence<>等，它们的关系我花了好几天终于弄明白了，不过要说清楚恐怕还要花费写口舌，我等以后有时间以后再来详细介绍吧。

有了这个helper（在boost.spirit里面实际上是symbols<>），我们就可以抛弃“或”逻辑，表达式匹配也就没有回溯的问题，提高匹配的速度。同时可以看出，这种“优化”在很大程度上似乎并不是特别必要，毕竟Expression Templates是可以在编译期间决定这种优化方式的（甚至于可以通过模板的偏特化优化运算顺序），所以我真的觉得这种技巧在这种应用环境里面恐怕不会存在太久……

可以很肯定地说，Expression Templates一定是未来C++各种类库设计的标准思路，现在boost.spirit、boost.lambda、boost.uBLAS、boost.xpressive等库都是用这种思路设计，而且介绍这种方法的论文也明确指出，合理应用这种方法可以显著的提高程序性能，能让C++程序库的效率高于相同功能的C程序库（例如std::sort和qsort的比较）。但是它的一个致命缺点是：令人发狂的类型推导。

看看下面这个例子吧，它是boost.spirit的一个例子（boost 1.34.0的libs/spirit/example/techniques/no_rules/no_rule2.cpp），用于说明如果没有自动类型推导或者类似功能的机制，类型定义会变得多么的疯狂：

请注意中间的那个skip_t的类型定义，我相信一定没有人相信是人手写出来的……本来应该编译器做的事情换做人来做，太疯狂了！特别是还要自己弄明白所有的operator的返回类型，更加的困难……

boost.spirit的作者Joel de Guzman给出了一个比较猥琐的解决方案：将skip_t先定义成随便一个什么类型，比如int，然后编译，这样便一起就会提示说：“Cannot convert boost::spirit::alternative<… …………> to int”，把这个错误拷贝出来，就可以看到实际的类型了——天哪，足够疯狂了！这还没完，如果遇到更复杂的情况怎么办，看看boost 1.34.0的libs/spirit/example/techniques/no_rules/no_rule3.cpp吧，头开始疼了……

所以，Joel de Guzman在给我留下深刻印象之后开始说明他的方案。
方案一：期待C++ 0X早日成为事实的标准，让那个非常有用的auto关键字成为到处可用的东西。
方案二：使用部分编译器已经实现的typeof关键字，然后写一个宏：

这样，就可以简单的使用宏来简化各种类型定义，不过可怜的MSVC并没有实现这种功能。
方案三：使用“Nabialek trick”。看到“Nabialek trick”这个陌生的名词，我的第一个反应就是“去google/baidu”，不过很可惜，google上的所有搜索结果都直接或间接的来自我正在看的boost.spirit文档，而baidu更是告诉我找不到。OK，我们还是回到这个名词本身吧。这个trick是因为其发明者，Sam Nabialek，而得名，其作用是将“线性非决定式”（linear non-deterministic）转换成“决定式”（deterministic）。如果要说的更具体一些就不行了，其实我还不太明白，我正在阅读boost.spirit的部分源码，希望能够有些收获。无论如何，boost.spirit最终用极为优雅的方式将类型推导的难题再次交给了编译器，整个代码非常的简洁明了，可谓是最佳的实现方式。

就我个人来说，应该还可以提出方案四：使用boost.typeof库的基础设施，不过为了能使用这个东西，依然必须手动的“注册”各种类型，并依赖于大量的模板和宏技巧，比较烦，所以并不算一个很好的方式，但至少还可以接受。

综合来说，正是因为Expression Templates的广泛使用，类型推导成了一个疯狂的怪兽，而C++ 0X中的auto关键字成了绝对的救星，我们还是来呼唤新标准早日降临吧！

在此，我就从boost.spirit库中间的一个例子出发，经过简单的修改就变成一个极为健壮的四则计算器。我所参考的例子是boost 1.34.0的libs/spirit/example/fundamental/calc_plain.cpp，我因为是在这上面直接修改而来，所以源码中带有原作者的版权声明。

关于boost.spirit的用法，在这里我先不说，以后有时间我来慢慢的把它用中国话讲解一遍。这个程序的核心实际上是一个EBNF的表达式，也就是如何用EBNF语法来表示四则运算。
在这里，我就直接给出答案（EBNF的知识请暂时自行看编译原理的教材）：

请注意，calculator从grammer派生，但是除了在内部定义了一个嵌套class以外，并没有做更多的事情。

至于这里面用到的do_calc<>、push_real等functor和函数，则是一些极为简单的东西，实现如下：

可以从源码中清晰看到，这些函数就是简单的做了些出栈/入栈以及运算的工作，每一个函数功能极为单纯，可认为就是一些状态及处理函数而已，而状态机逻辑则由grammer搞定了。

我用VS2005编译，错误信息如下：

我数了一下，这个错误信息总共有11355个字符，并且完全没有告诉我究竟应该如何排除这个错误……不过幸好在错误信息的最后几行中指出了真正出错的地方（真的是这样，前面的输出完全是没有用的烟雾弹……），然后利用这一点点信息，结合boost.spirit的文档，我终于知道错误的原因：我把一个函数的输入参数类型和个数写错了。

OK，看来调试这种基于Expression Templates的库真的需要耐心和勇气。