最近收到客户的一个需求，要求我们将产品的系统配置数据和业务配置数据定期导出备份，以防万一数据库宕掉后可以用来"救火"。产品从起初0.1版本就一直延续着一种"section-key-value"的配置文件方式，同时我们也有可复用的库来完成配置数据的读取，可是在长期的使用过程中我们发现的不少问题，特别是在存储多样化的业务数据的时候，这样的配置方式带来维护上的很大不便。

"section-key-value"这样的配置文件方式或者类似于环境变量似的配置文件方式用来做系统自己的配置可以说既简单又实用，像著名的Apache服务器、版本控制系统svn等都是采用这种方式。在我们产品的初期，那时的业务相对简单，采用这样的一种配置方式还算是合适的。但随着业务复杂度的上升，种类繁多的业务数据的出现，这种配置方式的弊端渐渐显现。

最大的弊端就是"同步"问题。每当我们的产品升级时，我们一般都会先升级数据库的配置，然后再同步文档，最后同步配置文件以及相关读取代码。如果工作量较大，升级工期较紧的时候，常常忽略了将新增或修改的配置同步到配置文件；这样累积到一定时间之后，除了花费大力气去"补"，别无它法。另外一个弊端就是上面提到的那个问题：从数据库导出配置文件始终是那么"别扭"，曾经尝试过使用脚本导出、Java程序导出，但是始终不能让人很满意，挖掘一下深层原因：配置文件和数据库表设计"不搭调"。业务数据千变万化，导致从数据库导出配置文件的逻辑甚是复杂，维护起来十分不便；而且像"section-key-value"这样的结构，数据库中由于没有section的字串，导致这些section必须"写死"在代码中。

不错，我们在寻找替代品，目标锁定在xml。曾经在2005年做的一个项目中尝试过使用xml作为配置数据，取得了很好的效果。记得当时参考Ant的build.xml的配置方式，顺利解决了一个"自动化处理"的配置设计，那应该是部门第一次采用xml做为后台C实现的系统的配置文件。也是自那以后，我感受到了xml的强大描述能力。xml在Java世界可以说占据了大部江山，从DB导出数据到xml可以说轻而易举，这又恰好解决了本篇所提到的"同步"难题。

坐在公司的Bus上，大致想出了如下xml作为配置文件的好处：
1) 与DB表几乎无缝转换，方便导入导出；
2) 作为元语言，其描述能力毋庸置疑；
3) 在Java世界几乎是配置文件的首选或者说是标准也不过分，选择标准的，总会被支持的很好；
4) 诸多开源工具支持对XML的读写甚至支持加密；
5) 文本形式，方便浏览和信息查找(grep or find均可派得上用场)，这也符合Unix编程艺术(TAOUP)作者在书中阐述的一个原则-尽量文本化。
6) DTD或schema验证，自动验证格式是否OK。
… …

当然缺点也是有的：
1) 如果不加密，是明文，保存账户、密码等数据时要小心，当然这也是文本配置的通病；
2) 如果设计不当，会导致"xml地狱"，xml太多也太烦，很多Java世界的产品就有此弊病。

大致在心里估算了一下，读取xml承载的配置与读取传统的配置的代码量没有太大出入，但是如果xml设计的足够精致，后期的维护工作将大为减少。xml配置改造工作看来势在必行了。

在网上搜索"万能"二字的英文翻译，结果却无意中看到有人提到了如何设计"万能栈"。栈(stack)是比较基础(fundamental)的数据结构，实现起来一般都比较容易。但一般的栈(stack)的实现都是局限于某种特定类型的，比如一个存储32-bit整型的栈。如果对于同一份栈实现，要求可以存储多种数据类型的话，那就需要仔细想想了。而这样的栈实现也就被戏称"万能"栈。

这里对"万能"栈再做一个分类：同构数据"万能"栈和异构数据"万能"栈。简单解释一下：同构数据"万能"栈指得是这个栈可以存储多种类型数据，但是每次使用该栈时只使用其中一种类型数据；异构数据"万能"栈则说的是这个栈可以存储多种类型数据，而且使用时也是多种数据混合处理。

对于同构的"万能"栈，像C++、Java这样有模板支持的语言来说，是很好实现的。C++的标准库中就携带了一个通用的stack类，使用起来也很是方便：
stack<int> s;
for( int i=0; i < 10; i++ )
    s.push(i);  

但是对于使用C语言的人来说，栈是需要自己实现的。那么如何实现一个同构数据"万能"栈呢？我的想法是借用union的语法功能：
union general_unit {
        void  *vp;
        void (*fp)(void);
        char  *cp;
        long   l;
        double d;
    long long ll;
};

struct stack_item_t {
        union general_unit item;
};
这样我在准备我的item的时候，就可以按需选取union中提供的相应类型的member。比如：
struct stack_item_t item;
item.item.l = 5;
push(&item);

这里其实也是有些别扭的，别扭在于谁来管理数据存储的问题。对于char, int, long, float, doule这样的语言本身提供的基本数据类型，大可存储在stack中。但是对于其他非基本数据类型的数据，我们只能将其指针放到栈中了，这时你就要保证push到栈中的地址在栈的活动期是有效的，像下面这样的肯定会出错：
typedef struct Foo {
    //…
} Foo;

void foo(void) {
    Foo foo;
    //init…
    struct stack_item_t item;
    item.item.vp = (void*)&foo;
    push(&item);
}

int main(void) {
    struct stack_item_t item;
    item = pop();
    Foo *pfoo = (Foo*)item.vp;
    pfoo->xxx; //error;    
}

如果上面的例子中存储的是函数指针的话，那么问题就不大了，因为函数地址在程序构建之后其地址就是全局可访问且始终不变的。

有了上面的基础，异构的"万能"栈实现也就容易了。异构栈要求：pop时候我也要知道pop出来的item的类型，那么只用union显然不能完成这个任务了，我们需要有一个字段来标识一下存储的类型是什么或者说标识使用了general_unit中的哪个成员，便于上层使用，方法如下：
union general_unit {
        void  *vp;
        void (*fp)(void);
        char  *cp;
        long   l;
        double d;
    long long ll;
};

struct general_item {
    union general_unit unit;
    int ut_type; //用于标识栈中数据的类型
};

struct stack_item_t {
        struct general_item item;
};

这样在pop时我们需要如是做：
item = pop();
switch(item.item.ut_type) {
    case xx:
        //…
    case yy:
        //…
    //…
}
看起来还是比较麻烦的。

以上只是"万能"栈的一种想法而已，C语言博大精深，有很多诡秘的技巧是我所不知的，也许很多人还有更好的方法。

为什么要给万能二字加上引号呢？其实就是说明这个"万能"只是一个相对的概念，这个相对的"万能"带来的是数据存储管理的不一致以及接口的不易用。在平时使用时尽量避免使用这种所谓的"万能"栈，一般来说我们都会使用比较单一类型的栈实现，这样的栈简单、高效、易用且不易出错。