在网上搜索"万能"二字的英文翻译，结果却无意中看到有人提到了如何设计"万能栈"。栈(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语言博大精深，有很多诡秘的技巧是我所不知的，也许很多人还有更好的方法。

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

大凡写程序者，都会遇到错误；
大凡写程序者也都知道两种错误处理的机制：传统的'错误码返回机制'和'面向对象语言引入的异常处理机制'。

人们常常会在这两种机制之间徘徊不定，难以抉择。但有两类人大可不必为此头痛，他们是坚决只使用'错误码返回机制'的人，和坚决只使用'异常处理机制'的人。而苦就苦了摇摆在中间，思索不定的那些人了。这群人有一个特点就是不停的问："什么是异常？什么时候该使用错误码返回？什么时候又要用标准的异常处理机制呢？内存不足是不是异常？网络瘫痪是不是异常？用户输入id的超出了允许的长度该如何处理？"等
等诸如此类的问题。

我一直使用C，C没有像C++、Java、Ruby那样提供标准的异常处理机制，C只是提供了setjmp和longjmp这样的粗糙的甚至让很多新人觉得迷惑的调用接口，所以到目前为止，我还没有真正用过"异常处理"来写过代码。直到我看到"David Hanson "的"c interfaces and implementations(C语言接口与实现)"中第4章封装的C的异常处理宏。看完后我有些迷惑。迷惑的不是这组宏有什么精湛技艺，而是他破坏了以前我对错误处理的单一使用错误码返回的想法，他又给了我一个选择：使用异常处理。而多了一种选择之后，我也陷入徘徊不定中。只能反复的一遍又一遍的看和回味Hanson在这章起始的那段关于错误分类的描述和理解，以寻求在返回错误码和使用异常处理之间的平衡。

Hanson将错误分为三类：
用户错误，就是由用户的不正确输入引起的，对于此类错误的态度是：函数必须处理错误并返回错误代码。
//testusererr.c
int main(int argc, char *argv[]) {
if (argc <= 1) {
printf("you should input at leaset an argument!\n");
return 1;
}

int i = atoi(argv[1]);

if (i < 5) {
printf("i should be more than 5.\n");
return 2;
}

return 0;
}

上述的例子仅是一个程序接收用户的输入，并对其输入错误进行处理。

那么对于一个功能接口而言，对其参数是否都要做类似处理呢？通常来说在我们系统中除了针对用户的接口需要进行外，其他的接口都是内部调用的，比如库，库提供了接口同时也隐含了某种约定。我们作为程序员在使用库的时候都会遵守约定。但是这是不是这些库接口就不用对其接口参数进行任何处理了呢。一般我们会在接口的入口处加上断言。这就是我们要说的第二种错误–可检查的运行时错误。

按照Hanson的说法，可检查的运行时错误不是用户错误，上面已经说了，程序员已经按照约定传入了适当的参数，那么一旦出现错误，这个错误是从何而来的呢？可检查的运行时错误恰恰是揭示了程序的漏洞，他们不可预料，通常遇到此类错误，应用程序一般将无法恢复。看下面的例子：

//testcheckedrterr.c
#include
#include

#define MY_MAGIC 0×19210723

struct Foo {
int i;
char id[22];
#ifdef _DEBUG
unsigned int magic;
#endif

};

void check_foo(const struct Foo *foo) {
assert(foo != NULL);
#ifdef _DEBUG
assert(foo->magic == MY_MAGIC);
#endif
;
}

int main() {
struct Foo foo;
foo.i = 13;
#ifdef _DEBUG
foo.magic = MY_MAGIC;
#endif
strcpy(foo.id, "this will cause an overflow");

check_foo(&foo);
}

gcc -D_DEBUG -g *.c
执行的结果：
Assertion failed: foo->magic == MY_MAGIC, file testcheckedrterr.c, line 20
退出 (（主存储器）信息转储)

这里程序的确是按照check_foo的需要的参数提供了参数，只是没有预料到，程序存在栈溢出，对于这种运行时错误，在check_foo中我们使用了断言。断言一般都是无法恢复的，直接的结果就是程序退出。

异常，第三类错误，极少出现，可能不可预测，但有可能从中恢复的错误。如：内存不足、网络瘫痪、磁盘空间满等。按照Hanson的经验，由于异常发生很少，很多可能发生此类异常的函数都是没有返回值的。这时是采用异常处理机制的好时机。

说到这，也许还只是停留在说教上，也许开头提到的那些疑问仍然无法回答。我想什么样的回答都不能令所有人满意，自己在项目中摸索理解吧。其实永远没有绝对的事情，你大可在程序中丝毫不考虑使用异常机制。