接上面的文档

Deen

By Matthew Wilson
Matthew is a consultant for Synesis Software, as well as author of the STLSoft libraries and the upcoming Imperfect C++ (Addison-Wesley, 2004). He can be contacted at matthew@synesis .com.au or http://stlsoft.org/.
--------------------------------------------------------------------------------

Conclusion
Clearly, you cannot simply say compiler X is superior to all others. Most compilers are superior to others in one or more respects.

Borland is the fastest compiler, has good language support, and doesn't shame itself in any other regard. Though it's not one of my compilers of choice, it has value to contribute in its good warnings. However, it seems to share VC++'s predilection for internal compiler errors (ICEs) when things get too hard for it, which I find annoying.
For me, CodeWarrior is the last word in language rules, conformance, and error-message readability—and it is invoked whenever another compiler balks at something I've written that I think should be okay. Moreover, it has a good (though not great) IDDE, produces reasonably efficient code, and has support for all the popular libraries. It would be the compiler I'd chose if I could only have one.
Digital Mars comes off very well, featuring in the top three for language support, compile time, and execution speed. (It's about fourth on execution size.) For now, it is let down by nonstandard Standard Library support, the occasional ICE, and an outdated IDDE—but it's free and you get such good service from its developer that these things are forgivable.
GCC has the best language support, which is commensurate with its having the widest collaboration of any open-source (and probably commercial as well) compiler in the business. However, this may also account for its poor efficiency characteristics. On my tested scenarios, it proved to be the slowest compiler, and produced the slowest and fattest code. (This can be contrasted with Digital Mars, which is written and maintained by one person.)
For speed of generated code—which is often the most important factor—Intel reigns supreme. It does well on the size of generated code, although it is let down somewhat by compilation speed. It scores well on language issues, although getting it to listen to warning-suppression commands is sometimes a trial. It does not have any kind of IDDE, but plugs into Visual Studio (98 and .NET) without problems, other than that precompiled headers and browse information go to pot. I'm always surprised when I speak with clients who are writing performance-sensitive software in a Microsoft environment (Win32 systems, Visual Studio) and yet have not considered using the Intel compiler. It's definitely an essential part of a programmer's armory.
Visual C++ does better than I expected. It produces the smallest code, is quick to compile, and does well in the performance of generated code (though it's still way off Intel's performance). It also, finally, has good language support; VC++ 7.1 even discovered some typename qualification errors in the STLSoft libraries that CodeWarrior and GCC missed. And, in my opinion, it has the best IDDE by a country mile. It is/has been badly let down by poor language support (now impressively, though belatedly, addressed in Version 7.1), long update cycles (it was five years between Versions 6 and 7), ridiculous gigabyte install sizes, and by assumptions in the compiler and the IDDE that you will be using Microsoft extensions, MFC, and so on. Furthermore, there are too many ICEs for my liking (even one should be an embarrassment), which makes you question how much testing goes into it. Finally, WTL should be a fully supported part of Visual Studio.NET, wizards and all.
Watcom is poor on template support, which made it hard to give it a fair comparison with all the other compilers. It did well in the areas in which it featured, although Dhrystone performance was extremely poor. I hope it will continue to develop in its Open Watcom guise, and return to the glories that were Watcom C/C++ in the mid '90s.
All C++ professionals and organizations should use more than one C++ compiler at all times. No compiler provides all the possible useful warnings, so compiling with multiple compilers affords much more comprehensive coverage. Furthermore, there's nothing better for making your code port-prepared than making it work with more than one compiler. Particularly bad in this regard have been the Borland and Visual C++ compilers. Many times, I've built substantial projects that have worked well in one of these compilers, only to find in porting that I've done nonstandard things, and even had bugs. So, I would recommend that all C++ developers modify your work environments to incorporate three or four compilers; you'll find your code quality rises sharply. Given that many of these compilers are free—Borland 5.5(1), Digital Mars, GCC, Intel (for Linux), Watcom—it seems remiss to do otherwise.