vb6中的Bug.欢迎高手来看.

Question

'-- 编程过程中发现的问题.我把问题做了简化.
'-- 我的猜想:VB6的解释器和编译器的代码不同.(可能是微软的两组人分别完成的)
'****************************************
'*-- 在IDE中结果为    0               *
'*-- 编译成EXE结果为  1               *
'****************************************
'-- 应该算是个BUG吧!Option ExplicitDim Num As LongPrivate Sub Form_Load()
    Dim r As Long
    r = Num + GetNum
    MsgBox "r = " & CStr(r), vbOKOnly + vbInformation, "r = Num + GetNum"
    End
End SubPrivate Function GetNum() As Long
    GetNum = Num
    Num = Num + 1
End Function

Answer 1

可能是编译器的一种优化，在调试中的确是０，但是编译器在生成最后的
ｐｅ文件时将　GetNum　删除，直接以内联的方式将　ＧｅｔＮｕｍ中的代码
嵌入ＧｅｔＮｕｍ调用处，所以ｅｘｅ的结果为１

Answer 2

晕！这也是bug？！
别的不想说了，自个儿琢磨一下执行顺序吧

Answer 3

我觉得,编译时可能先算的GetNum,而后算的r.(即先算函数,然后算表达式的值).
个人觉得r=0比较合理.
如果把代码改成
r = GetNum + Num
那么运算结果就统一了.都是1.
这个有点像C中的(i++),但是VB在解释时认为是(i++),在编译时又认为是(++i)了.

Answer 4

另外我在发现:实现VB的SubClass(为了捕捉消息),调试一段时间后IDE就Crush.
我保证还原了全部的,调试过程中的窗口函数指针.
编译成EXE就没有任何问题了,不会再Crush.
看来VB的IDE还是解释的不够好.不能和EXE结果完全统一.

Answer 5

基本功太差了！别怪人家编译器！
应该这么写！解释与编译的本质是什么？
Private Function GetNum() As Long
    Num = Num + 1
    GetNum = Num
End Function