C/C++ Users Journal, January 2006
It is a truism that no good deed goes unpunished. One of the reasons for that, I've learned recently, is that opinions often vary as to what constitutes a good deed. No, this time I'm not on the receiving end of the missiles, though I've done my time on the dunking stool. The principal alleged perp here is that big software company that so many people love to hate, good ole Microsoft.
As I write this, the long-awaited Whidbey release, a.k.a. VC++ V8, is just going out the door. And it's chock full of new features, some of which I've described. One is C++/CLI, the new dialect of C++ that walks the fine line between conformance with Standard C++ and well-crafted extensions for the .NET environment. Another is the "Secure C" extensions to the C Library, a set of replacement functions that do better bounds checking than the Standard C Library. Still another is the optional iterator checking that comes with the latest Standard C++ Library from Dinkumware. Quite a lot of stuff, all in all. But much of that new stuff kinda gets in your face. Microsoft has chosen to ship V8 with all sorts of things turned on by default. You get iterator debugging, for instance, even though that can slow a program down quite a bit, and even though that option doesn't always meet the time complexity requirements of the C++ Standard. It's true that the iterator debugging logic turns up all sorts of errors that are otherwise really hard to find. We've had several years of experience with it, and both we and our customers find it an invaluable debugging aid. But mostly, it's something our customers want to turn on from time to time, not turn off to make production code. The compiler is also eager to warn you about every C function (and a few C++ functions as well) that Microsoft now deems unsafe. The warning messages tell you that certain functions are "deprecated," and strongly suggests that you ought to replace such calls with ones from, say, the Secure C Library. Now I happen to agree that this is a wise migration strategy for most serious software products. But "deprecated" is a term of art in the ISO Standards world, and the offending functions (in Microsoft's eyes) are by no means on the hit list for future elimination from the C and C++ Standards. You should not be surprised to learn that several members of the C++ Standards committee have taken exception to this approach to reeducating programmers. There are also objections to the raft of warning messages you now get from perfectly conforming code. This continues a trend that I've griped about for many years. Warnings are just some compiler writer's notion of good programming style. By definition, they have nothing to do with any failure to write conforming code. Dinkumware provides libraries used by hundreds of thousands of programmers, so we dare not issue code that produces any warning messages, lest they interfere with customers' shop standards or simply mask warnings generated by user code. We're not alone in this regard—quite a few shops require warning-free compilation for some nontrivial warning level. So all these added warnings impose a serious burden, and on customers who don't necessarily buy into their underlying philosophy in the first place. I emphasize that you can turn all this stuff off with just a compiler switch or two. I should also emphasize that Microsoft got lots of feedback from customers, during beta testing, who think this is the right sort of thing to do. And, knowing the principal instigators of this approach at Microsoft, I can testify that they all meant well. But I suspect that a few things are going to change with V8, and probably sooner rather than later. Microsoft is not the only compiler vendor who's gone preachy of late, however. I just recently found out that a package we'd prepared for the Mac no longer works. Seems we were (of necessity) relying on static links, and someone at Apple decided along the way that dynamic linking is the only way to fly. According to their latest developer docs, "Tying user binaries to the internal implementation of Mac OS X libraries and interfaces would limit our ability to update and enhance Mac OS X." That's fine, except for those of us who don't want those updates and enhancements to affect our product performance. Worse, they enforce the ban on static linking simply by removing a critical file, so you get a cryptic link-time diagnostic instead of a proper sermon. Sometimes, I wish people wouldn't do so many things for my own good. I'll pave my own road to hell, thank you.P.J. Plauger
Senior Contributing Editor
pjp@plauger.com