Hi Stephen, >What is a ISO 14882 compliant way of representing a 64-bit constant value? There is no ISO 14882 compliant way of representing a 64-bit constant value, because what a constant value is represented as depends on your platform (compiler + operating system). For example, you could have a C++ compiler that has these data sizes: char, wchar_t : 8 bit short, int, long : 16 bit And there is no way to represent a 64 bit constant value on that platform. On another platform (say a mythical nVidia super duper GPU), you could have these data sizes: char, wchar_t : 256 bit short, int, long : 256 bit And there you can only express a 64 bit constant value insofar as 64 bits readily fits in 256 bits. For numeric constants, these are all just regular old constant numbers, with a type bias: 'A' is 65 (on, say, an ASCII, ISO 8859-1, or ISO 10646 platform), with a char bias. L'A' is 65, with a wchar_t bias. 65 has an signed int bias. 65U has an unsigned int bias. 65L has a signed long int bias. 65UL has an unsigned long int bias. I'm not aware of any way of representing a short bias (except by casting). And the long long bias (LL and ULL suffixes) is a C99-ism, or a GCC extension in C++. In my opinion, current personal computers platforms -- such as PowerPC based or current Intel & AMD CPUs, *should* use these sizes (but don't): char : 8 bit wchar_t : 32 bit short : 16 bit int : 32 bit long : 64 bit bool : 32 bit (same as int) Unfortunately, most current personal computers use a compiler configuration known as ILP32 (int, long and pointers are 32 bit). Sometimes you find one that is IL32/P64. But I haven't seen one that is I32/L64/P32 or I32/L64/P64. Relying on the GCC extension (C99-ism enabled on C++), most GCC's I use are IL32/LL64/P32, which I find to be an abomination in-that (in my opinion) the long should be twice the size of the int (where 'int' represents the platform's natural word size), and short should be half the size of int. Hence the terms 'long', and 'short'. Following the spirit of K&R C. Alas... I hold a minority position, so please don't cite me as gospel. Besides, changing the meaning of 'int' and 'long' every 10 years insures job security. It's like the Y2K debacle over-and-over-and-over again, but on a decade cycle instead of a millenium cycle. Note: large numeric constants that fit in a 'long long' (64-bit on many platforms) do not participate in the "free" implicit type conversion. Which is why the LL or ULL suffix is mandatory. I'll give you a "for instance". Just over two decades ago, I worked on a platform that had 13-bit bytes, the natural word size was 13-bits, the long (double-word) was 26-bits. A 64-bit number is not natively represented on that platform; you'd have to create your own 64-bit handling code to work with 64-bit numbers. HTH, --Eljay
