long data type with 64-bit
-
Hello everyone, I have a question concerning the long data type. Using a 32-bit compiler, sizeof(long) = 4. But what about 64-bit? Regards, Alex Don't try it, just do it! ;-)
-
Hello everyone, I have a question concerning the long data type. Using a 32-bit compiler, sizeof(long) = 4. But what about 64-bit? Regards, Alex Don't try it, just do it! ;-)
longis still 32-bits in a 64-bit compiler. If you want to have a 64-bit integer, uselong long(platform independent) or__int64(Windows). If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac -
Hello everyone, I have a question concerning the long data type. Using a 32-bit compiler, sizeof(long) = 4. But what about 64-bit? Regards, Alex Don't try it, just do it! ;-)
short intis the same asshortlong intis the same aslongsizeof(short)returns 2sizeof(long)returns 4 on a 16 bits environment :sizeof(int)returns 2 on a 32 bits environment :sizeof(int)returns 4 on a 64 bits environment :sizeof(int)returns 8sizeof(long long)is supposed to return 8, but it is not provided by the standard, and not every compilers know that type.sizeof(__int64)is quite the same aslong long, but AFAIK, it is a microsoft specific type, so, not portable either...
TOXCCT >>> GEII power
[VisualCalc 3.0 updated ][Flags Beginner's Guide new! ]
-
short intis the same asshortlong intis the same aslongsizeof(short)returns 2sizeof(long)returns 4 on a 16 bits environment :sizeof(int)returns 2 on a 32 bits environment :sizeof(int)returns 4 on a 64 bits environment :sizeof(int)returns 8sizeof(long long)is supposed to return 8, but it is not provided by the standard, and not every compilers know that type.sizeof(__int64)is quite the same aslong long, but AFAIK, it is a microsoft specific type, so, not portable either...
TOXCCT >>> GEII power
[VisualCalc 3.0 updated ][Flags Beginner's Guide new! ]
toxcct wrote:
on a 64 bits environment : sizeof(int) returns 8
This is not currently the case, and many on the standards committee are arguing against making it so for backwards compatibility reasons. Currently, on 64-bit compilers, sizeof(int) will return 4 (just like on 32-bit compilers). sizeof(long long), which most compilers support and is being discussed as part of the next standard, will return 8. sizeof(void*) will return 8 on a 64-bit compiler. Note that much of that is still subject to change ... we should know for sure when/if the standard's committee is able to agree on things by 2008. As a side note, it is best to declare the type of integer you actually want (or typedef it) instead of declaring "int" for precisely this reason. If you need low numbers (less than 255/127), use unsigned char/char; if you need larger numbers, use unsigned short/short; and if you need huge numbers, use unsigned long/long. Finally, on 64-bit systems, if you really need the massive numbers, use unsigned long long/long long. It will help save you some portability issues down the road. If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac -- modified at 13:30 Thursday 22nd June, 2006
-
Hello everyone, I have a question concerning the long data type. Using a 32-bit compiler, sizeof(long) = 4. But what about 64-bit? Regards, Alex Don't try it, just do it! ;-)
Alexander M. wrote:
Using a 32-bit compiler, sizeof(long) = 4. But what about 64-bit?
On Windows, still 4. On most Unix-like systems: 8 In general: implementation dependent.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
-
toxcct wrote:
on a 64 bits environment : sizeof(int) returns 8
This is not currently the case, and many on the standards committee are arguing against making it so for backwards compatibility reasons. Currently, on 64-bit compilers, sizeof(int) will return 4 (just like on 32-bit compilers). sizeof(long long), which most compilers support and is being discussed as part of the next standard, will return 8. sizeof(void*) will return 8 on a 64-bit compiler. Note that much of that is still subject to change ... we should know for sure when/if the standard's committee is able to agree on things by 2008. As a side note, it is best to declare the type of integer you actually want (or typedef it) instead of declaring "int" for precisely this reason. If you need low numbers (less than 255/127), use unsigned char/char; if you need larger numbers, use unsigned short/short; and if you need huge numbers, use unsigned long/long. Finally, on 64-bit systems, if you really need the massive numbers, use unsigned long long/long long. It will help save you some portability issues down the road. If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac -- modified at 13:30 Thursday 22nd June, 2006
Zac Howland wrote:
use unsigned long long/long long. It will help save you some portability issues down the road.
I'd recommend using typedefs and __int64. That's far easier to maintain, should long long mean anything else than 64 bits on a specific platform/compiler. My 2 cents. :)
-- 100% natural. No superstitious additives.
-
toxcct wrote:
on a 64 bits environment : sizeof(int) returns 8
This is not currently the case, and many on the standards committee are arguing against making it so for backwards compatibility reasons. Currently, on 64-bit compilers, sizeof(int) will return 4 (just like on 32-bit compilers). sizeof(long long), which most compilers support and is being discussed as part of the next standard, will return 8. sizeof(void*) will return 8 on a 64-bit compiler. Note that much of that is still subject to change ... we should know for sure when/if the standard's committee is able to agree on things by 2008. As a side note, it is best to declare the type of integer you actually want (or typedef it) instead of declaring "int" for precisely this reason. If you need low numbers (less than 255/127), use unsigned char/char; if you need larger numbers, use unsigned short/short; and if you need huge numbers, use unsigned long/long. Finally, on 64-bit systems, if you really need the massive numbers, use unsigned long long/long long. It will help save you some portability issues down the road. If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac -- modified at 13:30 Thursday 22nd June, 2006
That standard is so stupid... they should use long as synonym for char *, which makes pointer arithmetic easier. At the moment there is a big problem when you want to cast a pointer to an integer, especially if you are creating source code for different platforms and compilers. Windows defines ULONG_PTR etc, but I've never heard of a Linux equivalent :(. VC++ and GCC are also very different in some cases, that's getting on my nerves... Thanks for your answers! Don't try it, just do it! ;-)
-
Zac Howland wrote:
use unsigned long long/long long. It will help save you some portability issues down the road.
I'd recommend using typedefs and __int64. That's far easier to maintain, should long long mean anything else than 64 bits on a specific platform/compiler. My 2 cents. :)
-- 100% natural. No superstitious additives.
I agree with the typedefs, but __int64 only means something for Microsoft's compiler. If you use any other compiler, it is meaningless (or you would have to typedef it to long long). If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac
-
That standard is so stupid... they should use long as synonym for char *, which makes pointer arithmetic easier. At the moment there is a big problem when you want to cast a pointer to an integer, especially if you are creating source code for different platforms and compilers. Windows defines ULONG_PTR etc, but I've never heard of a Linux equivalent :(. VC++ and GCC are also very different in some cases, that's getting on my nerves... Thanks for your answers! Don't try it, just do it! ;-)
That assumption is why we have the problems with int, long, and void* today. In the 32-bit standard, they were all the same size, so programmers would take advantage of that and cast 32-bit pointers to integers. The problem is now that when you want to run a 32-bit application on a 64-bit platform, that assumption breaks your code (not desirable). To prevent this from happening, one of the proposals being discussed is to create a long long datatype for 64 bits, long and int would still be 32 bits, short would still be 16 bits, and char woudl still be 8 bits. void* would be 64 bits. As for the ULONG_PTR and INT_PTR ... those are just typedefs (use to be #define's). They are handy for recompiling in 64 bit mode, but still run into the same problems when you try to run a 32 bit application on a 64 bit platform. The presense or absense of those definitions has nothing to do with the actual compiler and everything to do with the utility libraries. You can VERY easily create your own. If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac
-
I agree with the typedefs, but __int64 only means something for Microsoft's compiler. If you use any other compiler, it is meaningless (or you would have to typedef it to long long). If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac
I see that I didn't really express what I meant. I really meant that the typedef should be changed to alias to the platform specific 64 bit type. (And not just the microsoft __int64 type)
-- 100% natural. No superstitious additives.