This is my second entry on Code::Blocks in the past couple of weeks. I had earlier commented on the release of the IDE but refrained myself to get too carried away and thus, purposefully, didn’t get into details at that time. The reason? Well, we all know how deceptive first impressions can be, especially about something like an IDE. IDEs can be complex beasts and it can take some time to work things out with them. However, Code::Blocks has been mostly easy to adapt to, at least for me. This in part due the fact that it mostly mirrors how Visual Studio works, and I work on that beast 98% of the time. So adapting to Code::Blocks was not too difficult except for minor differences.
First of all, Kudos to the Code::Blocks team. They have done a great job at bringing us this editor. It’s no mean feat, but they seemed to have pulled through all odds and that does indeed deserve a praise. It’s true I was eagerly waiting for the Code::Blocks release for some time now, and if you have been reading my blog, you will have seen me mention the IDE a couple of times before. To cut the long story short, I am lazy! I hate writing UI code and Code::Blocks (wxSmith) just does much work for you in that regard and yes, I always tend to use wxWidgets for most of my cross-platform UI projects. I wish this release could have come in a year earlier, when I was working on a C++ project which involved using wxWidgets for the UI, would have saved me a sh**t load of trouble.
Even though the IDE auto generates UI code, it’s surprisingly clean. Most editors will make a mess of code generation, but not so with C::B. The UI code is generated into pure C++ files (.h and .cpp) which you can continue editing like your normal text files provided you don’t insert code into the blocks C::B uses. Reminds me of the days I worked with Visual Studio 6.0 and MFC. If I am not mistaken VC++ 6.0 used a similar method for code generation. You can even move the code around and C::B is correctly recognize it, yes, provided the blocks are kept intact. A good thing is the fact that you can save the resources as .XRC files, which I tend to use extensively with wxPython. For me, Code::Blocks could very well become the de-facto editor while working with wxWidgets. To bad it doesn’t allow native Python support. That would have been great indeed.
So, besides having a good integration with a UI builder what more does C::B offer? Other than the fact that it can be used for UI development, can it be used for (, maybe other) serious C++ development? Yes it very much can be. All said, my main interest in IDE was not how easily you could build UI. My main interest was too see if C::B could be used for serious day-to-day development and how well it scales to full scale projects. There are several other IDEs that look equally impressive, until you actually try to get things done with them. So what’s the story with C::B? Does it live up to the standards of other professional IDEs? Well, besides some niggling quirks C::B seems to be pretty good for full scale projects. I always have a habit of building,
a hello world, a “hello notepad” project with any new UI library I encounter. It gives you a fair idea of the capabilities of the UI. I tried the same with C::B and was pretty happy with the overall experience.
Now for some issues I had with the IDE. First and probably the most annoying was the fact that short-cut key assignments are very different from other editors, at least the ones I use. Also the fact that the IDE doesn’t allow me to set shortcuts like Ctrl-F5 or Shift-F5 is somewhat of a hindrance to quick acclimatization to C::B. That’s one serious nag! The other thing I noticed was the fact that the debugger can get really slow on Linux systems, though I must say it happened only twice for me and is not a frequent occurrence. On Windows the Visual Studio 9.0 directories got messed up when I installed VC 9.0 after I had installed C::B. C::B doesn’t pick up the VC 9.0 directories when you upgrade or remove older express versions. Not a problem though, I did managed to manually set them in the Options section. The debugger is not as extensive as others, but I guess you can generally live with that by adding “watches”. Most other issues, or for the matter of fact even these are rather trivial, I suppose.
OK then, how does the IDE handle projects across platforms? I found almost no trouble porting applications across platforms, at least no issues that were IDE centric. But then again my sample application was not entirely that extensive. Even then it’s worth a mention that after having been setup right, the project written under Linux compiled without a single major change on windows. No mucking around with Makefiles or build systems. Yes, it’s true I programmed for compatibility but still, all I really had to do was switch the compiler settings (for VC 9.0) thats all.
So can C::B be used for production quality projects? I would have to answer “yes” to that question. It definitely is good enough to be used for production code and if you are working with wxWidgets, I would even go so far as recommending this IDE over others. True it is not as powerful as Visual Studio, at least yet, but it still deserves more than a praise. For C++ development under Linux, I would recommend this IDE hands down, period!