Do you generally release separate version for each or just one version. If just one how do you best approach the differences between 32 and 64bit. As you can see I have never written a 64bit program and I am currently reading on the difference, different variable, memory, pointer rules and plenty more, although it's anything as complex as I expected.
How much can you use macros to separate the differences between the two?
I don't write separate code for the two. The only macros I ever use in production code are for include guards, working around compiler-specific bugs, and a couple of rare things (that I won't go into here). I certainly don't rely on macros to check variable sizes, for 32-bit versus 64-bit pointers, or anything like that.
I write code using techniques that eliminates where practical (or, if eliminating is not practical, minimises and isolates) any reliance on the size of variables, the size of pointers, the range of values a variable can hold, and things like that.
Such techniques include;
1) If storing the size of an object in a variable, ensure variable is of type size_t, not of type int, unsigned, unsigned long, or anything else. Similarly for array sizes.
2) If computing an offset between pointers, use a variable of type ptrdiff_t rather than an integral value to hold the difference.
3) In C++, use standard containers and their iterators wherever possible, rather than using raw arrays, pointers, linked lists, etc. There are some cases (before C++11) where it is necessary to use a raw array to initialise a container, but avoid these where possible.
4) Avoid using any explicit type conversions (C-style casts or C++ _cast operations) if at all possible.
5) If writing any code that relies on an assumption about the size or layout of any data type, search for some way to eliminate that assumption and make the code independent of such properties.
6) If introducing macros (compiler specific or programmer-selected) that are related to size or layout of some data type, treat it as an assumption about size of layout of the data type, and revert to point 5.
7) If using sizeof(), a pointer, or variables of type size_t or ptrdiff_t in any context other than when implementing an operator new() function (or, in C, when calling malloc()/calloc()/realloc()) or when printing out the value, then treat this as a special case of point 5.
8) Don't use bitwise operators to express numeric operations (since these generally introduce a reliance on size and layout of a basic type, and result in going back to point 5). Conversely, don't use numeric operations to emulate a bitwise operation.
9) Never optimise for efficiency without making use of a profiler (a large proportion of "premature optimisation" hacks rely on some assumption about size of layout of some data type).
10) Don't rely on signed integral types behaving rationally when overflowed or underflowed.
11) If breaking any of the preceding rules is necessary, isolate the offending code into a function. Name the function based on the effect it achieves, not on how it achieves it. Keep track of the number of such functions, and categorise them as problems in your design (i.e. keep them live as candidates for refactoring, elimination, avoiding calling, etc).
