BcdDivide 函数在 Delphi XE 和 XE2 中的行为不同
FmtBcd.pas
已在 Delphi XE2 中进行了广泛的修改和重写。在我的一个项目中,我有一个对两个 Bcd 值使用除法运算的情况,但两个版本产生不同的结果。在最坏的情况下,Delphi XE2 可能会抛出 Bcd 溢出错误
。
示例:在 Delphi XE2 控制台应用程序中运行以下代码:
var A, B, C, D: TBcd;
begin
A := StrToBcd('1');
B := StrToBcd('3');
BcdDivide(A, B, C);
WriteLn(BcdToStr(C));
try
BcdMultiply(C, C, D);
WriteLn(BcdToStr(D));
except
on E: Exception do
WriteLn(E.Message);
end;
ReadLn;
end.
上述输出将为:
0.333333333333333333333333333333333333333333333333333333333333333
BCD overflow
变量 C
包含一个具有 63 个小数位的 Bcd 值。对变量 C
执行第二次 BcdMultiply
运算将导致 Bcd 溢出错误
。
然而,在 Delphi XE 中运行相同的代码会产生以下结果,并且没有任何异常提示:
0.3333333333
0.11111111108888888889
任何人都可以建议解决此问题的最佳实践方法吗?
FmtBcd.pas
has been extensively revised rewritten in Delphi XE2. In one of my projects, I have a case that uses a division operation on two Bcd
values, but the two versions yield different results. In the worst case, the Delphi XE2 may throw a Bcd overflow error
.
Example: Running the following code in Delphi XE2 console apps:
var A, B, C, D: TBcd;
begin
A := StrToBcd('1');
B := StrToBcd('3');
BcdDivide(A, B, C);
WriteLn(BcdToStr(C));
try
BcdMultiply(C, C, D);
WriteLn(BcdToStr(D));
except
on E: Exception do
WriteLn(E.Message);
end;
ReadLn;
end.
Output of the above will be:
0.333333333333333333333333333333333333333333333333333333333333333
BCD overflow
The variable C
contains a Bcd Value with 63 decimal places of specificity. Performing a second BcdMultiply
operation on variable C
will cause a Bcd overflow error
.
However, to run the same code in Delphi XE yields the following result without any exception prompt:
0.3333333333
0.11111111108888888889
Could anyone please suggest a best-practice method for resolving this problem?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
问题中的代码在 XE2 更新 4 中产生预期的输出。请注意,更新 3 产生错误的输出,因此显然修复程序随更新 4 一起到达。此外,XE3 产生预期的输出。
The code in the question produces the expected output in XE2 update 4. Note that update 3 produces the bad output and so clearly the fix arrived with update 4. Also, XE3 produces the expected output.