新的公司、新的环境、新的领域、新的业务，当然也包括新的程序和新的开发工具，这些，就是我这半年多以来的经历。其中，从Visual C++到PowerBuilder的转变，在这个Java与C#兴起并盛行的大时代，的确不能不让人觉得是一段难得的经历。适应的过程总伴着痛苦与挑战，幸而C++与汇编的基础帮我走了过来，也终于能体会到网上关于“PB已经没落”的传言确有一定道理。下面就我这半年多的使用PB的感觉总结总结：

一、PB采用二进制文件的方式存储其源码（.pbl文件）。

因为是二进制的，所以每编辑完一段代码保存的时候，PB的IDE都会对这段代码进行分析，确定没有语法错误后，才能保存成功。这种做法首先带来的不便就是，你无法随时对代码进行保存，尤其是刚改动了一半的代码，此时一旦掉电或者PB的IDE崩溃，刚才的改动将完全丢失。而且，PB的IDE确实也不太稳定，比较容易崩溃退出（当然也可能跟我用的版本有关，我用的是PB9，补丁打到Version 9.0.3 Build 8716）。另外，源码管理很不方便，虽然PB9中已经提供了SCC接口，通过它能使用SourceSafe等将PBL源码（按对象）重新组织成文本管理起来，但还是脱离不了PBL文件，也就是说真使用它时，除了在SourceSafe中管理好各个PB对象的源码外，还得对PBL文本本身也进行版本管理，否则就无法完全恢复出某个版本来。

二、PB无法同时编辑有继承关系的多个对象。

还是因为PB使用了二进制的源码文件，同时它还随时对代码进行分析，所以造就了PB的这个特点：当你有两个对象（类）A和B，B由A继承而来，于是你在PB的IDE中将无法同时打开A和B进行编辑，如果你正在修改B中的内容，发现此时基类A需要修改，你必须把B的编辑窗口关掉才能打开A来修改。这在开发过程中也极大地限制了程序员操作的方便性，比如Undo等动作就很不好在这种时候发挥作用。

三、PB不支持多重继承，也不支持接口。

C++的多重继承一直以来就被编译原理的研究认为是一个重要的麻烦来源，Java和C#中就不提供这样的东西，转而使用接口，但C++也正是有了多重继承，才让它没有接口的缺陷变得不那么严重。很多时候，我都在使用多重继承来完成多个接口的实现。可惜在PB里既无法使用接口，也无法使用多重继承。这让一些稍微复杂的应用很难分解功能到不同对象，也许是PB的设计者们认为PB就适合一些简单的模型的设计开发吧。

四、由于不区分大小写，同时对变量的作用域控制很有限，标识符极容易冲突

PB的对象有自己的属性、方法，方法有参数，方法里还有局部变量，这些各种不同的东西，所使用的标识符竟然会互相冲突，比如窗口对象有属性X、 Y，表示对象的左上角坐标，这样，在这个对象里，其方法的参数，方法的局部变量，就都不能使用X和Y作为名字了。除了加上各种表示变量类型的前缀外（如使用 li_X 和 li_Y 的变量名，表示局部整型变量），还真是没有什么太好的办法。

五、变量定义时，只能用常量进行初始化

其实这不是一个严重的问题，只是它给代码带来一个问题，就是如果需要调用函数或者通过一个表达式计算出某个变量的初始值时，你就必须写两行代码，第一行定义变量，第二行才赋值。如：

integer a = 1
integer b // 不能写为 integer b = a + 1
b = a + 1

六、虽然在一个函数里，变量可以随时定义，但其作用域和生存期却都为整个函数

这个问题也属于一些习惯的问题，也是在编写代码时特别应小心的，比如：

string ls_Text = ""
integer li_Index
for li_Index = 1 to 3
    integer li_Value = 1
    li_Value ++
    ls_Text += "li_Value = " + string(li_Value) + "~n"
next
MessageBox("", ls_Text)

结果是：

li_Value = 2
li_Value = 3
li_Value = 4

也就是说那个 integer li_Value = 1 只执行了一次，说明它的生存期为整个函数。但上面的代码却容易让人以为循环每次都执行了赋值为1的动作。

评论（备份自LiveSpace）：

• 2007-08-19 - bear keke: 再漂过～～～～～～··
• 2007-09-01 - 柳奇瑞: 搞不懂　路过