C++ revisited

02 January 2010
C++ was a language that I first seriously used back in 2000 and used for a few project around the time. However this was in the days when C++ had serious issues with lack of standardisation, and eventually uncertainty over portability was a killer. Since the only C++ specific feature I was really interested in was function encapsulation, I concluded I would be better off adapting my C++ programming style to C, rather than learning all the ins-and-outs of C++.

In more recent years it became apparent that different people have different ideas about what constitutes "C++ programming"; this included everything from purely C code in a .cpp file, to full use of IO-streams, templates, & overloading. For consistency in use, Java seemed a better alternative.

For various reasons, I recently decided to make a serious effort to get back into the language. Considering how much I had nailed C down, it made more sense consolidating on C/C++ rather than Java or Python. The language has certainly moved on from when I last seriously looked at it..

Passing objects by value

This takes some getting used to, and is something of a gotcha when using temporary variables with code like:

vector list; while( ... ) { ... switch ( ... ) { case MyClass:myCase: MyClass mc = makeAnObj( ... ); list.push_back( mc ); ... } }

In practical C it's malloc() & pointers all the way, and Java passes (or rather, returns) by reference. Use of temporary variables helps split up what would otherwise be long lines, but it does seem (at first at least) counter-intuitive that you have to have a constructor for an object variable that is going to immediately get overwritten.

Namespaces

Nice idea, but seems redundant. Associating functions and constant with classes already solves most of the problem of namespace pollution, and in practice namespaces is an unnecessary extra layer of subdivision. It is supposed to be an ideal solution for when a program uses multiple third-party libraries, but C++ bindings that actually make use of namespaces seem few and far between.

Headers declaration

Not a major issue, but I suspect having/omitting the “.h” extension switches on/off some legacy support flags.

Templates

These seems to have borrowed quite heavily from Haskell's type classes, so it was no surprise when I came across a paper comparing them. So far the amount of generality seems somewhat overboard, but the standard template library means that (at least syntactically) some things like lists are more-or-less built-in features.

Odd (and very long) error messages

One downside is that errors involving templates are very long-winded, as the type identifier includes template parameters complete with expanded namespace path. To muddy the water even more it seems a lot of built-ins form a hierarchy, and error messages refer to the base class/template. Since I was typically getting these errors due to missing headers, it takes a lot of reading (and sometimes guesswork) to see which header is actually missing. This becomes even more infuriating when compiling via Windows' command prompt, which does not provide much output scrolling.

On the plus side, you can get output simplifiers..

Calling of superclass constructor

In Python (and in Java) when you derive a sub-class, there is flexibility on where the superclass's constructor is called. For instance:

class MainWindow(wx.Frame): def __init__(self): style = wx.DEFAULT_FRAME_STYLE ^ (wx.RESIZE_BORDER|wx.MAXIMIZE_BOX) wx.Frame.__init__(self,None,-1, "LyteCFG", (-1,-1), (620,480), style)

In C++, the function call to the superclass constructor has to appear before the function body, which limits what can be used as superclass constructor parameters. To see how this will be a problem, suppose style above was instead a table, possibly containing values calculated at runtime.