The D language, C++0x and threads

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!

2007, the year of software reliability?

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 ;)

The problem with programming?

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!

How about an open mobile phone platform sir?

Mobile phones have come a long way in the last 10 years in the UK. I remember when my friend got his first analogue mobile back in 1995 and how impressed I was! I've got a K800i myself now, it's the CyberShot 3MP camera model. A really impressive feature set over the K700i I had. The K800i's screen is bigger, web browser renders clearer in anti-aliased fonts and it even has an M2 memory card slot, hungry for MP3s and photos - going to be great rocking to some fab tunes on the ski slopes with this phone come new year ;) Now all the French Alps need is a snowfall!

There are a few things which could be improved though. The stability and reliability isn't perfect; PhotoDJ crashed while saving my edited photo, and it even crashed when I added Nite (langue à la mode?) to my words list! Interestingly it auto-restarts when it crashes, also restarts when engaging file transfer mode, it could just be rebooting into "File Transfer" mode though?

Now what would be cool is if Sony published the source code, I'd love to get the opportunity to write some features for this phone. Here are a few ideas I've had :-
General:

• Integrated search box on main GUI of the phone, which searches with Google.
  
• Modify Camera View and PhotoDJ to make the Zoom function always accessible.
• Optimise Next Word Prediction, a cool feature, but too slow to be usable at present.

Compose message features:

• Add a way to set the Subject on TXT and MMS messages.
• Revise the input mode to not switch the last letter to CAPS when I switching from abc to Abc input.
• Add a some words to the dictionary and share the list online, Blog and Nite etc. (or use the Mozilla dict?)
  
• Keep the order of msg in Drafts, at present it changes when they are viewed.
• In the Web browser jump into input mode when a key is pressed (need to press Edit each time atm).
• Know that peoples' names and cities first letter should be capitalised.
  

Past use statistics:

• Address book search using past usage stats, like I mentioned in 2004. Also stats for non dictionary words, just add them automatically to a local list.
  
• Unify and sort the extended character list by their usage frequency, atm there are two different orders in use on different dialogs in the phone!

Add Contact dialog:

• When you meet someone and get their mobile number you always enter the number first and then the name; so the Add Contact dialog should highlight that field first!
• Know that 079* is a mobile number, and add it as that rather than Home in the Address book.

Finally, I know mobile phone companies make money out of chargers and other accessories to cover their discounted phones, but it would be sooo much simpler if phones cost slightly more and had standard connectors. USB, headphone jack and charger connectors are pretty much standard on other devices, but even between my Sony models the connectors change! Korea and now China are leading the field with standardised mobile charger and USB sockets; they are even mandating USB chargers! Now we just need a standard headphone/handsfree/music player control port ;)

A positive development is the announced Linux-based Motorola Rokr E2, it shuns the 100 song limit Apple hobbled the Rokr E1 with to "protect" their iPod music player market. The more open and DRM-free approach of the E2 looks v.promising; let's hope it gets released eventually. Many interesting things forward to in the mobile arena, I can't wait ;)

PS2 VU disassembler fix for ee-objdump

PS2 VU disassembler fix for ee-objdump, (patch, ChangeLog), ensure you apply binutils-2.13.2.1-r5900-7.diff.gz prior to this patch.

SDL PS2Linux DualShock2 Force Feedback patch

Currently working on an SDL patch that will add API support for force feedback actuators on joysticks and video game control pads. I am testing with PS2Linux DualShock2 controllers. This is progressing well and I expect it to be finished soon; (patch if you are interested in testing :) and SDL Actuator Force Feedback announcement. [PS2 Actuator Support SDL mailing list post]

Using the MS Visual C++ Compiler with GNU-Wine

CodingStyle is hosting an article I have written about my experiences using Microsoft's Visual C++ compiler from my GNU/Linux computer with Wine. The end result saved me time when porting Spheres of Chaos to PS2Linux. Update: The article is listed on Slashdot as well.

If would like to purchase Spheres of Chaos you can sign-up for Paypal, (if you use this link I will receive the referral benefit). Then visit Spheres of Chaos to complete the transaction.