Technorama

It's interesting to see our programming languages evolve, C++ is one of my favourites because it is so flexible for programming performance critical real-time apps like video games -- you really need to get as close to the metal as you can for speed, while the OO approach helps with modularity.

The question is how to improve our lot from what we have at present? I would like to see some compiler and developer environment improvements:

• Developer environments checking code as we type, just like my word processor does.
• Better static analysis at compile time, following through code pathways and warning about dead code (Some modules may be intractable).
  
• Verify that return values are handled when necessary, i.e. fopen() may return NULL, so code shouldn't just use the return value without checking if its valid.
  
• Likewise, there needs to be a language extension so the compiler can check the methods and functions which require their return value to be handled; how about a check keyword? (Not handling a returned pointer as above is the worst case which could cause a crash.)
  
• Compilers should check that C++ exceptions which may be thrown are handled.

I'd also like to see better systems libraries, such as Boost and other middleware; people don't/shouldn't need to write their own classes for half the things they do at present.

C++0x will be finalised in the next few years. D is also available now, D is developed as an improved version of C++. It brings lots of interesting ideas, like multiple return args and the null keyword (C++0x will have nullptr I hope). Couldn't spot a pure keyword, would be handy for abstract bases will have this so they don't have to use =0 as at present! Maybe even some D ideas will pass back to C++0x. Would there ever be enough momentum to switch development to D? I don't think it is different enough from C++ for companies to want to make the shift.

I'd like to see a good system for managing memory pools in the standard library, perhaps Boost pool. OSs provide a good heap, but often fragmentation still happens. The heap doesn't know the expected lifetime of an allocation when it chooses where to place it. If a coder can help by separating their same-sized (or even smaller) objects to come from a pool that could help with performance.

Threads in C++ is still under discussion, Hans Boehm has proposed an idea, and Howard Hinnant of Apple has proposed something similar to Boost's thread mutex. Both are different from the pre-processor approach of OpenMP.

Interesting times ahead!

Labels: Coding

A new year is upon us, and everything feels so different! I've been pondering if 2007 could be a year to remember for software. Reliability is definitely one area I can see which has scope for improvement in this year's releases.

Following on from my last discussion: The problem with programming? Do we as software developers really need to expose ourselves and users to crash opportunities as at present? It's an interesting point to debate. C++ gives programmers control over memory resources, direct address access and pointer arithmetic. Invalid data can cause out of bounds memory accesses and likewise programmers are only fallible humans which can make mistakes as well. Programmers shouldn't count on being able to always beat the language at what it does best!

As Bjarne says "People push what they know and what they have seen work; how could they do otherwise?". It's surprising to see people code C++ like they do C, pointers arithmetic, allocating memory and magic globals etc which should be neatly wrapped up in a state system, design pattern or other standard approach.

A few examples of problems in C++ which can trip programs up:

• Memory management delegated to programmer, no built in garbage collection of inaccessible objects/allocations means resource leaks can occur.
  
• Using pointers means NULL pointers will cause crashes.
  
• The type system is not type-safe like Ada, Java, Haskell and C#.
• Direct address access for memory and data means a the program could over or under-run.
  

Would it be better to write non-kernel/system libraries in a language which does not permit these issues? It seems logical to cut down on the opportunity for errors.

In practice I see that performance critical crunching code (like a quantiser etc) really benefits greatly from a C++ implementation which can use the points above; the compiler just can't convert the code into as optimal an implementation itself. Let's only write a more optimal block of code when we really need to though, the profiler shows us when that is necessary ;)

Labels: Coding, Future

Interesting Q&A session with Bjarne in these two interviews: The Problem with Programming + More Trouble with Programming. I echo the sentiments of those who detract from C++'s successes, it's a professional's language for high-level coding when suited. If an engineer mismanages memory or makes improper use of pointers and addresses then there will be problems.

I love the flexibility C++ allows, templates and our own memory management mean we can get the most out of each embedded system. Likewise STL is great, as are custom templated fixed size containers. In addition, Boost has lots of useful functionality not in the standard. Object-Oriented programming is really a necessity to handle the complexity of projects. C++ lets me think about applying algorithms, structures and maintainability my way, its a meritocracy of code ;)

The flip side is if flexibility allowing such a degree of control is suited to all engineers? Essentially, do we really need to change to a constrained language to prevent high-level coders accidentally making mistakes which cause crashes and bugs? One solution is coding standards, they are great and I adhere to the rules in place on each project. However, if the risky language feature isn't available then there does not need to be a rule book to prevent its use.

At over 20 years old, C++ is still v.cool!

Labels: Coding