views:

6438

answers:

6

Not to long ago someone told me that long are not 64 bits on 64 bit machines and i should always use int. This did not make sense to me. I seen docs (such as the one on apples official site) say that long are indeed 64 bits when compiling for a 64bit CPU. I looked up what it was on windows and found

  • Windows: long and int remain 32-bit in length, and special new data types are defined for 64-bit integers.

from http://www.intel.com/cd/ids/developer/asmo-na/eng/197664.htm?page=2

What should i use? should i define something like uw, sw ((un)signed width) as a long if not on windows. Otherwise do a check on the target CPU bitsize?

+1  A: 

If you need to use integers of certain length, you probably should use some platform independent headers to help you. Boost is a good place to look at.

PolyThinker
+3  A: 

This article on MSDN references a number of type aliases (available on Windows) that are a bit more explicit with respect to their width:

http://msdn.microsoft.com/en-us/library/aa505945.aspx

For instance, although you can use ULONGLONG to reference a 64-bit unsigned integral value, you can also use UINT64. (The same goes for ULONG and UINT32.) Perhaps these will be a bit clearer?

Reuben
+4  A: 

The easiest way to get to know it for your compiler/platform:

#include <iostream>

int main() {
  std::cout << sizeof(long)*8 << std::endl;
}

Themultiplication by 8 is to get bits from bytes.

When you need a particular size, it is often easiest to use one of the predefined types of a library. If that is undesirable, you can do what often happens with autoconf software and have the configuration system determine the right type for the needed size.

Paul de Vrieze
Not that it matters, but 8-bit bytes are not actually part of the C spec(clause 3.6 and 5.2.4.2.1 of the C standard). Although you would be hard pressed to find a machine where it wasn't 8 bits, you could check LONG_BIT to see how big your long datatype is.
Andres
Of course, you're right, it's actually architecture dependent ("addressable unit of data storage large enough to hold any member of the basic character set of the execution environment"), but the most commonly used architectures that equals 8 bits.
Paul de Vrieze
+1  A: 

Microsoft has also defined UINT_PTR and INT_PTR for integers that are the same size as a pointer.

Here is a list of Microsoft specific types - it's part of their driver reference, but I believe it's valid for general programming as well.

Mark Ransom
+13  A: 

In the Unix world, there were a few possible arrangements for the sizes of integers and pointers for 64-bit platforms. The two mostly widely used were ILP64 (for DEC Alpha, one of the first 64-bit machines) and LP64 (for almost everything else). The acronynms come from 'int, long, pointers are 64-bit' and 'long, pointers are 64-bit'.

Type           ILP64   LP64   LLP64
char              8      8       8
short            16     16      16
int              64     32      32
long             64     64      32
long long        64     64      64
pointer          64     64      64

The ILP64 system was abandoned in favour of LP64 (that is, almost all later entrants used LP64; only systems with a long heritage of 64-bit operation use a different scheme). All modern 64-bit Unix systems use LP64. MacOS X and Linux are both modern 64-bit systems.

Microsoft uses a different scheme for transitioning to 64-bit: LLP64 ('long long, pointers are 64-bit'). This has the merit of meaning that 32-bit software can be recompiled without change. It has the demerit of being different from what everyone else does, and also requires code to be revised to exploit 64-bit capacities. There always was revision necessary; it was just a different set of revisions from the ones needed on Unix platforms.

If you design your software around platform-neutral integer type names, probably using the C99 <inttypes.h> header, which, when the types are available on the platform, provides, in signed (listed) and unsigned (not listed; prefix with 'u'):

  • int8_t - 8-bit integers
  • int16_t - 16-bit integers
  • int32_t - 32-bit integers
  • int64_t - 64-bit integers
  • uintptr_t - unsigned integers big enough to hold pointers
  • intmax_t - biggest size of integer on the platform (might be larger than int64_t)

You can then code your application using these types where it matters, and being very careful with system types (which might be different). There is an intptr_t type - a signed integer type for holding pointers; you should plan on not using it, or only using it as the result of a subtraction of two uintptr_t values (ptrdiff_t).

But, as the question points out (in disbelief), there are different systems for the sizes of the integer data types on 64-bit machines. Get used to it; the world isn't going to change.

Jonathan Leffler
For those of use who've been around long enough, the 64-bit transition has some parallels with the 16-bit to 32-bit transition of the mid-80s. There were computers that were IL32 and others that were L32 (adapting the new notation to the old problem). Sometimes 'int' was 16-bit, sometimes 32-bit.
Jonathan Leffler
Don't forget that this only applies to C-ish languages. Others have saner specifications where a) the compiler writer is not allowed to choose the size of the datatypes willi-nilly or b) the physical representation of the datatypes doesn't "leak" or c) integers are always infinitely large.
Jörg W Mittag
True - but for those languages which specify the behaviour, there isn't an issue in the first place. For example, Java has a 'long', but the size is fixed (64-bit?), on all platforms. So, there are no issues porting to a 64-bit machine; the size does not change.
Jonathan Leffler
A: 

See table N1 in article: Optimization of 64-bit programs