vcvarsall.bat amd64Oddly the x64 compiler is still in "c:\program files (x86)" , not "c:\program files" where it's supposed to be. Also there's this "x86_amd64" thing, I was like "WTF is that?" , it's the cross-compiler to build x64 apps from x86 machines.
amd64 is a synonym for x64. IA64 is Itanium.
The actual "CL" command line to build x64 vs x86 can stay unchanged I think (not sure about this yet). For example you still link shell32.lib , and you still define "WIN32".
Another nasty case where 64 bit bytes your ass is in the old printf non-typed varargs problem. If you use cblib/safeprintf this shouldn't be too bad. Fucking printf formatting for 64 bit ints is not standardized. One nice thing on MSVC is you can use "%Id" for size_t sized things, so it switches between 32 and 64. For real 64 bit use "%I64d" (on MSVC anyway).
size_t really fucking annoys me because it's unsigned. When I do a strlen() I almost always want that to go into a signed int because I'm moving counters around that might go negative. So I either have to cast or I get tons of warnings. Really fucking annoying. So I use my own strlen32 and anyone who thinks I will call strlen on a string greater than 2 GB is smoking some crack.
Here are the MSC vers :
MSVC++ 9.0 _MSC_VER = 1500 MSVC++ 8.0 _MSC_VER = 1400 MSVC++ 7.1 _MSC_VER = 1310 MSVC++ 7.0 _MSC_VER = 1300 MSVC++ 6.0 _MSC_VER = 1200 MSVC++ 5.0 _MSC_VER = 1100Some important revs : "volatile" changes meaning in ver 1400 ; most of the intrinsics show up in 1300 but more show up in 1400. Template standard compliance changes dramatically in 1400.
I think x64 cl is in the right place, the compiler is still a 32 bit app, it just cross-compiles to x64.
ReplyDelete"I think x64 cl is in the right place, the compiler is still a 32 bit app, it just cross-compiles to x64. "
ReplyDeleteI don't think so. The one in x86_amd64 is a cross-compiler. The one in "amd64" is native 64 bit.
Unsigned integers are wrong for just about anything except if you're doing bit operations.
ReplyDeleteMy go-to demonstration of this is what happens when someone gives you an unsigned N and you want to do a for loop. for(uint x=0; x < N; ++x) does what you want for increasing, but for decreasing, for(uint x=N-1; x >= 0; --x) does not, instead you have to do crap with postdecrements in the comparison or something.
Which means you really want the loop index to be signed, which means you really want the variables you're comparing it to or initializing it from to be signed.
ReplyDeletewhat about this?
ReplyDeletefor(uint x=N-1; x < N; --x)
one of the nice things about unsigned variables is that when the valid range is [0, N] you only have to do one comparison to check whether the value is inside.