/* */ /* */

Friday, 12 October 2012

C++ development: a trip back to the 80's

When returning to C++ coding from some years of primarily C# coding it strikes me how poor and error prone the C++ tools are for building software compared to the C# equivalents.

Assisting functionality that I've taken for granted in IDE:s, most notably refactoring, is missing. Equally disturbing, and the primary topic of this post, is the fact that modularizing the code into different projects is a mess.

As an example, consider an application using logging. Logging is a reusable kind of functionality and I want to modularize it. In my application project I would just like to state that I have a dependency on a project called logger, and then have access to #include "logger.h" and get logger.a linked to my application. That should be a one drag-n-drop operation.

However, even in IDEs such as Xcode and Visual Studio I have to both both
  1. add a reference to the library project to get the linker to include logger.a and
  2. add a include directive to the path of the directory of the library source.
I think this is a significantly worse approach than the C#-way of just referencing the project and then being able to actually use it in the code, since it makes separating functionality into modules more error prone and tedious. For example, if absolute search paths are entered by mistake, the result will not be portable.

One reason is certainly that the C++ does not have a module system like C#, where both the usage info (the equivalent to the header files) and the compiled code are combined in one assembly. However, the C++ equivalent is the set of header files and the library files. There is no reason why the IDE:s cannot just add a hidden include to the header file directory of the library when a reference to a library project is added to an application project.

Anything less than having an IDE that automatically performs obvious, common, automatable, tedious and error prone steps is a nasty trip back to the 80's!?