Thought Leadership

C, C++ and the family tree

By Colin Walls

I am interested in programming languages in general and particularly as they apply to embedded systems programming. I have written about this topic before, but I wanted to revisit it and consider the issues from another angle. The most popular programming language for embedded continues to be C. Clearly it offers the capabilities and facilities that most developers need today, but what comes next? I think we can get some ideas by looking at the genealogy of C – where it comes from and how it relates to other languages …

The first programming was done in assembly language. Actually, that is not true – it was first done in binary. If you have never programmed a computer using switches and lights on the front, you are not a real software engineer. [No, I do not really believe that, but it is essential to understand conceptually what I just said.] For embedded applications, assembler continued to be very widely used until the 1990s, when various high level languages were tried: Pascal, Modular 2, Forth, PL/M and C to name a few. It was C that “won”. C is non-ideal, but satisfactory. I have considered its shortcomings on a previous occasion.

C originates with a language called BCPL, which was developed at Cambridge University in the mid-1960s. BCPL was designed to be a minimalist language – a kind of “high level assembler”. There were no data types – words of data were treated as integers or addresses as appropriate. Programs were written using a block structure which could be traced back to Algol, which is an even older language.

The B language was derived from BCPL, being even more stripped down to minimize memory utilization. It was used for one of the first UNIX implementations. In due course, developments in CPU architecture [notably the DEC PDP11] made the addition of data types to the language attractive. Thus, C was born and UNIX re-written using it.

For some years, the “standard” for the C language was as described in Kernighan in Ritchie’s book. Many compiler vendors extended and “improved” the language in various ways. A number of teams developed variants of C with object oriented capabilities: C with Objects, Objective C [still used in the Apple world] and C++. The last of these has been most successful and is the only one of the three found in embedded contexts.

The ANSI/ISO standard took many years to develop, as it sought to go beyond ratifying K&R C, but instead incorporated numerous extensions and a few features from C++. It got there in the end and is now probably the most widely used language variant, even though there have been more recent standards published [C99].

I suppose there are three current languages that own their origins to C:

  • C++, as I already mentioned, which is gaining ground in embedded.
  • C#, which is Microsoft proprietary and not really relevant to embedded systems other that Windows CE.
  • Java acquires many features and syntax from C and has a place in embedded systems, where user-installed “applications” are supported. But it is not feasible to implement an entire system in the language. For example, it lacks pointers, which are a critical feature.

C is at the heart of a family tree of languages and every embedded programmer should have at least a passing familiarity with it. I just wonder what will come next …


0 thoughts about “C, C++ and the family tree
  • I actually programmed in BCPL (long ago), I think its name was originally from “Bootstrap Cambridge Programming Language” – but they never got round to doing the CPL.

    I wouldn’t put Java in the same class as C/C++ myself. C/C++ have a platform dependent view of memory, Java is platform independent and uses garbage collection – it’s more like C#.

    As for what’s next: I’m working on an extensions to C++ to get direct compiler support for multithreading and parallel processing –

  • Kevin:

    I agree about Java. I was really alluding to the fact that it’s syntax came from the C language family.

    Interesting project for a multi-threading C++. Curious that it is being approached from the direction of HDLs [Verilog and VHDL] instead of software programming languages that have multi-threading capabilities [Ada and Java]. Not saying this is wrong, just interesting.

  • What will come next is already here and being sold by Mentor Graphics in the BridgePoint tool. Executable UML has been used for many years as an embedded systems programming language. A higher level of abstraction than C++ or Java with efficiencies comparable to C. Just waiting for support from more embedded developers for tool costs to decrease and understanding to increase.

  • Lee:
    I think you may well be right. I am quite familiar with xtUML and Bridgepoint and I am enthusiastic about what it can do. I have written a number of articles and done presentations about it. Although it has been available for a while, it has never quite reached the usage level that changes the world. Well, it hasn’t yet …

Leave a Reply

This article first appeared on the Siemens Digital Industries Software blog at