After 15 years programming in C++, I was surprised to discover today that throw in C++ is an expression rather than a statement. As a result, throw may be used as part of larger expressions.

int x = 5;
int y = x > 4 ? x : throw std::out_of_range;

The only use I’ve found for this — and in fact the speculative attempt by which I discovered it — is range checking within constructor initializer lists.

RangeChecked::RangeChecked(int x) :
    int_member(x > 0 ? x : throw std::out_of_range)
{
}

It’s academic what the type of a throw expression is, since it will never be returned, but for type-checking purposes the compiler seems to be happy to use it in place of any type.

This posting has been re-written from an earlier version which contained unnecessary complexity

Following on from my proposal on how to compiler BBC BASIC functions with variant return types, in response to Richard Russell’s compilation challenges, I’d like to move on to compiling BBC BASIC loop structures. Nonetheless, several readers have comments how useful even a compiler that did not support these features would be.

The claimed difficulty arises is because BBC BASIC maintains a stack at run-time for managing loop structures such as FOR..NEXT, REPEAT..UNTIL and WHILE..ENDWHILE. As the interpreter executes the program it presumably uses the instructions it encounters to manipulate this stack. They key point here is that the tokens listed above are not merely loop delimiters used by the parser, they are actually statements which modify the internal state of the interpreter.

The situation is further complicated by the quirky behaviour of the NEXT statement. First of all, the loop variable following the NEXT is optional. If it is omitted the next iteration of the FOR loop which is topmost on the stack (i.e. the inner-most loop) is executed. However, it is also possible to supply a comma-separated list of loop variables, for example NEXT i%,j%. This is equivalent to NEXT i% : NEXT j%.

Richard goes on to illustrate the point with a real-world example,

Here there are two NEXT I% statements; which gets used depends at run-time on the contents of the array. This is a real-world example (although the code could no doubt be written more elegantly).

DEF FNscan(A()) : LOCAL I%
FOR I% = 0 TO DIM(A(),1)
IF A(I%) = 0 THEN
I% = DIM(A(),1)
NEXT I%
= TRUE
ENDIF
REM Some more code here
NEXT I%
= FALSE

This time, I will use a different example, which is very similar in structure to Richard’s code, but which excludes the array, for the sake of clarity.

FOR i% = 1 TO 5
IF i% = 3 THEN
PRINT "Three!"
NEXT
ENDIF
PRINT "i% is ";i%
NEXT

Note there is one FOR statement and two NEXT statements, so it is not possible to pair them. I simply print the loop counter, or in one case print a different string and NEXT early.

Formatted like this we can see that the inner NEXT is exactly like the continue statement in C#.

for (int i = 1; i <= 5 ; ++i)
{
   if (i == 3)
   {
      Console.WriteLine("Three!");
      continue; // next
   }
   Console.WriteLine("i% is {0}", counter);
   continue; //next
}

So, we can do something isomorphic in C#, C# is compilable to CIL, ergo this particular BBC BASIC construct is compilable to C#. Obviously.

However, more nefarious constructs are possible in BBC BASIC, such as this:

FOR i% = 1 TO 5
FOR j% = 1 TO 5
PRINT "i% = ";i%,"j% = ";j%
NEXT i%

where we iterate on the outer loop, from ‘within’ the inner one. It may be possible to weed these out at compile time in simple cases such as this, and replace the FOR j%= 1 with a simple assignment. If not, its definitely possible to deal with it at run-time

The equivalent code using the C# a simple ForNext class I devised looks like this:

ForNext outer = new ForNext("i%", 1, 5, 1);
outer.execute(delegate(int counter)
        {
            ForNext inner = new ForNext("j%", 1, 5, 1);
            inner.execute(delegate(int counter2)
            {
                Console.WriteLine("i% = {0} j% = {1}", counter, counter2);
                ForNext.Next("i%");
            });
         });

For the run-time solution, I create a ForNext loop object, initialized with the counter name which is just a label and the start, end and step values. I then pass the loop body to the ForNext object as a C# anonymous delegate. NEXT statements are implemented as calls to the static method ForNext.Next() with an optional counter name.

When run, the code produces,

i% = 1     j% = 1
i% = 2     j% = 1
i% = 3     j% = 1
i% = 4     j% = 1
i% = 5     j% = 1

Of course, some machinery in the ForNext class is required to make this work. In this case we use the .NET exception handling machinery to manage the stack of FOR..NEXT loops on our behalf, calling ForNext.Next() exits the current iteration of the top-most loop on the stack and if necessary begins the next iteration.

class ForNext
{
    public delegate void Body(int counter);
    private string id;
    private int end;
    private int step;
    private int counter;

    private class NextException : System.Exception
    {
        public string id;

        public NextException(string id)
        {
            this.id = id;
        }

        public NextException() :
            this(null)
        {
        }
    }

    public ForNext(string id, int start, int end, int step)
    {
        this.id = id;
        this.counter = start;
        this.end   = end;
        this.step  = step;
    }

    public void execute(Body body)
    {
        while (counter <= end)
        {
            try
            {
                body(counter);
            }
            catch (NextException e)
            {
                if (e.id != null && e.id != this.id)
                {
                    throw;
                }
                counter += step;
            }
        }
    }

    public static void Next()
    {
        if (counter < end)
        {
            throw new NextException();
        }
    }

    public static void Next(string id)
    {
        if (counter < end)
        {
            throw new NextException(id);
        }
    }
}

Note how in this example we pass the loop counter label as ForNext.Next("i%").

Of course, relying on the .NET exception handling mechanism for all such loops in BBC BASIC would be overkill. The majority of FOR..NEXT constructs are must simpler than this. The challenge moves on to detecting the simple cases using static analysis of the program to be compiled, and generating normal loop code in these simple cases. We would only fall back to the mechanism described here when required, if multiple unlabelled NEXT statements are present. It remains to be seen how feasible detection of these cases will be.

Of course, in functional languages, explicit iteration structures such as FOR..NEXT need not be present at all, since all iteration is achieved through recursion, usually with tail-calls. Another feature invented in the functional language LISP and now commonly available in more sophisticated languages is the concept of continuations, which are basically “GOTOs with parameters”. Both exception handling, as used in this post, and other complex control structures can be implemented using continuations, as can all the iteration structures of BBC BASIC, even with mismatched FOR..NEXT statements, even when the NEXT statement is not labelled with a counter variable.

There’s an awful lot of C++ out there. As a industry we’ve been pumping out C++ code since we collectively jumped on the object orientation bandwagon in the early 1990s. There are large systems, each with millions of lines of code created entirely in C++. Every day thousands of hours are spent, at fantastic expense, finding memory leaks, wondering why pointers are dangling and waiting hours for our code to compile. And these are the major contibutory factors to the big C++ problem.

Productivity.

Or lack of it. You see, writing C++ is easy. Writing good C++ is hard. Of course it is possible to write solid C++ but the unfortunate truth is that the huge existing body of code is unlikely to be rebuilt around the good programming techniques facilitated by libraries such as Boost or Qt. We will continue on the long death-march down the road of ongoing mainentance.

So why do programmers continue to subject themselved to working in C++, and why do our managers not only think this is acceptable, but activly encourage it? Of course, there are many reasons, but two stand out. First of all, many developers value the performance of their code, over their personal productivity. The second is the perceived difficulty of learning a different programming language in which to create better code.

My experience is that developers display an almost unnatural obsession with the performance of their code. This need for high performance has become some sort of pseudo-requirement for new code in the mind of many developers. Performance is commonly cited as a reason for using C++ over and above some other language such as Java or Python. But rarely is it necessary; many developers are not aware of exactly how fast their code needs to be, or conversely how slow it can afford to be. In spite of the claim that performance is important, the overwhelming majority have never used profiling tools in order to truly improve performance in the few lines where it counts. Why is performance valued more highly than rapid producing something that works?

This attachment to performace presents a serious problem, since for most programming tasks it is possible to write faster solutions in C++ than is most other programming languages. Any other language is then almost always a notch down in performance, even though this in itself is usually irrelevant for the task at hand. Perl hackers have recognised this for years with ‘You can sometimes write faster code in C, but you can always write code faster in Perl’ – although I fully agree with the spirit of their statement I actually think Perl introduces its own set of syntactic productivity barriers.

So given these topsy-turvy circumstances we should expect managers to be challenging their developers. Our managers should be asking why we are using tools such as C++ which make it unnecessarily awkward and time-consuming to write reliable code, and which do nothing to prevent common categories of errors. They should be encouraging us to write in Python, Ruby or even C# which allow us to much more rapidly create something which works, and which will liekly require much less cumulative maintenance over the life of the software. Furthermore, developers should be volunteering to use these tools in droves since their own productivity will increase massively, which is surely good for their careers and employers, and they will spend less time with mind-numbing debugging.

Although there is certainly biodiversity in the programming language jungle, most developers choose only to sample one or two programming language fruits and usually these are usually very similar – more a case of oranges and lemons than apples and oranges. For example many developers may know C++ (from work) and Java (from college). This citric experience provides a limited perspective on programming solutions. I don’t believe that the best programmers ‘think in C++’ or ‘think in Python’, in spite of some excellent books with that moniker. The best developers – the superstars our teams depend on – ‘think in software’, some sort of well defined, but difficult to expess, higher-level concept of how software should be designed and implemented. These great hackers know several languages which exploit different paradigms – C++ (imperative, strong, static typing), Python (imperative, strong, dynamic typing), Haskell (functional, strong typing) – and they are comfortable with applying techniques from one language in another, for example, by writing reliable code in C++ by avoiding functions with side-effects. Learning languages is relatively easy within a given paradigm – for example a C++ programmer learning Python. Crossing paradigm boundaries can be more challenging I’m a C++ developer by trade and I still struggle with functional Haskell – largely through lack of practical experience. However, the majority or programmers know only one language well enough to apply it commercially, and more remarkably show little curiosity about what other programming languages could offer them.

So why all the fuss about multiple languages and the corporate obsession with C++ ?

I recently had the dubious honour of being asked to review some C++ code which both transformed XML recieved from a socket into standardized SOAP requests. I was asked for comments on how the code could be improved, or refactored. The original was unreliable, leaked memory, and hogged the CPU due to some dubious socket handling. I hacked around in the code for 15 minutes looking for easy opportunities for improvement; hoping to make an impression, or spot some neat refactoring that could be applied. I was struggling – the code was almost unreadable, with five different string representations (don’t ask) and multitudinous conversions between them. It was clear that this particular problem was indeed the proverbial nail being pounded by the proverbial C++ hammer. Nobody volunteers to do XML processing in C++ do they? When I encountered inhumane C++ SOAP bindings statically generated from WSDL files I knew I had seen enough. I wanted to recommend that the code be rewritten in something more suited to the problem at hand- in this case I though Python would be a much better fit to the problem with its nice XML processing and SOAP libraries.

I spend a few evenings trying to understand the intent of the original code and re-implementing it in Python – not line-by-line as that would have achieved nothing – but from a higher level perspective. The result? I had reduced 8000 lines of C++ down to around 800 lines of Python, and I had enjoyed myself to boot. This was the first time I had experienced the fabled 10:1 code reduction of working in Python in a non-trivial example. I was amazed. Surely I had missed some critical piece of functionality? But no, it was all there – and what’s more it nearly worked.

I presented my late-night efforts back to my colleague who had introduced me to the problematic C++ code initially. He responded enthusiastically. We spend a few days with him debugging, and me helping and hinting – a kind of pair programming separated by communicating only through Jabber and source control over the 300 kilometres of mountain and glacier that separated us. Within 36 hours and with some help from tcpdump, he had something that worked. We had slain the leaking, intransigent, C++ beast, and replaced it with a svelt Pythonic beauty.

And then he talked to his manager.

I wasn’t present, but I imagine the conversation went something like this:

Developer: “You know the SOAP agent we’ve been having trouble with?”

Manager: “Yeah – the one we need to fix and deploy by the end of next week?”

Developer: “Well, most of the problems are sorted, its no longer leaking memory and the socket communication is now far more reliable. In fact – I’m confident its now a quality product.”

Manager: “So what was the problem?”

Developer: “Well, we didn’t want to waste more time tracing leaks in the C++ version, so we recoded it in Python; now its 90% smaller, and far more robust. By the way, you know how the older version only worked on Windows? Well now it also works on our Linux, Solaris and Irix too!”

Manager: “We can’t use it.”

Developer: “The only catch is that we don’t have experience of deploying Python applications, so there might be some work to do on the installer, but this program is usually installed by sys-admins anyway, and we’re sure its solvable in the …”

Manager: “We can’t …”

Developer: “… Excuse me?”

Manager: “We don’t use Python here. We use C++. We can’t afford the overhead of developers needing to know more than one language.”

Ouch! So now the Python solution, which is a much better technical fit to the problem than the C++ behemoth is rejected because it is feared the cognitive load of learning a second language may be too high for some developers. Worse still, the hopes for our enthusiastic colleague becoming a topline developer are diminished, because rather than valuing diversity of programming language knowledge, the application of such abilities is frowned upon as ‘too costly’.

There is hope for Python, Ruby and other productive languages though to overturn the C++ monopoly in the realm of proprietary software, non web-based sofware. (Remember real applications?) But with developers on the one hand needlessly obsessing about which functions they should inline, or avoiding dynamic_cast completely because its slow, and on the other hand managers encouraging a language monoculture to protect their developers from having to learn something new, I think change will take an order of magnitude longer to achieve than we have seen in the FOSS world. Achieving escape velocity from the black hole of C++ productivity cannot be achieved without both main engine developer thrust and management boosters. Developers on the ground must accept that using a language slower than C++ can be a good thing, and managers need to permit a degree of linguistic diversity in the interests of multiplying the productivity of their teams.