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.
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
> 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/
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.
As someone who has been stepping away from C/C++ code towards Go, I'll add this for anyone in a similar boat:
When interfacing C (via CGO) or C++ (via SWIG) code with Go code the #1 thing to keep in mind with 64-bitness is that int in Go may be either 32-bit or 64-bit depending upon the GOARCH the compiler is targeting. int on the C/C++ side is virtually always 32-bit, even on a 64-bit compiler. Use int32 on the Go side to match int on the C/C++ side if you need your structs to align correctly when passing data back and forth.