6

http://msdn.microsoft.com/en-us/library/windows/desktop/aa383742%28v=vs.85%29.aspx

They are supposed to be used like this, set two 32 bit values on LowPart and HighPart and then perform arithmetic on the QuadPart.

int a,b,c;
ULARGE_INTEGER u;
...
u.LowPart = a;
u.HighPart = b;
u.QuadPart += c;

So if you are going to perform arithmetic on the QuadPart(64 bits) anyways you need a 64 bit processor, right? So what is the whole point? Why not assign the value directly to the QuadPart?

Roland
  • 7,525
  • 13
  • 61
  • 124

3 Answers3

9

You don't need a 64 bit processor to perform arithmetic on a 64 bit data type. All 32 bit compilers that I know of support arithmetic on 64 bit integers. If the hardware doesn't allow native arithmetic, then the compiler has to generate code to do the arithmetic. Typically this will make use of support functions in the compiler's RTL.

The struct is intended for use by compilers that don't provide native support for 64 bit data types. The very documentation to which you linked makes that clear:

Note Your C compiler may support 64-bit integers natively. For example, Microsoft Visual C++ supports the __int64 sized integer type. For more information, see the documentation included with your C compiler.

Compilers that don't support native 64 bit integers will not be able to treat the QUADPART union member as an integer.

typedef union _ULARGE_INTEGER {
  struct {
    DWORD LowPart;
    DWORD HighPart;
  };
  struct {
    DWORD LowPart;
    DWORD HighPart;
  } u;
  ULONGLONG QuadPart;
} ULARGE_INTEGER, *PULARGE_INTEGER;

And the definition of ULONGLONG:

#if !defined(_M_IX86)
 typedef unsigned __int64 ULONGLONG;
#else
 typedef double ULONGLONG;
#endif

Of course, all compilers written in the past 10 years (or more) will have native support for 64 bit integers. But this union was originally introduced a very long time ago and the compiler landscape would have been different then. When looking at Windows header files, always bear in mind the history and legacy.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
  • >Compilers that don't support native 64 bit integers will not be able to treat the QUADPART union member as an integer. So what will happen when you do u.QuadPart += c on such a compiler? – Roland Feb 16 '13 at 23:42
  • 3
    Read the quoted text from the header file, the part with the #if. – Raymond Chen Feb 17 '13 at 00:54
  • @RaymondChen What would happen on a 32 bit compiler if you do `u.LowPart += 100` and it overflows? – Roland Aug 07 '17 at 05:15
  • I suggest adding a definition for RTL([Runtime library](https://en.wikipedia.org/wiki/Runtime_library)). I didn't know what it was. – Roland Aug 07 '17 at 14:14
5

Typically ULARGE_INTEGER is used when you need to convert a pair of 32-bit integers into a 64-bit integer or vice-versa.

For example, consider manipulating a FILETIME structure:

void add_millisecond(FILETIME * ft)
{
  ULARGE_INTEGER uli;
  uli.LowPart = ft->dwLowDateTime;
  uli.HighPart = ft->dwHighDateTime;
  uli.QuadPart += 10000;
  ft->dwLowDateTime = uli.LowPart;
  ft->dwHighDateTime = uli.HighPart;
}

You can't assign the QuadPart value directly because you don't have it; all you have is the high and low parts.

Harry Johnston
  • 35,639
  • 6
  • 68
  • 158
  • `uli.QuadPart += 10000;` this code should not work on a compilers that don't support 64 bit integers, right? – Roland Aug 07 '17 at 05:09
  • On compilers that only support 32 bit arithmetic you can't do `uli.QuadPart += 10000;` and instead have to do as outlined here: https://stackoverflow.com/a/45540114/480894 – Roland Aug 07 '17 at 06:42
  • @Roland, I'm not aware of any modern-day Windows compilers that only support 32-bit arithmetic. – Harry Johnston Aug 07 '17 at 07:38
3

So if you are going to perform arithmetic on the QuadPart(64 bits) anyways you need a 64 bit processor, right?

No. But the real question should be, do you need a compiler that supports a 64 bit integer type? The answer to that too, in this case, is no. That's what these functions are for:

http://msdn.microsoft.com/en-us/library/windows/desktop/aa383711%28v=vs.85%29.aspx

Benjamin Lindley
  • 101,917
  • 9
  • 204
  • 274