gcc it is, undoubtly.
It may not always do the very fastest compiling, and it may not always be the top performer, granted.
However, it is unarguably the best general and portable compiler suite by design and philosophy.
First of all, a compiler should be correct, and then it should be optimized, as a correct compiler enables you to produce much better code in the end.
One of the major design failures in wxWindows in my opinion is that they use macros for everything and reimplement STL functionality with custom classes. The reason they state is "portability".
The real reason is templates *are* portable, and the STL *is* portable (well, 95%), only MSVC is utterly broken.
By using and supporting MSVC, you prove them correct and further the development of incorrect software. At the same time, you prevent others from writing correct code because they must take VC into account.
It is like designing a web page for Internet Explorer. If you "optimize" your web sites for Internet Explorer, then your markup is not only incorrect, it also encourages the production of web browsers which honour flashy features higher than security and standard compliance. And, more seriously, you penaltize those browsers that are actually correct, as these will not show the pages the way people expect them.
For this reason, and to honour the free time the gcc developers sacrifice to produce a really good product (which they give to the world for free), one should use gcc.
Call me a Hippie if you like, I don't mind (and yes, I use OpenGL, too)
Executable speed may be an issue for some, however, the really big difference in performance lies in entirely other things, anyway. The actual gains by using another compiler are rather small. Other things can easily make a difference of factor 2, 10, 100, or 1000, where compilers make a difference of 5%. Think of algorithm complexity, multiple API layers, cache misses, page faults, synchronous disk access... the compiler is really the smallest factor here.
Compile times, well, yes, gcc is somewhat slow. But you have to be fair and admit that at least some of this is due to precompilation. If you have gcc precompile your headers, your compile times are somewhat faster, too. Unluckily, the one thing that would benefit most from that is wx again, and wx throws up errors on precompilation.
Either way, most of my projects build in 20-40 seconds on gcc (without optimizations of course), and when only changing 1-2 files, it takes some 3-4 seconds, which is quite acceptable. What difference does it make if one single file compiles in 1.1 or 1.5 seconds.
If an optimized revision build takes 5-6 minutes, so what... you don't do that 50 times per day
As a sidenote, I am curious to see how things will change with gcc 4.0, as the optimizer has seen a major overhaul and the 4.0 version supports auto-vectorization (is there any other compiler supporting this?). The effect of auto-vectorization may be zero for many applications, but it may as well be a great benefit for anything that processes mid-size or large-size streams of data. As it happens, it may save me a lot of hand-coded SSE assembly (which the compiler possibly can do better, too).
