ACE的陷阱

 

ACE的陷阱

坦白说，使用这个标题无非是希望能够吸引你的眼球,这篇文章的目的仅仅是为了揭示一些ACE缺陷的。文章适合的读者是对ACE（ADAPTIVE Communication Environment）有一定研究，或者正在使用ACE从事项目开发的人士参考。如果你对C++还是新手，甚至包括ACE知识初学者，（但你想飞的更高），建议你收藏这篇文档以后阅读。

秉承陷阱系列文章的传统，我只是通过一些辩证的角度去看ACE的一些不足，对于ACE的强大和优美我就不再作赞美。从2000年，到现在，ACE在中国已经从星星之火，开始有燎原之势。这一方面说明ACE的优美和实力已经逐步得到大家的认可（我所知道的Adobe reader的使用ACE，估计是为了跨平台，国内的大量电信的网管，计费，智能网软件也使用ACE），一方面要感谢的是的马维达这位国内少有的职业作家，国内的ACE的中文资料（包括大量免费资料）都出自这位老兄。

但ACE无疑是复杂的，能够畅快的遨游在其中的绝对不是泛泛之辈。没有对网络，设计模式，操作系统有一定的底蕴，想痛快的驾驭ACE无疑是较难的。另外，由于ACE仍然处在逐步发展的过程中。他的很多问题仍然有待进一步完善。重要的是一些文案的不足，受众面狭小，导致许多ACE的使用者在使用ACE的时候会碰上很多问题。这篇文案就是用于彻底揭示部分这些问题。希望大家能在更加顺捷的使用它。

另外，请注意我使用的陷阱这个术语，而不是原罪。（C Trap and Pitfalls 倒有很多应该是Original sin）ACE还在不停的发展中。很多问题可能会在以后的版本中间改进。所以在我认为的的确是问题的章节后面，我会附上知道错误的版本号。

 

1               我将什么列为陷阱

1.1               低效的模块

作为一个代码级的中间件。ACE无疑是高效的，但是坦白说ACE的代码不是非常完美的。ACE的很多地方提供的是一个框架解决方案，为了保证框架的可移植和通用，代码中大量使用了virtual 函数，Bridge模式，多线程下的锁操作，甚至有相当的new操作……，这些东西都限制ACE的性能。所以个人谨慎的将ACE的效率定义为中上。

个人认为，一般情况下，如果你使用ACE的API代替系统API，速度应该降低0.01%以下，主要导致这些差役在于ACE的再次封装，而函数栈的调用成本应该可以几乎不计。ACE的优势在高性能的系统架构，而不是绝对的函数性能，如果你要再考虑在加入系统框架的其它功能呢，（举一个例子，当你想把定时器优美的合入你的代码时），ACE就有足够的优势让你选择他。【注】

 

在此啰嗦一句，同样也有很多人质疑STL的性能。所有好的类库一样，他带来优势的同时也会有一定的遗憾，比如少量性能降低。但是如果说他们的性能不好，那是无稽之谈。（不信，把你认为性能差的代码给我写写看。）建议固步自封的程序员不要再干买椟还珠的事情，先去读读那些优美的代码。

但是和所有的框架一样，ACE也有不少的地方的地方是性能的暗礁，你最好绕开。当然一般而言ACE会提供多条道路，重要的是你能选择正确。

1.2               设计缺陷

ACE的有多个层次，侧记缺陷这类错误往往出现在ACE的高阶封装中。同时由于ACE是一个跨平台的中间件。所以为了平台的兼容性，ACE做了很多折中和弥补，有些是很漂亮的，但有些却不是非常理想。

1.3               使用不便的地方

所有的代码都是不完美的，特别是ACE这种要让无数人在无数环境下使用的软件。很多使用不便的问题都是来自我个人的一些习惯，这些算是苛责了。

1.4               容易误解或者误用的地方

由于ACE的庞大性，很多时候大家会错误的理解使用ACE的某些代码实现某些特性。在此将写一些曾经让我们栽跟头的阴沟写出来。另一方面，ACE的文档的某些介绍也存在含混，会误导大家的理解，错误的地方。