Skip to content

Ten Code::Blocks Tips

December 7, 2012

Introduction

With the release of Code::Blocks 12.11, I thought this might be a good moment to share some tips about using this FOSS C++ IDE. The following is a list of ten things that I think it important for new Code::Blocks users to know about, specifically for those using the IDE on MS Windows, though many tips will also apply to Linux users. Please note that I have no connection to the Code::Blocks project, other than that I have submitted the odd patch and bug report, and that I like the product.

#1 – Install in a directory without spaces in its path

Like many FOSS tools, Code::Blocks (and the TDM GCC compiler) have a lot of Unix baggage. And one thing that Unix programs don’t like is dealing with file paths containing space characters. To avoid hard-to-diagnose problems, I always install both Code::Blocks and TDM GCC in directories without spaces in their paths. In fact, I install all my development tools in such directories – I have a directory called C:\prog, and I create sub-directories off this for each tool.  Similarly, avoiding project names and project directories that contain spaces and/or non-ASCII characters, such as accented ones, is also a good idea.

#2 – Create a project, and choose the right kind of project

Like most modern IDEs, Code::Blocks is project-based. Although you can compile single files outside a project, you will have problems if you take this approach (specifically, you won’t be able to use the Code::Blocks debugger) – so don’t do it! And make sure you create the right kind of project. If you are just starting out with C++, you almost certainly want to create a Console application:

cb-console

#3 – Increase the compiler’s warning level

By default, the GCC compiler compiles code at very low warning levels, and will actually let all sorts of dubious stuff get past without warning about it. You can easily increase the warning level, and I’d recommend doing this globally. Go to the Settings menu, and choose Compiler… Then, in the dialog that appears, select the following warnings:

cb-warnflags

There are other flags you can set, but these two are the most important. You may be surprised by the number of warnings your code generates after you enable these. All are important, and all should be fixed – good code compiles with zero warnings. 

#4 – Increase the number of compiler processes

If your PC’s CPU has more than one core (and what doesn’t these days?) then it is worth increasing the number of processes that the IDE will use to run the compiler to match the number of cores. This can give a very worthwhile speed-up (I got about 30%) when compiling multi-file projects. To do this, go to the Settings menu and choose Compiler… and then select Build Options in the tabbed dialog that appears, and increase the number of processes:

cb-cthreads

#5 – Turn on HTML logging

As with any complex piece of software, things can go wrong with Code::Blocks and the compiler. when it does, you need to see exactly what the compiler, linker etc. have been up to. The best way to do this is to enable HTML logging (via the same dialog as in the tip above):

cb-log

Once you have done this, every compilation will be logged to a file in HTML format that you can read or post as part of a question on the Code:;Blocks support groups.

#6 – Add commonly used directories to your search paths

If you use libraries like Boost a lot, it’s a good idea to add them once via the Settings|Compiler… dialog rather than having to set them up on a per-project basis. You can set them using the dialog’s Search Directories path:

cb-search

The Compiler tab contains the directories to be searched for header files, and the Linker tab the directories to be searched for libraries. Note there is no need to specify the TDM GCC header or library directories as these will be searched by default.

#7 – Use the Tools menu

Code:;Blocks allows you to integrate your own and third-party tools into the IDE, either by writing plug-ins, or more simply by using the Tools (and/or Tools++) menu. Here’s my own tools menu:

cb-toold 

You add to the tools menu by using the Configure tools… option at the bottom of the menu. This pops up a dialog that allows you to add new tools or edit or delete existing ones. The dialog is quite self-explanatory, but it’s worth pointing out the macros that are available which allow you to specify things like the name of the currently active source code file. For example, this dialog shows the configuration for the Hg Diff File command, which runs a Mercurial DVCS diff on the current file:

cb-toolcfg

#8 – Customise the keyboard, use the right-button menu

Most commonly-used commands in Code::Blocks have keyboard shortcuts, but these are often not exactly what you would want them to be. For example, I really hate having to use function keys for anything, particularly the tiny function keys on my laptop! So I quite heavily customise the keyboard shortcuts. To do this, go to the Settings menu and then select Editor, and Keyboard Shortcuts from the list on the left hand-side of the dialog.

One often overlooked feature of Code::Blocks is the powerful set of facilities provided by the editor’s right-button menu.. Using this you can browse through your source code for selected symbols, flip between header an implementation file (I recommend setting up a keyboard shortcut for this – it’s incredibly useful), split the editor window as much as you want and even perform some limited refactoring (hopefully this will get increased functionality as time goes on).

#9 – Keep up to date via nightly builds

The Code:;Blocks IDE is under continual and quite rapid development, and actual "official" releases often lag a long way behind. To get the latest goodies and bug-fixes, you need to track the so-called "nightly builds" which are compiled snapshots of the currently active development. People seem a bit put off using these, but they are actually mostly very stable, and often fix problems in the "official" releases – I’ve been using them for years with no problems, and using them is recommended by the Code::Blocks developers. You can check the current status of these builds in this support forum. It’s also worth keeping an eye on the TDM home page for updates of the GCC compiler, though these don’t happen all that often.

#10 – Use the Code::Blocks support forums properly

As well as the forum for nightly builds mentioned above, there are a number of other technical support forums on the Code::Blocks website. these are the place to as technical questions, but please, only questions about the Code::Blocks IDE. Questions about the C and C++ language, about linker and compiler errors, about installing third-party software etc. should be asked elsewhere, such as on Stack Overflow and/or Reddit. The basic rule is if you have a problem, try running the compiler from the command line, not from the IDE  – if the problem persists, it’s not a Code::Blocks issue.

Conclusion

The above are my most important tips for using Code::Blocks, but its a complex piece of software, and has lots of features that I haven’t covered. You should not be afraid to experiment with it on your own account!

Advertisements

From → c++, devtools, foss, top 10, windows

Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: