来自微软的资料鼓吹：高级优化对话框中的所有编译选项都被认为是不稳定的，它们可能导致不正确的结果，甚至程序崩溃。对于其中的大多数，这种说法是正确的，但是经常有一个叫做"allow unrounded floating point operations"的选项能够给予正确的结果，防止应用程序产生bug。 考虑下面的代码段：
dim x as double, y as double, i as integer
x = 10 ^ 18
y = x + 1 ' this can't be expressed with 64 bits
msgbox (y = x) ' 显示 "true" (不正确的结果)
严格地说，由于x和y变量不包含相同的数值，msgbox将显示false。可问题是，由于数值1e18与1e18＋1都以相同的64位浮点double类型来表示，它们最终包含了几乎相同的数值，最后的msgbox结果将是true。
如果打开了"allow unrounded floating point operations"编译选项，vb就能重用已在数学协处理器堆栈中的数值，而不是内存中的数值（比如：变量）。因为fpu堆栈具备80位的精度，因此就可以区分出这2个数值的不同：
' if the program is compiled using the
' "allow unrounded floating point operations" compiler option
msgbox (y = x) ' 显示 "false" (正确的结果)
总结一下：当以解释模式、或者编译的p－code模式、或者编译的native代码模式但关掉"allow unrounded floating point operations"选项这3种方式运行一个程序时，所有浮点数字运算在内部都以80位的精度进行处理。但如果有一个数值是存储在64位double变量中，结果就是接近的了，并且，随后使用那个变量的表达式也将产生近似的结果，而不是绝对正确的结果。
相反，如果打开"allow unrounded floating point operations"编译选项后运行一段native编译代码，在随后的表达式中vb就经常能重用内部的80位数值，而忽略存储在变量中的当前数值。注意：我们并不能完全控制这个功能，vb也许对此生效，也许就不生效，这要取决于表达式的复杂程度以及最初分配数值语句与随后产生结果的表达式语句的距离远近。
Java Asp PHP .Net XML C/C++ CGI VB Jsp J2ee J2se J2me EJB Servlet Tomcat Resin Struts Weblogic Eclipse ANT GUI JMS Web servise IDEA Webphere Hibernate Spring Jboss Applet Swing Socket Javamail Perl Ajax P2P 安全 模式 框架 测试 开源 游戏
Windows XP Windows 2000 Windows 2003 Windows Me Windows 9.x Linux UNIX 注册表 操作系统 服务器 应用服务器
