GCC for the Visually C++ Impaired

At this years ACCU conference Steve Love gave a talk titled Why Portable Code?. It covered far more than just toolchains and platforms, but it reminded me of a previous chat I had with Steve about portability after one of the recent ACCU London gatherings. I've always liked the idea of writing truly portable code, but quite frankly in the corporate waters where I swim Visual C++ is The Big Fish and any ideas about using alternate toolchains to satisfy personal desires around "writing quality code" would be seen as frivolous - irrespective of whether it has long term benefits or not.

In my discussion with Steve I explained that I hadn't even looked at a Makefile in a long time (according to my personal SourceSafe repository it's 1997) and I didn't feel that I could introduce any other build system just to enable portability checks. What I wanted initially was a quick way of taking a C++ codebase and just running it through A.N. Other compiler. It wouldn't have to link or run, just allow me to check compilation. Steve's suggestion was Code::Blocks, an Open Source, cross platform IDE, that was obviously also free. It turned out to be much better than I had hoped for and has also given me a partial answer to my previous blog 'Where Are the "Lite" Editions of Static Code Analysis Tools?'.

As you can see from my earlier post 'Building Visual C++ Projects From the Command Line', I am not adverse to command line tools, but the thought of trying to use another toolchain, especially one with a Unix heritage like GCC, didn't exactly fill me with joy. The last time I had used G++ was on a twin-floppy Atari STE circa 1990 and it needed a Unix like OS to run it. Googling didn't fill me with any more confidence as I started to read about Unix emulation layers like Cygwin and I didn't want to have to learn another 'Shell' - I just wanted to be able to run the compiler from a Windows command prompt. The answer again turned out to be pretty simple - MinGW - a Win32 port of GCC for building Windows applications. Feeling cocky I also downloaded the Digital Mars C/C++ compiler as well after noticing support for it in the Code::Blocks UI.

Now, I only wanted the IDE for the build system, not the text editor. So I created a simple Hello World C++ console application in Visual C++ and then switched to Code::Blocks to see if I could get it to build. After hunting though the menus I discovered how to configure a toolchain (it had detected VS2005 Express automatically, but not my VS2003 Professional) and noticed that it had an option to import a Visual Studio Solution or Visual C++ Project. I picked the former and played around in the UI to see what it had done. Amazingly I hit build and it worked... and ran too! I discovered how you switch compilers on a project and pointed it to my MinGW 3.4.5 installation and lo-and-behold it also worked (except for some warnings about unknown compiler switches which is an artifact of switching tools). I tried the Digital Mars compiler, after also downloading STLport, and it compiled, but didn't link (I discovered later that I had to specify the stlport .lib manually). I then got hold of the MinGW 4.4.0 release, but now it all went horribly wrong. However that was entirely my fault due to a lack of RTFM'ing the release notes. It was actually a blessing as I discovered the TDM GCC builds as an alternative to MinGW and it's "On-Demand Installer" worked out-of-the-box and better suits a heathen like me.

With my new found confidence I decided to take my Core library, which is the more platform agnostic part of my framework and give it a whirl with GCC 3.4.5 (I didn't have 4.4.0 working at that point). Once again I used the import feature of Code::Blocks to configure the build and it complained quite loudly at my code, which I kind of expected :-) But all the problems were quite simple and related to my use of Visual C++ specific #pragma's in the common build configuration header files. Once these were fixed the rest of the code was pretty sound - with GCC 3.4.5 that is. GCC 4.4.0 being much newer and stricter had a LOT more to say! I am going to blog about the changes I made because I was pleasantly surprised at how little I needed to change on the structural front to enable GCC support, but also the kinds of issues 4.4.0 has raised are squarely in the Static Analysis arena and not reported by any version of Visual C++ up to 9.0 (i.e. VS2008).

I feel somewhat annoyed that it has taken me so long to truly see the light. In Steve Love's talk he identified three stereotypes - The Ignorant, The Skeptic & The Zealot. I don't believe I'm any single one of those, as I've always agreed with the principle, but I probably share traits from all of them and add in a dose of procrastination for good measure. As I write this I'm just finishing up porting the oldest part of my framework, my Windows Class Library, and as soon as that is done I'll write some posts about the discoveries I've made.