3 Jul
2012
3 Jul
'12
1:22 p.m.
On Jul 3, 2012, at 2:38 PM, Richard wrote:
In article <0F2F7083-54E8-49C2-A5EC-308F30C91BB9 at gmail.com>,
David Riley <fraveydank at gmail.com> writes:
In fact, I said both (look above). What I did *not* mean to do was
imply that MSVC did not have ptrdiff_t, something of which I had no
idea and about which I had nothing to say. In retrospect, my
statement was worded rather poorly, so apologies for that.
[...] That's why we have ptrdiff_t.
stdint.h is your friend, and anyone not implementing it (*cough*
MSVC *cough*) is not.
ptrdiff_t has been in MSVC for a long time.
In a private reply, David indicated that he meant to say <stdint.h>
instead of ptrdiff_t. <stdint.h> is not present in VS2008, but is
present in VS2010. However, ptrdiff_t doesn't come from
<stdint.h>, it comes from
<stddef.h>, which is present in VS2008, and although I don't have them
installed, I suspect that it was present in MSVC going all the way
back to VC6, which is about 15 years old at this point.
I don't mind people picking on the standards compliance of a C++
compiler, but you should at least be accurate when you complain about
it or imply that it doesn't support something.
Microsoft's compiler has been getting better with each and every release
and hasn't ever been "bad" in my opinion. (Anyone who asserts that
they should support 100% of the standard in the first release hasn't
been reading the standard.) gcc/g++ doesn't support all of the current
(or previous) ISO standards for C++ either.
I more or less agree; VS2008 was the first one I used that didn't
drive me absolutely batty from a standards point of view. 2010 is
theoretically much better, but I haven't had much cause to do much
Windows programming recently, and the last time I did, some
critical components I was using (specifically, CUDA and OpenCL
support from ATI) didn't support VS2010 without major patching. I
shouldn't imagine it's gotten any worse.
My chief issue with MSVC from a standards point of view has almost
always been the lack of stdint.h, which I use quite a lot. It's
easy enough to drop in a hand-rolled replacement, since Microsoft
has gone to great pains to make sure that nothing is changing
(even to the point of making "long" 32-bit on 64-bit architectures
because there's so much crappy code kicking around blindly
assuming that "long" is 32 bits), but I still feel uncomfortable
not having that from the compiler vendor. I'm glad to hear that's
been rectified; if I ever get the time to do game programming
again, I'll be glad to see what else has improved.
- Dave