It’s a sum-up of the GoingNative 2012 conference that happened on Feb 2nd-3rd. There won’t be an English translation later, since it’d be outdated by the time it appeared. The talks are in English, and you can download them all from Microsoft’s Channel9 page, though.

From the article:

Die Qualität der Vorträge war durchweg hoch, wenn auch Nichtmuttersprachler einigen Vortragenden nur schwer folgen konnten. Die Konferenz macht Lust auf ein Jahr mit mehr C++-Konferenzen als seit 1999 üblich. Besonders hängen blieben das Versprechen auf schnelle Adoption des neuen Standards, auch von Clang und Microsoft, und der Versuch, die C++-Standardbibliothek in den nächsten Jahren massiv zu erweitern.

This is the original-language version of my recent Mythos Proxy-Style article.

The first Private Practice article, Taming Templates, examines techniques to control template code bloat. There’s nothing particularly earth-shattering in there, but I noticed that a lot of people don’t seem to be aware of the fact that templates can cause a lot of duplicated code, so I thought I’d write about it.

Even if they haven’t been released under the Private Practice banner, the following articles also fit that category well:

• Mythos Proxy-Style [[Update 2011-11-24: EN version now available as "What's in a Proxy-Style?"]]
• Dem Elfenbeinturm entreißen

It examines the implementation of QProxyStyle in Qt 4.6 and, from that analysis, derives an important caveat regarding the applicability of a certain well-known design pattern.

This is the German translation of an unpublished English-language original, which I will publish here after a grace period.

From the article:

In der Qt-Gemeinde existiert ein Mythos: “QProxyStyle”. Auf der einen Seite stehen Entwickler wie David Faure, seines Zeichens KDE-Urgestein und geschätzter Kollege des Autors, die behaupten, ein QProxyStyle sei unmöglich. Auf der anderen Seite stehen Entwickler von Qt-Erweiterungen, die einen QProxyStyle entwickelt haben wollen. Eine Spurensuche im Märchenwald deckt interessante Komplikationen bei der Anwendung eines bekannten Entwurfsmusters auf.

Developing a serious and large application from scratch, or from an existing desktop application, presents a different set of challenges compared to your normal smart-phone ‘app’. Portability to different platforms, and long-term maintainability in the face of ever-changing mobile target platforms suddenly come into play. This paper attempts to summarize the experience we gathered using the new declarative GUI framework, QtQuick, in this project.

Unfortunately, recent events (read: Tizen) have already invalidated much of the content in the supplemental box on the future of Qt, but that’s the bane of everyone writing about Qt’s future these days…

Get the English version (with slightly more details) at http://www.kdab.com/whitepapers, or read the German version (with better editing) in the current print issue of German computer magazine iX: http://www.heise.de/ix/inhalt/2011/11/114/.

In other news: I’ve updated “Understand the Qt Containers” with a discussion of the differences between STL and Qt containers regarding size types, associative container insertions, and error handling. I also mention QT_STRICT_ITERATORS now.

Compared to the print version, we’ve updated the content in some places, such as spending less time on the removal of concepts and more about the adoption of the new standard, as well as turning the Top 10 into a Top 11 to celebrate the new standard

From the article:

Die spannendste Frage wird sein, wie schnell sich C++11 gegen seinen Vorgänger C++98 wird durchsetzen können. Es war in den vergangenen zwei Dekaden regelmäßig notwendig, C++-Neuerungen konservativ einzusetzen, da Compiler den Standard nur zögerlich umgesetzt haben. [...] Hier muss sich die C++-Gemeinde umgewöhnen. Neuerungen wie Lambdas und auto machen C++11 zu einer deutlich produktiveren Sprache, als C++98 es war. Es gilt nun, diese Produktivitätssteigerung im Alltag auch zu nutzen, um gegen Java und .NET zu bestehen. Ein weiteres Jahrzehnt der Zersplitterung und Inkompatibilität könnte die momentan exzellente Ausgangsposition von C++ schnell wieder zunichte machen.

Hope you like it.

So, the new C++ standard is finalised and voted on unanimously. Does that mean that we’ll have another decade of C++ incompatibilities ahead of us?

My answer to that is: That depends on us.

Will we adopt C++11 faster than C++98? Our compilers do. Will we make use of the new productivity gains (auto, range-for, lambdas, …) or will we continue to castrate our code to work with 15-year-old compilers? The answers of the majority of C++ programmers will determine how the next decade goes for all of us.

In this post, I’ll argue (strongly) for dropping C++98 support asap, and using C++11 to the fullest possible extent in all our projects. This includes dropping support for compilers and platforms that don’t (yet) support C++11 to the extent required by a particular project instead of #ifdefing our way around it, as we (as an industry) have done for the past 30 years. Will these compilers and platforms be left out in the cold? Not really: they will have older versions of libraries and programs to support them. But yes, newer versions will require an up-to-date C++ compiler.

Is this realistic? I think it is.

Essentially, we have this situation already now. Many projects require fairly recent versions of libraries, precisely because 1) there’s not much point in supporting older versions, and 2) supporting many versions of one library with the same code-base is fairly expensive. I’ve tried. Gpgme++ theoretically supports gpgme’s that can be considered stone-aged. Has anyone ever tested this? Hmmm… How many Mac applications still support OS X 10.2? 10.3? 10.4? Half of the web doesn’t work anymore on KDE 3.5′s Konqueror.

Then why should we be so conservative when it comes to C++, the very core of what we work with? It’s not even customer-visible. Why do we accept an STL shipping in 2011 that is basically unchanged from the mid-1990s? Why do we #ifdef our way around MSVC6 problems in 2011? Why do we care about the quirks of GCC 3.3, or heaven forbid, 2.95?

My new-year’s resolution (ok, it’s a bit early, but hey): stop it!

C++11 support in C++ compilers now is much stronger than C++98 support was in 1998 in the then-C++-compilers. I fully expect every C++ compiler to have caught up on final C++11 with its next major release, except for source-code invisible changes like the new memory model. I want Qt 5 to require a C++11 compiler. I want KDE 5 to require a C++11 compiler. I will lobby inside KDAB to do the same.

Why? Because I’m a programmer, and we’re lazy.

I want to use auto. If you make me type std::map<std::string,std::string>::const_iterator instead of auto, it’s more work, less fun, so you should need to pay extra.

I want to use lambdas. If you make me write

struct ByName : std::binary_function<Foo,Foo,bool> {
    result_type operator()( const Foo & lhs, const Foo & rhs ) const {
        return lhs.name() < rhs.name() ;
    }
};

instead of [](const Foo &lhs, const Foo &rhs) { return lhs.name() < rhs.name() ; }, it’s more work, less fun, so you should need to pay extra.

C++11 is a much more productive language than C++98. We as an industry can, however, only reap that productivity gain if we stop throwing C++ productivity out of the window by the bucket-load in the hopeless pursuit of compatibility with non-standard implementations. The worst offender, Microsoft, has seen the light. Their current compilers are very standards-compliant, and actively maintained. I hope that Apple won’t be the next blocker: By choosing Clang over GCC for—apparently—political reasons (GCC 4.2 was the last GCC with GPLv2), they have lost at least one year of C++11 support that GCC and VC are ahead of Clang. Let’s hope Clang catches up soon.

[[EDIT 2011-09-21: If you think that VC isn't implementing C++11 fast enough, you can make yourselves heard here: http://visualstudio.uservoice.com, in particular here and here.]]

[[EDIT 2012-03-30: Microsoft has announced that the VC++ compiler will have a faster release cycle than Visual Studio. That makes me hope that we'll see a "reasonably conforming" (Sutter) VC++ a long time before 2014. Also, Clang++ 3.1 has caught up a lot with GCC (http://clang.llvm.org/cxx_status.html#cxx11, 3.1 currently shows up as "SVN"); it seems tooling will indeed not be the problem, after all.]]

From the announcement:

This two-day training teaches how to use multithreading with the primitives provided by Qt. Participants will gain insight into multithreading problems in general, and how they pertain to Qt programs in particular.

Examples include how to offload work from the GUI thread, how to increase throughput to the maximum in your application, and optimal strategies for communication between threads.

The training covers topics such as cross-thread signal/slot connections, QThreadPool, QObjects and multithreading, QtConcurrent, QFuture, and Qt atomic operations.

Participants are expected to have a working knowledge of C++ and Qt. Prior experience with multithreaded programming is recommended, but not necessary. The course will start with a one hour multithreading refresher.

To book, visit http://www.kdab.com/schedule.

Until October 1st, you’ll save 200€ on the early-bird offer. Just use d94ec6fd in the Voucher(s) field.

Hope to see you there!