ReCode /

BoostCon 09

This was my first BoostCon and I have to say that the Aspen Meadows resort is a great place for this kind of meetings, though I was shocked to see that it was SNOWING when I woke up Monday morning. Yes, shocked -- naively, I'd hoped that I'd finished dealing with snow for this lifetime when I moved to California. :) Needless to say, I was quite happy that not only the snow melted quickly, but the weather was quite good through the rest of the week.

The conference was split in two tracks, which means that there were two talks happening at any given time. So basically nobody could see all the talks. Below is a list of some of the talks I attended:

  • Thomas Becker gave an excellent talk on the Boost smart pointer package. There was a lot of wisdom in his words, not only related to smart pointers. It is very easy to come out as arrogant when you tell people what is a good way of doing this or that -- but Thomas is such a great speaker and such a nice guy that frankly, it'd be arrogant not to appreciate that his entire talk was very practical: lessons learned from hands-on experience.
  • Troy Straszheim had an interesting report on using Boost Serialization and Boost Python to hunt for neutrinos on the South Pole. It turns out that the terabytes of data they collect is all stored in files, formatted by the Boost serialization library, and that physicists love scripting in Python -- who knew! :) Troy is clearly a very good speaker, since he managed to make something as complex as C++ serialization easy and simple to understand.
  • Justin Gottschlich gave a talk on a transactional memory library he's working on, which isn't part of Boost yet but looks very interesting. Essentially, this is a library approach to using atomics instead of locks to write thread-safe code. The benefit of atomics is that they are easily composable without risk of deadlocks. An interesting observation is that locking may be faster on platforms with small number of cores, since when you have a thread waiting on a lock, that frees a core that can be utilized by other threads. Of course, locks don't scale so transactional memory definitely seems the way to go in the future.
  • Michael Wong talked about the upcoming C++0x standard. He explained the two main goals for this new revision: to make C++ a better language, and to make it easier to teach and learn. There are many new language features, such as rvalue references, variadic templates and concepts. Special attention was given to the new built-in atomic features. To be honest, I am a bit nervous about atomics since all this is based on very recent academic research, which makes it rather risky in my mind, though it appears that a lot has been learned from experience with similar features in other languages.
  • Regrettably, I missed Dave's lectures on rvalue references, in part because they were hands-on workshops and I was unprepared with downloading and installing GCC (which is one of the compilers that support this new C++ feature.) Rvalue references are a very important addition to the language, and I'm sure Dave's talk was awesome.
  • Lucanus Simonson and Gyuszi Suto presented GTL, the Geometry Template Library. Now I'd never have to write any 2D CSG operations by hand. I am a bit disappointed that the library doesn't support floating point coordinates. I know that's tricky, but today float support is important for anything that can end up rendered on the screen; this is the only way to get smooth zooming and 3D rendering, etc.
  • Marshall Clow's talk, "Extending Boost.Algorithms -- A Progress Report" presented a list of algorithms which are very basic yet quite useful, which for some reason were not included in STL. Interestingly, people from the audience pointed out variations of these algorithms which were equally useful yet they were missing from the Boost.Algorithms talk. :)
  • Hartmut Kaiser and Joel de Guzman presented Spirit and Karma. I wish they used more descriptive names for their libraries, I already forgot which is which. :) Joking aside, if you need to build a simple parser/compiler, Spirit will save you tons of trouble. Creating a parser with Spirit is a breeze, really. Karma is sort of the opposite of Spirit: it lets you easily format complex text strings from even something as complex as a container, all with a simple formatting expression.
  • Asher Sterkin presented a talk on Boost.Preprocessor. If you haven't seen this library, you will be blown away by what the standard C processor can do, and Asher did a great job explaining it, which isn't easy given the general ugliness of anything that has to do with C macros.
  • I regret not seeing Stephen Lavavej's talk. Reading the title -- "C++0x Support in Visual Studio 2010" -- I assumed it was going to talk about some MSVC-specific C++ features. I thought to myself: why would I want to know about features that I can't use with any other compiler? It turned out that the title was misleading, and the talk was NOT about MSVC! Oh well.

Last but not least, this year's keynote was delivered by Andrei Alexandrescu. His talk was provocatively entitled "Iterators must go!" which is quite ballsy given that most C++ programmers consider STL, and its iterator-based abstraction model created by Alex Stepanov quite brilliant. Andrey's proposal is for iterators to be replaced by something he calls ranges.

A good way to explain ranges is: if an iterator refers to a single element from a sequence, a range refers to an entire sub-sequence. Instead of ++/-- operations on iterators, ranges can be shrunk from the front or the back, but importantly they can never grow.

For sure, this is an interesting idea. It highlighted several valid shortcomings of iterators, such as the fact that operations on iterators are limited to the handful of operators that are valid for pointers: ++, --, *, +=, -=, etc. Because ranges are user-defined types, you can define any number of member functions on them. Also, ranges are higher-level abstraction compared to iterators; they simply "know more", which almost always translates to greater optimization opportunities, etc.

However, I am not convinced that "iterators must go". I mean, plain old C pointers are iterators, and I don't see plain old C pointers going anywhere any time soon. Iterators are a lower level, less safe concept, but they are so basic that they simply can't be ignored.

Andrei pointed at the simplicity of implementation of several classic algorithms using ranges, most notably his "retro" range which is roughly similar to the concept of reverse_iterator, which I must agree is painful to implement. The "retro" range is certainly elegant, but the question is how much of this elegance would be lost in a real-world practical implementation?

I mean, iterators are also simple and elegant; most of the complexities in defining iterators are needed in order to allow algorithms to provide complex dispatching and optimizations which are critical for performance. Anything -- ranges included -- that attempts to replace iterators must not compromise performance, and this will inevitably take away some of their elegance and simplicity.

And since no practical and complete C++ implementation of ranges exists, the question remains open, for now.

Justin E. Gottschlich — 15 May 2009, 17:37

Hi Emil -

Nice blog entry. Thanks for the kind words about my talk. I also just posted a BoostCon'09 trip report here:

I mention your talk in it, so please have a visit if you get a chance.

Add comment: 
Sign as author: 
Add 1 to 431 and enter it here: 

Formatting hint: when posting comments, surround code blocks in [@ and @].