Sunday 15th April, 2007
At breakfast time yesterday morning we were sitting in a conference room listening to a seminar by Trolltech - the people behind the Qt cross platform C++ framework.
Although we use WTL for our current projects, we are always looking to learn new techniques - and of course the lack of cross platform support is the big achilles heel of frameworks such as WTL (and of course MFC). It was an interesting presentation, and although we don't have any direct application for it at the moment, it is certainly something we will bear in mind for the future.
The first session of the day was "Towards a Memory Model for C++" with Hans-J. Boehm from HP Labs.
Multithreading is increasingly important in modern software systems, and the difficulties of writing multithreading support are well known. Java and C# define threads as a core part of the language, but even there getting the semantics of threading right is exceptionally difficult. C++ (as ever) presents a different set of problems and considerations, and traditionally C++ has addressed this using libraries.
Hans discussed why this is not adequate, using Pthreads and the Win32 threading model as illustrations. The impact of these failings is clear - multithreaded development in C++ is harder (and more error prone) than it needs to be.
As a result of this efforts are underway to ensure that the C++0x standard will define a memory model describing visibility of memory accesses to other threads. Herb Sutter is leading a similar effort for Microsoft platforms, and the intention is that the outcomes of the two efforts will be compatible. That can only be good news for C++ developers.
The detail of the proposals was beyond the scope of the session, but one obvious point is that a standard threading API will be provided as part of the C++0x language. The full proposal for this area of the standard can be read on the web at:
http://www.hpl.hp.com/personal/Hans_Boehm/c++mm.
After a short break we both headed to the Bladon suite for "Better Bug Hunting" with Roger Orr.
The session started with an introduction discussing the high cost of bugs and the wide variation in the effectiveness of individual developers at finding bugs quickly and not introducing unnecessary bugs in fixing them.
Bugs come in many forms, ranging from inconsistant or nonstandard UI and badly specified feature, to poor performance or instability. These are however, only symptoms - the root causes are often more subtle defects or flaws.
A simple approach to bug hunting might include:
-
Understand the system and how it works
-
Reproduce the failure. Unit testing can help a great deal here
-
Identify where the problem really is - not just where the symptom is
-
Change one thing at a time
-
Keep an audit trail (so you know what you changed and why)
-
Canvass views from others on the defect and possible fix
-
If you didn't fix it, it ain't fixed. Don't be tempted to "hide it under the rug"
More typically, it goes something like this:
-
Hope it goes away
-
Blame someone else
-
Open a debugger and poke around in the vague hope of finding something
-
Try random changes to see if the bug goes away
-
Fix the symptoms, but ignore the underlying defect.
Obviously, being able to reproduce the bug is absolutely key, and often developers have very limited information to go on. This increases costs and makes it less likely that the developer will correctly identify the root cause. Communicating to testers and end users what information is required when a defect is identified is essential.
An obvious improvement is to write scripts or code to collect the supporting information we need in order to triage the bug. Included in this category are of course the ubiquitous crash dumps. Logfiles also have their place - but only if the logs are easy to find and their contents are comprehensible. A bad log message is worse than none at all.
Any defect may relate to others which are already documented. As a result it is always worth looking for patterns in the defect tracking database.
Even when you think you've identified the cause, it is worth taking a step back. Could there be another possible cause? Is your fix really the right one or do you need to look a bit deeper?
Some classes of defects are of course much harder than others:
-
You can't reproduce the defect
-
The defect affects widely separated blocks of code
-
Memory corruption
-
Timing related
-
Environment related (e.g. permissions)
-
It was not the fault you thought it was.
Some techniques which can be used to increase effectiveness include:
-
Adding tracing
-
Refactoring areas of the code where you think the defect may lie
-
Running the system under a virtual machine in a configuration which is representative of that on which the bug was previously seen
-
Deliberately stressin the code to see if the failures match the observed symptoms
-
Use static or dynamic analysis.
-
When the cause of a bug is identified, it makes sense to take a step back to determine how to more easily identify and fix bugs of this class.
After a brief and spartan lunch (all the hotel provided were a few sandwiches) Beth and I headed back to our room to rest for a while (and hence for hot chocolate on the terrace!). Conferences really are exhausting!
Before heading in for the final session we had a chat with Julie Archer and Ewen (the conference chair) about sponsorship opportunities for next year's conference. The options they gave us were exactil what we were looking for, so I would hope we will have something in place for next years conference. Watch this space...
The final session of the conference was "C/C++ Programmers and Truthiness" with Dan Saks, an entertaining look at how both the general public and developers (who really should know better) will give "gut instinct" precedence over contrary evidence.
Dan's major example was the placement of const in variable declarations (i.e. whether you should use const T * or T const *) a cause he's been fighting for some years. It got really interesting when Herb Sutter and Bjarne Stroustrup both got involved in the discussion...
Personally, I think we've got bigger battles to fight. There are far too many developers out there who don't even use const, and with the trickle of people from languages without const (for example C#) into ocasasional C++ coding I keep running across this is not likely to get better in the forseeable future.
