Hi All.
ive now decided that i should start using the x64 architecture.
now i've lloked around a bit and found out that you are supposed to use INT_PTR, DWORD_PTR, ETC instead of INT, DWORD, ETC
and you should use the PTR version of windows functions when avaliable.
is there anything else i should know ?
are there any things i should avoid ?

and MSDN and other places say that _WIN64 is supposed to be defined for x64, but it is not for me; however _M_X64 is and _M_AMD64 is not.
why is _WIN64 not defined.

Thanks.

Hi All.
ive now decided that i should start using the x64 architecture.
now i've lloked around a bit and found out that you are supposed to use INT_PTR, DWORD_PTR, ETC instead of INT, DWORD, ETC
and you should use the PTR version of windows functions when avaliable.
is there anything else i should know ?
are there any things i should avoid ?

and MSDN and other places say that _WIN64 is supposed to be defined for x64, but it is not for me; however _M_X64 is and _M_AMD64 is not.
why is _WIN64 not defined.

Thanks.

Try to write your code as portable as possible and do not use these windows typedef's. All you have to do is remember, on a 64 bit build a pointer is sizeof(void*).
Keep your windows code confined to the window creation cpp file so the rest of your application is not pouted with windows only stuff -- this will make your life easier in the long run.
_WIN64 is automatically defined for you in your preprocessor define if you are using Visual Studio and you set your project to x64 build mode.
If it is not, then you are not using visual studio --and you should for windows development-- or you are not in a 64 bit build mode.

To create a 64 bit build mode in visual studio, open your project up. Highlight your project name in visual studio, right click goto properties. Click the button configuration manager (top right of the window that poped up).
Click the drop down menu "active solution platform". Select x64 and copy settings from win32. Press ok, then ok.
Now, you have a new build option that you can select. _Win64 should be defined as well as _M_X64.

There's a couple of categories of gotchas. First are the ones that apply when you don't actually need to play with 64-bit values. If you're doing int<->ptr conversions, then you are a bad person and probably going to programmer hell anyway, but take a look at that too. Unsafe use of unions is a related concern, now that ints and ptrs are different lengths.

from what i read INT_PRT will work be the correct byte size in the respective build configuration, right ?
and i would have used sizeof(int) for example.

The second category comes into play if you are actually going to have containers larger than 4 GB (actually, things get ugly around 2 GB too), or actually will use 64-bit arithmetic. You need to take a hard look at where you are using int and where you need to use size_t and ptrdiff_t and long long.

i dont fore-see myself using more then 4GB, but i would still like to have 64Bit compatible code.
what do you mean by ugly ?

The really, really important thing, though: Read <a href="http://www.codeproje...bit-Errors.aspx">this</a>. Over and over. Take it to bed with you. Make a song out of it. It's a great resource, but only if you memorize its patterns.

unfortunetly that link does not work for me

Now, you have a new build option that you can select. _Win64 should be defined as well as _M_X64.

_M_X64 is defined but the other is not.
and im using VS2010.

so this might be a bit over the top for me now then ?
i thought it would be better to haveing 64bit compatible code sooner rather then later, to ease any head aches.

Try to write your code as portable as possible and do not use these windows typedef's. All you have to do is remember, on a 64 bit build a pointer is sizeof(void*).
Keep your windows code confined to the window creation cpp file so the rest of your application is not pouted with windows only stuff -- this will make your life easier in the long run.

actually, ive been looking at makeing my DLL's cross platform but have not set out on this yet.
will my DLL work on Linux if it has DirectX code inside of it ?
do i have to make a seperate version for each platform or can i use the same DLL but with some #defines to have the correct code used per platform.

[quote name='Sneftel' timestamp='1308839710' post='4826805']
The really, really important thing, though: Read <a href="http://www.codeproje...bit-Errors.aspx">this</a>. Over and over. Take it to bed with you. Make a song out of it. It's a great resource, but only if you memorize its patterns.

unfortunetly that link does not work for me [/quote]
Fixed above.
[/quote]

Good Article +1