最近发布了一个比AutoFreeAlloc还好用的GC Allocator：ScopeAlloc。欢迎探讨。

参见：http://cpp.winxgui.com/cn:a-general-gc-allocator-scopealloc

另外，考虑到StdExt库的通用性比WinxGui库强，我决定将其独立发布。

主页：http://cpp.winxgui.com/

1. erlang严谨的，有严格的理论基础。但erlang同时也是务实的，他不是实验产品。这和我发布的winx库理念一样：务实。
2. 一点都不喜欢防御式编程，所以看到erlang的fail fast理念，眼睛一亮。这几天实践下来，更是爱不释手。
3. 也许你在乎erlang不能提供array的便利。但是想象一下，当我们有成千上万个单体（进程）在跑时，我们还会过分在意单体的速度吗？在计算机的power越来越强时，我更关注的是单体间如何协调，如何提供持续服务。 要想实现正真意义上的人工智能，我的观念，必须有无穷多个可以独立计算的单体（细胞），他们之间通过消息相互指令，而又保持独立。所以只有类似erlang这样的工作机制，才有可能实现“人工智能”。另外array在数据海量的情况下，弊端立即凸显。所有基于array的数据结构，如hash_map等，遭遇严重的性能瓶颈。所以，最好的数据结构，还是表处理。

关于array性能瓶颈的注解：

1. 我在做电子表格的存盘时，因为用到了mfc的CMap（是一个HashMap），在大文件存盘时失去响应。使我头一次对HashMap的效率产生质疑。
2. 去年这个时候，我在C#中，尝试了向一个Dictionary（是一个HashMap）加入1亿条整数，花了整整一天时间没有完成，最后Kill进程告终。改用C++的std::map（红黑树），1小时搞定。后在C#改用OrderedDictionary（应该也是红黑树），2小时搞定（之所以比C++慢，是C++的map::insert操作以inline提供的缘故）。

当然HashMap也并非真的一定会在海量数据时很慢。如果我们可以预测数据集的大小，HashMap肯定还是比红黑树快。但是问题就在这个前提。我们可以准确预知未来吗？我们不能。所以HashMap要想获得好的性能，很累。但是如果我们采用树结构，我们获得的性能是稳定的，可以预测的。