"I think x64 cl is in the right place, the compiler is still a 32 bit app, it just cross-compiles to x64. "
I don't think so. The one in x86_amd64 is a cross-compiler. The one in "amd64" is native 64 bit.
June 4, 2010 at 9:37 PM
Anonymous said...
Unsigned integers are wrong for just about anything except if you're doing bit operations.
My 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.
June 6, 2010 at 12:18 AM
Anonymous said...
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.
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.
June 6, 2010 at 10:50 AM
To build x64 on the command line, use
vcvarsall.bat amd64
Oddly 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 = 1100
Some 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.
"06-02-10 - Some random Win64 junk"
6 Comments -
I think x64 cl is in the right place, the compiler is still a 32 bit app, it just cross-compiles to x64.
June 4, 2010 at 6:03 PM
(And agreed that size_t unsigned is super fucking annoying)
June 4, 2010 at 6:06 PM
"I think x64 cl is in the right place, the compiler is still a 32 bit app, it just cross-compiles to x64. "
I don't think so. The one in x86_amd64 is a cross-compiler. The one in "amd64" is native 64 bit.
June 4, 2010 at 9:37 PM
Unsigned integers are wrong for just about anything except if you're doing bit operations.
My 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.
June 6, 2010 at 12:18 AM
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.
June 6, 2010 at 12:19 AM
what about this?
for(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.
June 6, 2010 at 10:50 AM