试用CBX1有感之二，我关注的IDE是... ...

这些年来没少关心过Borland，每次新品的发布总是很关注。然则，这次CBX1除了所谓的跨平台之外，真没有什么看点了。
对一个程序员来说，工具是用来解决问题的，如果它不能很好地为我们解决问题而设计，只是为了些所谓的超前的特性，再好也不用也罢，更何况还没有到好这种状况。

连个程序框架都用别人的了，何必还要再做编译器，我在这给borland出个主意，编译器去改gcc，编辑器去改eclipse，版本控制就改cvs，.......，算了，什么都不做，站在旁边看开源社区的hacker做就得了。(这是气话，恨铁是不能成钢啊)。

我觉得有点悲伤，最近两年老是心里在打鼓，是不是不要跟borland这条工具链混了，投向M$的工具链算了。这次试用，真有点加剧了这种想法。

最近两天，摸了摸MFC，用起来总是找不到VCL的感觉，比如，UTF8到AnsiString的转换就得自己用API来用，没有VCL方便。VCL里面还有许多这种小小功能的API，非常节省时间及精力，可让自己一心关注解决应用问题而非系统或半系统性的问题。

不知CBX2或者CBX3能否有一种全新的程序框架，能很好的支持.NET的之后才去考虑跨平台的事，CLX就是一个失败的故事，为什么还要重复呢。

解决跨平台的任务不是也不应该是C++的，更不可能通过一家公司的一个工具就可以解决的。Java目前比较有希望能做得到这个目标，但要解决得很彻底我看也是不大可能。

而且，JAVA是二进制的解决方案，而CBX1只是源码的解决构想，我真觉得用错了语言来做一件更错误的事。

试想，用源码来解决跨平台，肯定要加入很多判断或者是要做许多层的抽象并限制使用许多系统特性，运行效率就会下降许多，或者是要加入许许多多的编译条件宏，代码就会变得复杂，阅读起来就费劲，可读性就变差了。我觉得这两点是个大大的问题。

如果很强调运行效率，也就不用borland的工具了，毕竟OS及CPU都不是borland的，可能就要用MS及Intel的编译器了。
所以，我用borland的工具的原因是它能加快我的开发进度，在VCL框架下生成的代码具有良好的可阅读性(至少我觉得比MFC框架下的要好)。

我觉得不管后续产品如何发展，我关注的IDE是下面些内容(一家之言)：
1、编辑器要能方便的完成代码录入的工作，要能支持宏操作，最好是像SlickEdit那样，给出一个命令框，想做什么都可能；也希望能有类似SourceInsight我功能，其实我一直觉得SourceInsight不能做得跟编译器及平台(要输入的宏条件太多)结合起来用很不爽，如果由编译器工具公司来做这件事可能会更好；
2、编译器要能完全符合C++的标准，并能检测到可能及意外的错误；
3、调试器要能方便地获得调试者所想要得到的信息(我觉得CBC6做得就是比较VC6的用，如：Breakpoint Properties就是一个非常好的功能，我在VC6中没有找到类似的功能，谁知道与之相似的功能在哪，请告知，先谢了)；
4、第三方的工具链要能较好地集成进来，如版本控制、代码及质量分析(QA)；
5、建模要能支持双向更新；
6、对DLL的支持要能支持C++的名字裂变及MS格式的DLL(我想太多的人与我一样，好多时候不得不用VC的工具做个别扭的封装，转换成C格式之后才能在BCB中使用)；
7、对于Win32 API(以后的是.NET了)要做更完美的封装，多于线程安全要有更多的考虑；
8、对于网络要提供更好的支持，不能关加入一个ACE(这个东西，我已经跟进4年多了，到现在还只能当做业余爱好，每次推荐给项目开发小组时，总是遇到多多的反对----实现得太复杂、用起来太难)进来就拉倒，要让这个好东西融入整个框架，要不然加进来的意义就不大了；
9、要能体现软件生命周期的规律，也就是说，要有类似RUP迭代的支持。支持反反复复的需求分析、软件技术分析、架构设计、程序设计、程序开发、程序调试，而且这几个内容不是顺序的支持，要能反复迭代。
10、对数据库的支持不要再用BDE，而是用原厂商的东西，如支持oracle的OCI及OCCI；或者是要支持原厂商的API；
11、要能方便地开发插件，要加强这方面的支持，OpenTools还不够为广大人员接受使用，真有点遗憾；