Delphi 中的 C 风格十六进制 - 未记录的功能?
我偶然注意到以下代码
var
I: Integer;
begin
I:= StrToInt('0xAA');
ShowMessage(IntToStr(I)); // shows 170 = $AA
end;
在 Delphi 2009 中是可以的。顺便说一句,该功能帮助我从 C 头文件中提取十六进制常量。
我想知道该功能是否可以使用,或者该功能即将在未来版本中“修复”?
I noticed by chance that the following code
var
I: Integer;
begin
I:= StrToInt('0xAA');
ShowMessage(IntToStr(I)); // shows 170 = $AA
end;
is OK in Delphi 2009. BTW the feature helped me to extract hexadecimal constants from C header file.
I wonder is it OK to use the feature or the feature is about to be "fixed" in future versions?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
![扫码二维码加入Web技术交流群](/public/img/jiaqun_03.jpg)
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
这是一个功能,您可以信赖它。 Turbo Pascal 演变为 Delphi 过程中发生的哲学变化之一是承认 Delphi 生活在 C 语言主导的世界中,优雅地接受或容忍 C 语言比忽视它们并强迫 Delphi 开发人员获得更多的好处来解决它。 Rob 提到的与 C++ Builder 的互操作是一个因素,但事实上 Delphi 最初是为 Windows 设计的,而 Windows 在 Windows API 中有很多 C 语言工件。
我认为术语“阻抗不匹配”可能适用于此 - 它很简单,可以消除 Delphi 十六进制处理和“世界其他地方”之间的阻抗不匹配,所以我们做到了。
It's a feature, and you can rely on it. One of the philosophical changes that occurred in the evolution of Turbo Pascal into Delphi was the acknowledgment that Delphi lives in a C-dominated world and there was more to be gained by gracefully accepting or tolerating C-isms than ignoring them and forcing the Delphi developer to sort it out. Interop with C++ Builder as mentioned by Rob was a factor, but so was the fact that Delphi was designed first for Windows, and Windows has a lot of C language artifacts in the Windows API.
I think the term "impedance mismatch" may apply here - it was simple enough to remove the impedance mismatch between Delphi hex handling and "Rest of World", so we did.
回想一下,C++ Builder 也使用 Delphi RTL。该文档没有详细说明
StrToInt
接受“十进制或十六进制表示法”时的确切含义。您可以放心地期望StrToInt
继续接受 C 样式数字。Val
接受相同的输入,Read
也是如此(因为它们最终都会调用System._ValLong
)。Recall that the Delphi RTL is used by C++ Builder, too. The documentation doesn't go into detail about exactly what it means when it says
StrToInt
accepts "decimal or hexadecimal notation." You can safely expectStrToInt
to continue to accept C-style numbers.Val
accepts the same input, as doesRead
(because they all end up callingSystem._ValLong
).