As you may have noticed I had a kinda bad day yesterday and as a result of that was maybe a bit too harsh on Microsoft. I certainly don't want my blog to be a Microsoft bashing place. Although they work hard like no one else to give me plenty of reason to bash them ;-)
There are a few more notes that I'd like to add to my ranting on Microsoft's C++ iostreams bug. It seems that, ironically, the memory leak in VC++ 2005 is caused by the same bug that cost me four or five days of debugging. Now, those who have worked with Visual C++ know that the Microsoft C/C++ (debug) runtime library has a useful memory leak detection feature built in. While it doesn't tell you where the memory leak originates from, it nevertheless gives you a hint that there maybe something wrong with your memory management. Now, Microsoft (in a state of hubris?) decided to disable this leak detection feature for all memory allocations made from within the C++ standard library. Hadn't they done that, they could have easily found that bug during testing. Also, I have to ask why using a tool like Purify or BoundsChecker isn't standard practice in Microsoft's QA for the runtime libraries...
Posted by guenter at December 30, 2005 07:32 AMI really wished Microsoft would incorporate some better support for memory leak and memory corruption detection into Visual Studio (more than _CrtDumpMemoryLeaks() and _CrtSetBreakAlloc()). Compuware BoundsChecker is a cool product, but most C and C++ developers I know have never heard of it (nor have they heard of the above MS functions). In the Java world (where we have a managed heap) Borland decided to buy OptimizeIt and integrate it with JBuilder, so why can't Microsoft just buy or license BoundsChecker, or create some kind of tool support on their own? This would present a major step forward to improve application stability on their platform.
By the way, is there any good reason for C and conventional C++ projects to migrate to Visual Studio 2005 already? I mean Visual Studio 2003 resp. .NET 1.1 has only been viable since SP1 (and we don't plan to switch to Visual Studio 2005 for a while, as we cannot utilize .NET 2.0 yet), and we even stick with Visual Studio 6 (SP6) for C and C++ (rock solid).
And don't feel bad about maybe being too harsh this time - your previous comments have been well-tempered, not like the unsolicited Microsoft bashing I know from other people...
Some ranting at times is important for your own well-being. I was ranting about Lotus Notes on my blog one day, and some guys (folks from IBM maybe? ;-) ) flamed back that I was wrong, that I was using an outdated client and the like (not my choice, by the way). They surely are convinced they got a great product, and on the other hand I just know how much pain it has caused me. Writing about those experiences is a good thing, even if one runs the risk on stepping on someone's foot.
Posted by: Arno at December 30, 2005 01:58 PMArno, the only reason I could think of to be a justification to move to VS 2005 with conventional C++ is really powerful IntelliSense that may give you some productivity boost. They have integrated a compiler in the background and the thing will recognize pretty much everything including stl containers and drop down hierarhical member lists as you type. Debugger is significantly improved as well. But then, as you have seen there are some serious bugs lurking in MS standard library, so I'd say that's a good reason not to move yet. But hey, you've got a better debugger now ;-) Anyway, I will not move to production VS 2005 for a while, at least until after the first SP.
Posted by: Alex at December 30, 2005 03:09 PMAlex, thanks for your answer. I have already checked out Edit & Continue and Intellisense in VS 2005, but only on .NET projects. Sounds like worth taking a look as well on C and C++ projects.
Posted by: Arno at December 30, 2005 04:19 PM