why are you choosing to use it when gcc and msvc are free?
i´ve just tested both and they failed in certain areas:
-not sure about the code generation but 100% sure about the compilation speed…
slower than death and umbearable (10 to 20 times slower than msvc6)
that surprises me because a compiler that was made to build several times the linux enormous packages should be built on speed compiling too, i can imagine the poor linux developers/users having to recompile the system all the time.
there are some techniques to supposedly “try” to speed up the mingw and one that got my attention is to install the ultimate++ app just to snatch the linker ld.exe and the archiver ar.exe to speed up gcc… just tried it… it doesnt work outside ultimate++.
the guys at ultimate++ obviously got ultra bored at mingw and made their own custom modules, but outside ultimate++ those generate lots of errors.
horribly patched installation but at least it doesn´t craaaaaaaaawwwwwllllll like the 2003 and 2005 versions. and they try to push the .net framework along just to make the developer even more dependent on their own complex way of doing a gui.
the first important point here is to get AWAY from MFC and get CLOSER to a different option like JUCE and by using m$ compilers, of course they want to push all this garbage along with the compiler.
after msvc6 they just tried to make a “cuter” environment at the cost of development speed and compiling.
and finally m$ never got the guts to add full support in msvc6 for giving a SINGLE package contaning the tools for developing aplications the version 6 so you have to do lots of patches that at the end create a lousy development environment. (processor pack, sdk, service packs…)
ridiculously enough, msvc6 does not upgrades the include *.h files to be at least compatible with win2000 so you have to do both the sp6 and the sdk.
worse than that when you install the sdk for at least give compatibility to win2000 (my os of choice, stable faster and acceptable size) it creates duplicated include file folder instead of correctly patching the include folder inside vs98 include folder.
they also recommend to put sdk include directory on top of msvc include and to keep both which is absurd because allows the compiler to recall vs98 headers when it doesn´t find sdk headers giving a lot of compilation headaches.
for the service packs the processor pack stoppet at sp5 so if you try to put sp6 it refuses to install and when dealing with core gui libs it is important to have good processor support to use fast instructions for screen management (mmx sse sse2)
due to those separate packs (sdk, sp5, sp6, processor pack) all the code that is found on the net compiles for some non standard combination of those.
in this matter mingw receives a 10+ note because they ignored all those “packs” and made their own updated winapi, so with a very small 40meg pack you get standard support that otherwise with msvc would require 1gig of packages to have the same functionality, if mingw was faster on compilation it would be absolutely perfect.
i´m tempted to use msvc6 because even with the monstrous amount of packages it compiles fast and i like to do small adjustments on the code and recompile a lot of times, but as soon mingw/gcc compiles faster than msvc i will switch to it and retire msvc forever.
there is one small but important detail that i´ve checked that msvc6 does that i know that borland doesn´t.
it allows inline asm procedures without stackframe.
those are functions that are full asm like:
when this gets called in the middle of the code it does´nt generate a call along with a push bp mov bp,sp and ret inside the function.
it adds the code directly inside main code (forbidden in borland)
this is risky but when properly used in functions that are called a lot it provides an imense speedup.
if you use this technique in a putpixel function for example it will fly.
And this core optimization in root functions affect all the other parent functions.
that´s exactly what watcom makes, insert asm code directly in the body of other code.
i remember to this day that when i used this technique to modify the putpixel in the graph svga unit in the old borland pascal days, it was speeded up by a factor of 8000%!!! (also doing some trick to avoid the MUL instruction using a lookup table) so all the other line, rectangle etc were benefited.
this is why i think watcom deserves a try because it may compensate those aspects of gcc and msvc.
if you try to use it, chances are that JUCE will run faster than gcc or msvc and the use of it for developers will be easier not having to install msvc complex packages or waiting for gcc to compile.