文件大小计算，Int64，以及32bit与64bit之间的差异 [英] File size calculation, Int64, and differences between 32bit and 64bit

问题描述

我有以下代码的问题：

  var 
 FileSize：Int64; 
 ... 
 FileSize：= Info.nFileSizeLow或（Info.nFileSizeHigh shl 32）; 
  

我预计它会工作，因为 Int64 作业左侧的类型。但是没有。包含 shl 的部分计算似乎产生溢出。

所以我将其更改为：

  FileSize：= Info.nFileSizeLow或（Int64（Info.nFileSizeHigh）shl 32）; 
  

它适用于我的32位操作系统，但不适用于Vista 64位！ >

最后，

  FileSize：= Info.nFileSizeHigh; 
 FileSize：= FileSize shl 32; 
 FileSize：= Info.nFileSizeLow或FileSize; 
  

在两个系统上均可使用。

可以有人解释这三个版本的差异？

解决方案

一般来说，表达式的类型 a * b ，其中 a 和 b 的类型为整数和 * 是一个适用于整数的运算符，是一个整数类型，与Integer的范围相同。 （我通常说，作为一个例外是 / 。）为了使操作员使用64位操作，一个或多个操作数的范围必须只有可以用64位类型表达。这应该导致所有操作数被提升为64位，执行64位操作。

作业的左侧是64位位置通常对赋值运算符右侧的表达式的解释和键入没有影响。这是几乎所有语言的方式，我知道已经静态调度了32位和64位运算符重载（而不是任意精度整数或数字塔等上的多态分派操作符）;使事情行为否则将是非常令人惊讶的行为。

例如，过程调用的参数是对参数的有效隐式赋值。如果任务的左侧可以更改右侧表达式的解释，则不知道如何将参数解释为过程调用，而不知道定义：

var a，b：整数; $ pre>
// ...
P（（a shl 16）或b）; // 32位运算还是64位运算？


我不知道为什么你看到与第二个和第三个版本的代码不同的行为。据我所见，他们应该被解释一样，在我的测试中，它们被解释为相同。如果您可以提供在32位Windows上工作但在64位Windows上失败的示例代码，我可以进一步调查。

I had problems with the following code:

var
  FileSize : Int64;
...
FileSize := Info.nFileSizeLow or (Info.nFileSizeHigh shl 32);

I expected it to work because of the Int64 type of the left side of the assignment. But it does not. The partial calculation containing the shl seems to produce an overflow.

So I changed it to:

FileSize := Info.nFileSizeLow or (Int64 (Info.nFileSizeHigh) shl 32);

which works on my 32 bit operating system, but does not work on Vista 64 bit!

Finally,

FileSize := Info.nFileSizeHigh;
FileSize := FileSize shl 32;
FileSize := Info.nFileSizeLow or FileSize;

works on both systems.

Can someone explain the differences in these three versions?

解决方案

Generally speaking, the type of the expression a * b, where a and b are of type Integer and * is an operator that applies to Integer, is an integer type with the same range as Integer. (I say generally, as an exception is /.) In order for an operator to use 64-bit operations, one or more of the operands must have a range that is only expressible with a 64-bit type. That should cause all the operands to be promoted to 64-bit, and a 64-bit operation performed.

The fact that the left hand side of an assignment is a 64-bit location generally has no effect on the interpretation and typing of the expression on the right hand side of the assignment operator. This is the way it is in almost all languages that I'm aware of that have statically dispatched 32-bit and 64-bit operator overloads (as opposed to polymorphically dispatched operators on arbitrary precision integers or numeric towers etc.); making things behave otherwise would be very surprising behaviour.

For example, arguments to procedure calls are effectively implicit assignments to the parameters. If the left hand side of an assignment could change the interpretation of the expression on the right, we would not know how to interpret the argument to a procedure call without already knowing the definition:

var a, b: Integer;
// ...
P((a shl 16) or b); // 32-bit operation or 64-bit operation?

I do not know why you are seeing different behaviour with your second and third versions of the code. As far as I can see, they should be interpreted the same, and in my tests, they are interpreted the same. If you could provide sample code that works on 32-bit Windows but fails on 64-bit Windows, I could investigate further.

这篇关于文件大小计算，Int64，以及32bit与64bit之间的差异的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！