I've been meaning to attend the
ACCU Conference
for some years and finally decided to pay my own way for a couple of
days this year. It was an opportunity to hear world experts on C++
and other programming topics and to a smaller extent to meet and
socialise with other professional programmers.
I attended the following sessions:
Keynote: Improving Collaboration in Open Source Projects,
Mark Shuttleworth
This was a somewhat surprising choice of speaker and subject since
I think most attendees work on proprietary software, but I think any
sensible developer in the proprietary world will try to build on free
libraries under non-copyleft licences, where appropriate. Mark talked
about governance and leadership in "open source" projects (actually
praising Debian for having a clear constitution) and about the need
for good communication between projects, for example about release
schedules. He seems to have accepted that Launchpad cannot be a
single hub, and called for standard formats for, for example,
exchanging information about related bugs between bug trackers. But
it doesn't sound like he's ready to take the lead on that.
Choose your Poison: Exceptions or Error Codes,
Andrei Alexandrescu
Andrei looked at the strengths and weaknesses of various error
reporting mechanisms in C++ and introduced a technique for making
error handling more flexible. Normally a function is designed either
to indicate errors through its return value or to throw an exception
on error. If a function returns an error indicator, it's easy for
callers to ignore it. If it throws an exception on error, then a
caller that provokes errors more often than the called function's
author anticipated pays a high cost in processing time for those
errors.
Andrei's solution involves a class template
Likely<typename T> whose instances hold either a
return value of type
T or an exception. A function that
can fail has a specialisation of this template as its return type.
The caller can check for failure if it knows how to handle it, or it
can ignore it - in which case the conversion to
T or the
destructor will throw the exception. This is clever but doesn't seem
to be entirely satisfactory. The destructor which throws does first
check that no exception is already being processed, avoiding collision
of the two exceptions and consequent abrupt termination of the
program, but this can result in errors being unexpectedly ignored.
Introduction to Component-Level Testing, John Lakos
A marathon 3-hour talk on designing and testing software,
particularly C++ programs (the subject of
his well-known
book) as a set of well-defined components.
Lakos first defined these components as being "physical" i.e. sets
of source files - normally a header file defining an interface, an
implementation file, and a test driver file. They may also include
metadata for the build system. He talked about the value of reusable
components (as if this wasn't obvious!) and the risk of introducing
circular dependencies - which essentially turn many components into
one and reduce reusability - if we fail to keep track of dependencies.
Software built out of components can be viewed as a hierarchy or stack
defined by dependencies. In a large system, components with similar
dependencies and dependents can be grouped together into packages or
package groups to simplify a view of these dependencies.
He explained that the test driver's dependencies count just as much
as the implementation's, because we cannot reasonably test a component
until we have tested its dependencies. Test drivers should also be
written to avoid depending on environmental settings and
configuration, so far as possible.
Finally, and perhaps most importantly, he spent a long time talking
about how to construct test cases and test data. I might try to
summarise this in a later entry if anyone's interested.
The Appliance of Science: Things in Computer Science that every
practitioner should know, Andrei Alexandrescu
Andrei began by complaining that OpenOffice Impress was even worse
than PowerPoint, but being able to use Linux (specifically Ubuntu)
more than made up for the pain.
He briefly presented four key ideas that he believes programmers
should understand and be ready to make use of:
- Dynamic
programming. The Wikipedia article summarises this as "a method
of solving problems exhibiting the properties of overlapping
subproblems and optimal substructure (described below) that takes much
less time than naive methods". As a simple example, Andrei presented
a Fibonacci number generator. But since no-one really needs Fibonacci
numbers, he also showed its application to calculation of the Levenshtein
distance between words which is important in spell-checking and
fuzzy string matching. A naive approach to either of these problems
is so inefficient as to be useless.
- Garbage
collection and its connection to type-safety. Any object model
can only provide 2 of the following 3 features without losing
type-safety: mutable objects, aliasing (multiple pointers/references
to the same objects), and explicit reuse of memory (via free, delete
or similar). C and C++ have all three of these. Garbage collection
eliminates the need for the third. However it does require more
virtual memory and/or more processing time (there is a trade-off
between these). (He quoted numbers from Hertz and
Berger, Quantifying the Performance of Garbage Collection vs. Explicit
Memory Management, 2005. However, these numbers show the cost of
GC in Java, specifically Jikes, not as an addition to C or C++.)
- Machine
learning. Sometimes we don't know how to solve a problem, but we
can have the program gather feedback that will allow it to learn how
to do it better. This depends on the "smoothness assumption": small
changes in inputs have a small effect on the result, rather than
making sudden changes. Examples: image recognition, deciding whether
changes to web page layout are helpful, disambiguating search
terms.
- Transactional
memory is the most promising approach to achieving scalability
across massively parallel systems. Most hardware performance
improvements over the next 10 years will come from greater
parallelism, not higher clock speeds.
Writing for ACCU (BoF)
I think I've been convinced to write an article about
standardisation of multithreading in C++.
C++ Threads,
Lawrence
Crowl
Crowl gave an overview (
similar
to this) of the extensive work that's been done on standardisation
of multithreading in the C++ language and library. This is one of the
most important features in C++0x due to the increased parallelism
mentioned above. The current semantics of multithreaded programs are
not standardised, resulting in subtle but potentially serious
differences between current C++ implementations that support multiple
threads, and in the need for assembly-language code in programs that
use lockless synchronisation. Much of this is also relevant to C and
is being considered by the C standard committee.
C++0x Initialisation: Lists and a Uniform Syntax,
Bjarne Stroustrup
Stroustrup recapped the 4 forms of syntax for initialising objects
in C++, some inherited from C and some necessarily invented for C++,
none of which are entirely generic. He noted the lack of a simple
syntax to initialise the elements of containers, which violates the
general principle that class types should have the same status as
built-in types in C++. He then introduced a new initialiser syntax
that he and others have defined for C++0x, which is a brace-enclosed
comma-separated list of values, similar to that used for arrays and
C-style structures (aggregates). Container types can define a
constructor with a parameter of type
const
std::initializer_list<T> & and when constructed with
this new form of initialiser they will receive this wrapper for a
constant array of element values. For types that do not, the values
in the list are treated as arguments to some other constructor, if one
matches. Otherwise, for compatibility, this may be treated as
aggregate initialisation.
C++ Standard Library report, Alisdair Meredith
There was far too much information here for me to even begin
to summarise. Suffice to say there are lots of good things coming
bu the library committee will have its work cut out to get them
all properly specified in time for the Committe Draft coming late
this year.
I also met old friends and new, put faces to names from newsgroups
and books, and got too little sleep.
