3 ms·

> This is great information for anyone making the 32-bit to 64-bit transition, and at this point you really should be viewing 64-bit as your primary platform if

by cube13 14y ago

> This is great information for anyone making the 32-bit to 64-bit transition, and at this point you really should be viewing 64-bit as your primary platform if you're writing code for x86(amd64) platforms. Just falling back to 32-bit mode with WoW or similar for your target platform is just inexcusable at this point unless you have very specific legacy support issues. Eh, unless you absolutely need the addressable memory, there's no real reason to move a legacy codebase to native 64-bit unless the software absolutely needs the RAM. The general takeaway is that you shouldn't be relying on primitives that aren't underlying OS/implementation safe. Using things like longs(especially if you're targeting both Linux and Windows), and assumed pointer lengths can bite you in the ass if you're not careful(and there is a special circle of hell reserved for people who think bitshifting on a pointer type is fine). A few minutes doing some preventative #defines can save you a world of hurt, especially when porting to the next largest system.

derleth 14y ago
> Eh, unless you absolutely need the addressable memory, there's no real reason to move a legacy codebase to native 64-bit unless the software absolutely needs the RAM. Unless it can take advantage of the extra opcodes that are only available on x86-64 hardware. I think AVX is the best example here. http://en.wikipedia.org/wiki/Advanced_Vector_Extensions http://en.wikipedia.org/wiki/Advanced_Vector_Extensions > Using things like longs(especially if you're targeting both Linux and Windows), and assumed pointer lengths can bite you in the ass if you're not careful(and there is a special circle of hell reserved for people who think bitshifting on a pointer type is fine). A few minutes doing some preventative #defines can save you a world of hurt, especially when porting to the next largest system. Or investigate the types in stddef.h, such as ptrdiff_t: > It is a type able to represent the result of any valid pointer subtraction operation. > A pointer subtraction is only guaranteed to have a valid defined value for pointers to elements of the same array (or for the element just past the last in the array). http://www.cplusplus.com/reference/cstddef/ptrdiff_t/ http://www.cplusplus.com/reference/cstddef/ptrdiff_t/ Trying to mess with #define stuff is only a good idea if you're targeting older or somewhat nonconformant compilers. The includes were written by the compiler authors; trust them to know more about their compiler than you do.

by cube13 14y ago

derleth 14y ago

> Eh, unless you absolutely need the addressable memory, there's no real reason to move a legacy codebase to native 64-bit unless the software absolutely needs the RAM. Unless it can take advantage of the extra opcodes that are only available on x86-64 hardware. I think AVX is the best example here. http://en.wikipedia.org/wiki/Advanced_Vector_Extensions http://en.wikipedia.org/wiki/Advanced_Vector_Extensions > Using things like longs(especially if you're targeting both Linux and Windows), and assumed pointer lengths can bite you in the ass if you're not careful(and there is a special circle of hell reserved for people who think bitshifting on a pointer type is fine). A few minutes doing some preventative #defines can save you a world of hurt, especially when porting to the next largest system. Or investigate the types in stddef.h, such as ptrdiff_t: > It is a type able to represent the result of any valid pointer subtraction operation. > A pointer subtraction is only guaranteed to have a valid defined value for pointers to elements of the same array (or for the element just past the last in the array). http://www.cplusplus.com/reference/cstddef/ptrdiff_t/ http://www.cplusplus.com/reference/cstddef/ptrdiff_t/ Trying to mess with #define stuff is only a good idea if you're targeting older or somewhat nonconformant compilers. The includes were written by the compiler authors; trust them to know more about their compiler than you do.