38
回答
为什么我希望用C而不是C++来实现ZeroMQ
滴滴云服务器,限时包月0.9元,为开发者而生>>>   

开始前我要先做个澄清:这篇文章同Linus Torvalds这种死忠C程序员吐槽C++的观点是不同的。在我的整个职业生涯里我都在使用C++,而且现在C++依然是我做大多数项目时的首选编程语言。自然的,当我从2007年开始做ZeroMQ时,我选择用C++来实现。主要的原因有以下几点:

1. 包含数据结构和算法的库(STL)已经成为这个语言的一部分了。如果用C,我将要么依赖第三方库要么不得不自己手动写一些自1970年来就早已存在的基础算法。

2. C++语言本身在编码风格的一致性上起到了一些强制作用。比如,有了隐式的this指针参数,这就不允许通过各种不同的方式将指向对象的指针做转换,而那种做法在C项目中常常见到(通过各种类型转换)。同样的还有可以显式的将成员变量定义为私有的,以及许多其他的语言特性。

3. 这个观点基本上是前一个的子集,但值得我在这里显式的指出:用C语言实现虚函数机制比较复杂,而且对于每个类来说会有些许的不同,这使得对代码的理解和维护都会成为痛苦之源。

4. 最后一点是:人人都喜欢析构函数,它能在变量离开其作用域时自动得到调用。

如今,5年过去了,我想公开承认:用C++作为ZeroMQ的开发语言是一个糟糕的选择,后面我将一一解释为什么我会这么认为。

首先,很重要的一点是ZeroMQ是需要长期连续不停运行的一个网络库。它应该永远不会出错,而且永远不能出现未定义的行为。因此,错误处理对于ZeroMQ来说至关重要,错误处理必须是非常明确的而且对错误应该是零容忍的。

C++的异常处理机制却无法满足这个要求。C++的异常机制对于确保程序不会失败是非常有效的——只要将主函数包装在try/catch块中,然后你就可以在一个单独的位置处理所有的错误。然而,当你的目标是确保没有未定义行为发生时,噩梦就产生了。C++中引发异常和处理异常是松耦合的,这使得在C++中避免错误是十分容易的,但却使得保证程序永远不会出现未定义行为变得基本不可能。

在C语言中,引发错误和处理错误的部分是紧耦合的,它们在源代码中处于同一个位置。这使得我们在错误发生时能很容易理解到底发生了什么:

int rc = fx ();
if (rc != 0)
    handle_error();

在C++中,你只是抛出一个异常,到底发生了什么并不能马上得知。

int rc = fx();
if (rc != 0)
    throw std::exception();

这里的问题就在于你对于谁处理这个异常,以及在哪里处理这个异常是不得而知的。如果你把异常处理代码也放在同一个函数中,这么做或多或少还有些明智,尽管这么做会牺牲一点可读性。

try {
    …
    int rc = fx();
    if (rc != 0)
    throw std::exception(“Error!”);
    …
catch (std::exception &e) {
    handle_exception();
}

但是,考虑一下,如果同一个函数中抛出了两个异常时会发生什么?

class exception1 {};
class exception2 {};
try {
    …
    if (condition1)
        throw my_exception1();
    …
    if (condition2)
        throw my_exception2();
    …
}
catch (my_exception1 &e) {
    handle_exception1();
}
catch (my_exception2 &e) {
    handle_exception2();
}

对比一下相同的C代码:

…
if (condition1)
    handle_exception1();
…
if (condition2)
    handle_exception2();
…

C代码的可读性明显高的多,而且还有一个附加的优势——编译器会为此产生更高效的代码。这还没完呢。再考虑一下这种情况:异常并不是由所抛出异常的函数来处理。在这种情况下,异常处理可能发生在任何地方,这取决于这个函数是在哪调用的。虽然乍一看我们可以在不同的上下文中处理不同的异常,这似乎很有用,但很快就会变成一场噩梦。

当你在解决bug的时候,你会发现几乎同样的错误处理代码在许多地方都出现过。在代码中增加一个新的函数调用可能会引入新的麻烦,不同类型的异常都会涌到调用函数这里,而调用函数本身并没有适当进行的处理,这意味着什么?新的bug。

如果你依然坚持要杜绝“未定义的行为”,你不得不引入新的异常类型来区分不同的错误模式。然而,增加一个新的异常类型意味着它会涌现在各个不同的地方,那么就需要在所有这些地方都增加一些处理代码,否则你又会出现“未定义的行为”。到这里你可能会尖叫:这特么算什么异常规范哪!

好吧,问题就在于异常规范只是以一种更加系统化的方式,以按照指数规模增长的异常处理代码来处理问题的工具,它并没有解决问题本身。甚至可以说现在情况更加糟糕了,因为你不得不去写新的异常类型,新的异常处理代码,以及新的异常规范。

通过上面我描述的问题,我决定使用去掉异常处理机制的C++。这正是ZeroMQ以及Crossroads I/O今天的样子。但是,很不幸,问题到这并没有结束…

考虑一下当一个对象初始化失败的情况。构造函数没有返回值,因此出错时只能通过抛出异常来通知出现了错误。可是我已经决定不使用异常了,那么我不得不这样做:

class foo
{
public:
    foo();
    int init();
    …
};

当你创建这个类的实例时,构造函数被调用(不允许失败),然后你显式的去调用init来初始化(init可能会失败)对象。相比于C语言中的做法,这就显得过于复杂了。

struct foo
{
    …
};
int foo_init(struct foo *self);

但是以上的例子中,C++版本真正邪恶的地方在于:如果有程序员往构造函数中加入了一些真正的代码,而不是将构造函数留空时会发生什么?如果有人真的这么做了,那么就会出现一个新的特殊的对象状态——“半初始化状态”。这种状态是指对象已经完成了构造(构造函数调用完成,且没有失败),但init函数还没有被调用。我们的对象需要修改(特别是析构函数),这里应该以一种方式妥善的处理这种新的状态,这就意味着又要为每一个方法增加新的条件。

看到这里你可能会说:这就是你人为的限制使用异常处理所带来的后果啊!如果在构造函数中抛出异常,C++运行时库会负责清理适当的对象,那这里根本就没有什么“半初始化状态”了!很好,你说的很对,但这根本无关紧要。如果你使用异常,你就不得不处理所有那些与异常相关的复杂情况(我前面已经描述过了)。而这对于一个面对错误时需要非常健壮的基础组件来说并不是一个合理的选择。

此外,就算初始化不是问题,那析构的时候绝对会有问题。你不能在析构函数中抛出异常,这可不是什么人为的限制,而是如果析构函数在堆栈辗转开解(stack unwinding)的过程中刚好抛出一个异常的话,那整个进程都会因此而崩溃。因此,如果析构过程可能失败的话,你需要两个单独的函数来搞定它:

class foo
{
public:
    …
    int term();
    ~foo();
};

现在,我们又回到了前面初始化的问题上来了:这里出现了一个新的“半终止状态”需要我们去处理,又需要为成员函数增加新的条件了…

class foo
{
public:
    foo () : state (semi_initialised)
    {
         ...
    }

    int init ()
    {
        if (state != semi_initialised)
            handle_state_error ();
        ...
        state = intitialised;
    }

    int term ()
    {
         if (state != initialised)
             handle_state_error ();
         ...
         state = semi_terminated;
    }

    ~foo ()
    {
         if (state != semi_terminated)
             handle_state_error ();
         ...
    }

    int bar ()
    {
         if (state != initialised)
             handle_state_error ();
         ...
    }
};

将上面的例子与同样的C语言实现做下对比。C语言版本中只有两个状态。未初始化状态:整个结构体可以包含随机的数据;以及初始化状态:此时对象完全正常,可以投入使用。因此,根本没必要在对象中加入一个状态机。

struct foo
{
    ...
};

int foo_init ()
{
    ...
}

int foo_term ()
{
    ...
}

int foo_bar ()
{
    ...
}

现在,考虑一下当你把继承机制再加到这趟浑水中时会发生什么。C++允许把对基类的初始化作为派生类构造函数的一部分。抛出异常时将析构掉对象已经成功初始化的那部分。

class foo: public bar
{
public:
	foo ():bar () {}
	…
};

但是,一旦你引入单独的init函数,那么对象的状态数量就会增加。除了“未初始化”、“半初始化”、“初始化”、“半终止”状态外,你还会遇到这些状态的各种组合!!打个比方,你可以想象一下一个完全初始化的基类和一个半初始化状态的派生类。

这种对象根本不可能保证有确定的行为,因为有太多状态的组合了。鉴于导致这类失败的原因往往非常罕见,于是大部分相关的代码很可能未经过测试就进入了产品。

总结以上,我相信这种“定义完全的行为”(fully-defined behaviour)打破了面向对象编程的模型。这不是专门针对C++的,而是适用于任何一种带有构造函数和析构函数机制的面向对象编程语言。

因此,似乎面向对象编程语言更适合于当快速开发的需求比杜绝一切未定义行为要更为重要的场景中。这里并没有银弹,系统级编程将不得不依赖于C语言。

最后顺带提一下,我已经开始将Crossroads I/O(ZeroMQ的fork,我目前正在做的)由C++改写为C版本。代码看起来棒极了!

译注:这篇新出炉的文章引发了大量的回复,有觉得作者说的很对的,也有人认为这根本不是C++的问题,而是作者错误的使用了异常,以及设计上的失误,也有读者提到了Go语言可能是种更好的选择。好在作者也都能积极的响应回复,于是产生了不少精彩的技术讨论。建议中国的程序员们也可以看看国外的开发者们对于这种“吐槽”类文章的态度以及他们讨论问题的方式。

英文原文:martin_sustrik 编译:伯乐在线— 陈舸

举报
鉴客
发帖于6年前 38回/16K+阅
共有38个评论 最后回答: 3年前
C也抛异常,不是有人骂java抛异常这东西吗。
--- 共有 1 条评论 ---
Polle我就是,Java那异常处理的方式简直能让人气死,主流语言三大恶疾:C++的模板、Java的异常、C的指针错误 5年前 回复
异常处理被滥用在java中也是一个严重的问题
--- 共有 3 条评论 ---
幻の上帝更严重的问题是James Gosling这偏执狂异想天开引入CheckedException,还有一堆抖M乐在其中。 4年前 回复
kut使用好异常真的是一种艺术啊。 6年前 回复
xoHomeJDK中也存在很多异常处理,开元框架中同样存在N多异常处理,不知道你说的滥用具体是怎么用,但这不是个人问题,同样也不是JAVA应该重点考虑的问题。 6年前 回复

引用来自“崔钢”的答案

异常处理被滥用在java中也是一个严重的问题

那是因为java开发人员太多太多 导致平均水平被拉低太多太多

--- 共有 1 条评论 ---
幻の上帝因果好像倒了。 4年前 回复
自已不会好好用,还说人家这个不好,那个不好.
--- 共有 11 条评论 ---
幻の上帝回复 @cxshun : 国内牛人是有,但是少得可怜。云风要牛也反正不是牛在C++。 4年前 回复
newzai回复 @cxshun : 《C++现代泛型编程思想》《 Imperfect C++》《C++模板》三本书,如果仁兄没有拜读过,建议去看看,或许能否然你对C++模板有更深入的了解。当然这几本书是基于C++11之前的,某些功能在C++11已经实现或许较容易实现。这三本书,个人愚钝,基本上是拜读了五六遍以上,仍然有很多地方不明白。。 4年前 回复
cxshun回复 @newzai : 呵呵,我没看过那个,不好发言。但正因为用过才有发言权,不是吗?用过了才知道原来用那个东西是非常不好的,搞得代码很混乱,有些时候是为了用而用,这才是问题所在。 4年前 回复
newzai回复 @cxshun : 你可知道云风游戏引擎里面的很多高级东西,是使用模板实现的?? 4年前 回复
cxshun其实不是语言的问题,主要还是被滥用了,很多人非要一个简单程序里面用上模板啥的一大堆,显得自己很高级,就跟JAVA web的一样,简单的增删改查,非要上SSH,这说到底只是水平的问题。 但楼主说的不大赞同,C++是一个有太多特性的语言,但问题是太多的东西是没什么用,但又不像语法糖可以大量节省编码生命的,而且它又好像故意引导别人去用那些所谓高级功能,所以才会有太多人喷。 4年前 回复

C++提供东西的越多, 像异常这玩意, 个人觉得要么不要用, 要么就得提供两套, 一套返回error_code, 一套throw error_code, 正如boost里的一些库那样设计, 如:

int read(stream &s, error_code &err);
int read(stream &s); // throw error_code.

个人认为, 一个通用的C++库, API就应该被设计成这样.

 

--- 共有 1 条评论 ---
Lunar_Linvery agree. 6年前 回复

ZMQ本身定位于网络通信基础架构,替代底层的socket接口,据说想变成linux的标配。

如果我理解的这个定位不错的话,确实是该用C来实现。

用什么语言除了性能外,其他原因全依赖周围团队成员的开发习惯, C++,C,JAVA,各有优缺点,如果ZMQ不加入linux标配的话,用C++实现有什么错。上面的几个例子根本不能说明问题。

没有看完,不过我觉得如果认为C++异常不好用,你也可以不用,C++没有强迫你一定要使用异常。

 

--- 共有 1 条评论 ---
little_kid对头,C++完全可以写出C风格的C++,我个人习惯,从不用C++异常 3年前 回复
ZeroMQ几乎是用C来做的(应该没有用到任何标准C之外的库,比如STL),但是表现出来的是CXX,在socket类型的抽象上使用了些C++的类别抽象优势。我个人赞成这种做法的,结合C和部分C++的优势,不过度使用面向对象的CXX,不能弄明白直接了然的C++特性一律谨慎使用
--- 共有 1 条评论 ---
幻の上帝这样半吊子毛用,远不如纯C干净。 4年前 回复
顶部