unsigned long vs long

[Mike Pliam]

I have seen C++ code that uses

 typedef unsigned long ulong;

I want to use either long or 'ulong' to point to bytes in a file. It seems to me that ulong should be superior to long for such a task, however, I'm uncertain of this. It is possible that a function returning such a pointer could return -1 if the function fails. But there are other ways to indicate function failure and possibly benefit from the additional byte span possible with ulong compared to long.

What are your thoughts?

[Chris_F]

I think neither is particularly better than the other.

long is a 32-bit value, which means if you use the signed version you will be limited to handling files up to 2GB in size, or 4GB if you use unsigned.

These days, with modern file systems, it's much more common to encounter file sizes >4GB, so I would suggest using int64_t.

[Mike Pliam]

Thanks Chris. Do you know how to calculate the maximum number for a given set of F bytes ? For example, VC++ will produce the following:

	printf("LONG_MAX = %d\n", LONG_MAX);  // LONG_MAX = 2147483647
	printf("long max = %0.4X\n", 2147483647);  // long max = 7FFFFFFF
	printf("ulong max = %0.4X\n", ULONG_MAX);  // ulong max = FFFFFFFF
	printf("ULONG_MAX = %ul\n", ULONG_MAX);  // ULONG_MAX = 4294967295l

I've tried using factorials to calculate the number of possible permutations of 32 and 64 but the results are WAY TOO BIG. Then I tried using the binomial coefficient algorithm (n things taken k at a time), but still cannot get the numbers to match what VC++ generates. What I'm trying to figure out is how many bytes can one count using unsigned __int64 ?

[Chris_F]

2^N - 1 for unsigned
2^(N - 1) - 1 for signed

Either way it's more bytes then you'll ever need.

[monarch_dodra]

IMO, it is not very good design to mix results and error codes in the same variable. That said, this is the behavior C coders and C libraries expect. When coding, it is usually better to go with the flow, then try to force your own paradigm.

Anyways, a "ulong"/"slong" is at least 32 bits in length. The actual size depends on your compiler/platform (I believe 64 bit linux uses 64 bit, for example). You can either use the macros LONG_MAX et all. to find limits, or use the C++ std::limits traits (they are constexpr in C++11):

#include <iostream>
#include <limits>

int main(int argc, char* argv[])
{
  std::cout << "long min: " << std::numeric_limits<long>::min() << std::endl;
  std::cout << "long min: " << std::numeric_limits<long>::max() << std::endl;

  std::cout << "ulong min: " << std::numeric_limits<unsigned long>::min() << std::endl;
  std::cout << "ulong min: " << std::numeric_limits<unsigned long>::max() << std::endl;
}

And I get:

long min: -2147483648
long min: 2147483647
ulong min: 0
ulong min: 4294967295

So apparently, my long is 32 bits long

----
32 bits is often times enough, but there are some cases where it is too small. Why settle for 32 bit types then when you can use 64?

The easiest one to use is "long long". It is not actually standard C++98, but ALL compilers support it as extension.

[D_Drmmr]

I have seen C++ code that uses

 typedef unsigned long ulong;

I want to use either long or 'ulong' to point to bytes in a file. It seems to me that ulong should be superior to long for such a task, however, I'm uncertain of this. It is possible that a function returning such a pointer could return -1 if the function fails. But there are other ways to indicate function failure and possibly benefit from the additional byte span possible with ulong compared to long.

What are your thoughts?

I don't quite see how special values are an argument for using a signed type, unless you think that the number of different special values is proportional to the number of valid values, which seems unlikely. When the number of special values is small (in particular, if there is only one) then I don't see the problem with simply providing a static const variable for it, similar to the way std::string uses std::string::npos to indicate 'not found' as a return value of std::string::find etc..

In the particular case of file access, I would suggest to use the type that is used by whichever interface you use. If you are using std::fstream, use std::streampos, std::streamsize, etc. If you are using the win32 functions CreateFile, ReadFileEx, then use a LARGE_INTEGER. If you need portable support for large files (> 2GB), I suggest looking for an existing library that abstracts the platform-specific types and functions for you.

[CMalcheski]

Either way it's more bytes then you'll ever need.

LOL I remember people saying that about the first PC with it's 640k of memory ... you will NEVER use that much memory! ... and the 40 meg hard drive when it came out ...

[S_M_A]

My first PC had a 20 Mb hard drive and a turbo button that switched from 8 to 10 MHz CPU clock...

[nuzzle]

What are your thoughts?

I would introduce an abstraction, a class called FilePtr or something, a handle that encapsulates the desired pointer functionality.

[CMalcheski]

My first PC had a 20 Mb hard drive and a turbo button that switched from 8 to 10 MHz CPU clock...

Notwithstanding the fact that I'm *shocked* that I used an apostrophe in "its" as a possessive ... those old turbo buttons ... LOL ... I remember paying $972 for a 100 Mb SCSI drive in 1992. Now you can get a 2Tb drive at Costco for $119 or is it $109? Complete external setup.