ACE的一些问题和难点
对ACE仰慕已久，终于有机会使用ACE开发系统。对ACE的仰慕与追求女孩是一样的，理想化的、美好的。实际用上才发现，ACE如女人一样难以琢磨，有太深奥的学问。搞不清楚，会让你身心疲惫。
总结来说，ACE有如下好处：
1. 跨平台
2. 中间业务
3. 系统抽象
4. 网络传输
5. 新的模式
6. 。。。
ACE的恶名：
1. 内存泄露
2. 系统庞大
3. 体系繁杂
4. 概念难以理解
实际使用中发现的问题：
1. 异步的Proactor在Linux下不能正常工作
2. 和MFC结合有问题
linux系统安装步骤csdn3. 递归线程锁Linux下有问题
现在简单说一说，经过使用，ACE的优点一个都不少，都可以体验到。比如我们现在在Windows下开发程序，与系统、语言有关的函数、调用、资源全部使用ACE。在VS下编译调试，要知道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是“会者不难，难者不会”。
好东西啊！一般人我不告诉他！
本文来自CSDN博客，转载请标明出处：blog.csdn/hwz119/archive/2007/03/16/1530844.aspx

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。