The problem with C++

The biggest problem of software development is reuse: how to reuse software composed in the past, how to avoid to recreate the same code for every application.

Every developer knows that in C/C++ the software reuse is obtained through libraries: if you want to reuse a piece of software you have to create a library with it.

The C++ programming language on the other hand does not define a standard for making libraries or modules that can be reused without being recompiled each time.

The limits of available IDEs

Most of the commercial Integrated Development Environment for C++ are focused on source code editing and debugging, and building single modules, but C++ projects grow and they become composed by many modules or components, and the IDEs don't have functions to handle multiple modules in an easy and robust way.

A typical IDE for C/C++ provides a source code editor linked to a build system. A developer writes some code then compiles it, looks at the error or warning messages, and then changes the code and repeat the cycle many times until all errors are cleared.

This is very useful indeed, and it is usually quite fast. In addition the best IDEs provide contextual information while typing in the source code editor, like lists of function and variable names and so on.

The problems actually begin when this phase of the software development process has finished, when the source code is almost correct but there is a huge number of source code files that have to be compiled and linked together to create the binary files of the product.

For small projects the typical IDE is very good, but for large projects the limits of the compile - edit - compile cycle become evident.

When the project grows the developers need to split it in several smaller subprojects, and there are many ways to do this.

When the project has been splitted in smaller projects that can be compiled separately then the typical IDE would have a separated project file for each subproject, and the compiler's options are written in each if them.

This is a problem if we want to change a compiler option for all the subprojects. The IDE usually doesn't provide effective ways to do this.

Then the development team decides to have two or more versions of the product. The different versions may be for different platforms, or they may be just variations of the product output form. Usually the different versions are made from the same set of source code files but with different compiler options. This adds another bunch of separate subprojects to maintain.

In practice creating libraries is often a problem because the IDE in commerce, or even the free ones, require a separate project for each library, or do not provide a way to handle a collection of libraries.

For example the Microsoft IDE has step-by-step procedures to create the project files for a library but it is difficult to have two versions of the library in the same project, one for making a DLL and one for making a static library.

Often the details of the projects that make libraries are confused and repeated for every single library.

These problems often discourage developers and teams in using C++ for large applications, but with the right source code organization and the right build system all these problems are solved and the way to building large C++ applications or large sets of libraries is open.

The search for existing solutions

Of course we have searched the Web for existing build systems that would provide solutions to these problems, but we have not been satisfied by any of them, even if some solutions are really good.

We looked at the Eclipse IDE. It is a very big development environment, that supports many programming languages other than Java, which it has been created for, but the C++ support is based upon the old "make" with the horrible and awkward "makefiles".

Dev C++ is another typical IDE for C++, it works pretty well but it doesn't have the support for multiple projects in the same workspace.

CodeBlocks is a recent Open Source IDE which doesn't use makefiles. The fact that it is Open Source suggested to us that we could possibly use it and extend it, but, like many Open Source projects, the source code of CodeBlocks is not enough well designed and organized.

Then we looked at other build systems without a typical IDE, after all there are many source code editors that can be used to edit the source files and then invoke the build system in some way.

The first chosen was Ant. The project files of Ant are in simple XML, that is good, but the Ant package uses the make tools to compile C++, and so we finally discarded it.

The Scons build system is written in Python and its project files are Python programs themselves. This provides a flexible and power syntax for the project files, but we don't want to use a program as project file. First we found that using another programming language is distracting. But we also think that the project file should be a description of something, not a program itself. Yes, a program has apparently more capabilities than a data structure, but most of the things that can be done with control statements are also easily described in terms of passive data, and data is always simpler to understand and remember.

Read about our design.