ACE的一些问题和难点

ACE的一些问题和难点

    对ACE仰慕已久，终于有机会使用ACE开发系统。对ACE的仰慕与追求女孩是一样的，理想化的、美好的。实际用上才发现，ACE如女人一样难以琢磨，有太深奥的学问。搞不清楚，会让你身心疲惫。
    总结来说，ACE有如下好处：
    1. 跨平台
    2. 中间业务
    3. 系统抽象
    4. 网络传输
    5. 新的模式
    6. 。。。

    ACE的恶名：
    1. 内存泄露
    2. 系统庞大
    3. 体系繁杂
    4. 概念难以理解

    实际使用中发现的问题：
    1. 异步的Proactor在Linux下不能正常工作
    2. 和MFC结合有问题
    3. 递归线程锁Linux下有问题

    现在简单说一说，经过使用，ACE的优点一个都不少，都可以体验到。比如我们现在在Windows下开发程序，与系统、语言有关的函数、调用、资源全部使用ACE。在VS.net下编译调试，要知道VC的调试工具要比Linux下的方便友好多了。结果是，要移植到Linux下时，只需要在Linux下写好Makefile，把Windows下调试通过的程序包含进来，就完全可以运行，也省去了调试的麻烦。
    其它也全是，再比如说异步传输模式，在Windows下是使用完成端口，在Linux下是其它的东西。一般是AIO。如果自己写完成端口的传输层框架，要做的调试工作是相当麻烦的。在ACE下，使用Proactor即可，框架已经经过验证了。

    再说说ACE的恶名。
    1.内存泄露是指在Windows下的泄露，实际使用中发现，泄露并不是ACE泄露的，是VC泄露的，即使不使用ACE，创建一个空的工程，VC也会有一定数量的内存泄露，大小是固定的，体积是很小的。所以，这是ACE替VC的恶名。
    2.系统庞大，这是当然的了，复杂的东西当然庞大了，庞大后，功能也强大了。Windows也比Dos大多了吗。但是，实际使用中，我们只会使用到其中很小一部分，所以可以选择性地学习，连接文件时，连接程序也会提取用到的符号，最后的程序体积也不会很大。
    3.繁杂。因为ACE要处理各种异构平台，当然做了很多事。另外，还有人说ACE效率可能不行，因为太繁杂。其它，ACE中对不同平台的兼容是使用模板、预定义实现的，编译连接后，体积是很小的。最终代码不大。当然，ACE不太适合用在嵌入式系统上，因为使用到了很多模式，函数调用过多，这种开销在嵌入式系统上是不允许的。
    4.概念难以理解，这就是各人水平了。其实ACE中用到的各种技术和模式，都是大家多多少少用到的，只是没有这么大面积地地使用。

    再说说几个实际问题。
    1.因为Linux对Posix支持的不完整，所以，异步的Proactor在Linux和很多Unix下工作不正常，这个问题只需要安装一个Posix-aio做一个适配和伪装即可以。将来Linux内核完全支持Posix后，重新编译安装一个新内核即可真正支持异步传输。
    如果只装一个Posix-aio还不能正常工作，在这个基础上再装一个TProactor，一定可以解决问题。
    2.和MFC结合问题：在Windows下安装Perl环境，然后重启。然后执行下面命令
    cd %ACE_ROOT%
    perl bin/mwc.pl -type vc8 -value_template "configurations = 'MFC Release' 'MFC Debug' Release Debug"  ace/ace.mwc
    然后打开%ACE_ROOT%/ace/ace.sln，编译MFC两个工程，生成ACEmfc.lib及dll就可以了，然后使用时，先调用：ACE::init()，使用完了调用 ACE::fini()。
    就这么简单，一定可以用的。多试试。
    3.这个还没有大面积遇到，以后再说。

    ACE是“会者不难，难者不会”。

    好东西啊！一般人我不告诉他！