is VC++ 2005 worth a shit?

Post by **junglist** » Mon Sep 12, 2005 8:20 am

It looks like they're offering it for free now (or maybe just the beta), but I don't want it if it's going to be bloatware.

http://lab.msdn.microsoft.com/express/v ... fault.aspx

Post by **torhu** » Mon Sep 12, 2005 8:52 am

The 'Express Edition' is free, but only the beta, which expires next year, I think. But the beta isn't ready enough for me to bother with it anyway. If you want a profiler, it seems you have to get the most expensive version, Team Edition. The express edition requires only 1.3 GB for a complete install, according to the web page. Can't remember what the actual space used was when I installed it.

For q3 development, I'll stick with VC++ 6.0. VC7 and 7.1 sucks for that, because there's no call browser. But 2005 has got that, so it looks to be very neat. But it probably eats up 10 GB of your precious HD space...

Post by **junglist** » Mon Sep 12, 2005 2:45 pm

thanks dude. i actually have VC++ 6 standard in a box, so i'll just use that. :icon14:

Post by **glossy** » Thu Sep 22, 2005 7:26 am

i got a free (educational) edition of the whole Visual Studio suite for simply entering a programming competition that i never produced any work for.

ace

Post by **zewulf** » Wed Sep 28, 2005 6:12 pm

Hmmm...a new version of VC++ :icon6:

I may give it a try just to see if they've finally fixed that FP bug I found almost 4 years ago...

Post by **^misantropia^** » Wed Sep 28, 2005 6:24 pm

Not to mention the extremely buggy MMX/SSE/3DNOW! intrinsics.

Post by **zewulf** » Thu Sep 29, 2005 3:43 pm

Finally gave it a try, and as expected, that FP bug is still there :icon13: I don't know if I should report it. I figure they probably know about it already but just never bother to fix it

I mean I've known about this bug since VC++ 6, and it's also present in VC++ .NET.

And what's with deprecating standard I/O routines like scanf, fopen, etc.? :icon6:

One interesting thing I found is that the VC++ 2005 generated executable is much smaller in size than the VC++ .NET generated executable, especially for the Release build. However, the runtime speed seems to be inversely proportional to this decrease in file size (i.e., the VC++ 2005 generated executable runs a lot slower and requires more memory to run)

Post by **AnthonyJa** » Thu Sep 29, 2005 5:27 pm

You've gotten me curious - what is this FP bug that you know about?

Post by **zewulf** » Thu Sep 29, 2005 6:33 pm

Below is the output of a program I wrote that demonstrates this bug:

Code: Select all


Double precision (64-bit) FP division bug in Visual C++

Hardware result is incorrect...

==============================================

Dividend (decimal) = +7.06932792557673790E-157
Divisor  (decimal) = -6.13288101671836090E+156
Dividend (hex)     = 0x1F83696BE07C9694
Divisor  (hex)     = 0xE07C96941F83696B

Result:
Hardware (decimal) = -1.15269282188160850E-313
Software (decimal) = -1.15269282193101500E-313
Hardware (hex)     = 0x800000056E9F2ED4
Software (hex)     = 0x800000056E9F2ED5

==============================================

Dividend (decimal) = +4.51268704717494800E-155
Divisor  (decimal) = -9.59942829634031540E+154
Dividend (hex)     = 0x1FE35C96E01CA369
Divisor  (hex)     = 0xE01CA3691FE35C96

Result:
Hardware (decimal) = -4.70099563001620400E-310
Software (decimal) = -4.70099563001615460E-310
Hardware (hex)     = 0x80005689A6E985E6
Software (hex)     = 0x80005689A6E985E5

==============================================

Dividend (decimal) = +6.49702735810724210E-155
Divisor  (decimal) = -6.74564033298548460E+154
Dividend (hex)     = 0x1FEBE01FE0141FE0
Divisor  (hex)     = 0xE0141FE01FEBE01F

Result:
Hardware (decimal) = -9.63144644154457230E-310
Software (decimal) = -9.63144644154452290E-310
Hardware (hex)     = 0x8000B14C9F2E3A22
Software (hex)     = 0x8000B14C9F2E3A21

I actually posted a similar program in general discussion about 2 years ago asking people to run it on their computers so that I could determine whether it was a hardware (i.e., FPU) bug or a compiler bug. Originally I thought it was probably a hardware bug, because this bug was non-existent when I compiled the program with GCC and ran it on a Sun Sparc system running Solaris. However, when other Q3Wers reported the bug on both Intel and AMD systems with the VC++ compile, I knew it was most likely a compiler bug. I then finally compiled the program with the Win32 version of GCC and ran it again on my Intel system, and the bug was gone.

I have yet to run the program through a debugger to see where it goes wrong. I suppose I will get to it someday

BTW, this bug occurs for the dividends from 0x1F83696BE07C9694 thru 0x1FEBE01FE0141FE0 divided by the divisors from 0xE07C96941F83696B thru 0xE0141FE01FEBE01F. This is just one range I found. I think there may be other ranges where this bug could occur.