Let’s say you have a few hundred thousand lines of code being regularly updated. Let’s also say you have at least a few hundred users, maybe more, some of which use your code for their work and expect backwards compatibility when updating to new versions. Finally, let’s say that your code still uses the C++03 standard and you’re kind of itching to move to modern C++. In short, you’re in the same position we are with QuantLib. Should you do the move, and if so, how?

Oh, and let me add a couple of notes before I start. First: I’m talking about code that someone uses in production somewhere, and that you have or feel some kind of obligation to keep running. Hobby project? Go ahead and migrate it: it will be educational. Code that you’ve thrown on GitHub as an explicitly best-effort, use-at-your-own-risk thing? Go ahead. Second: I’ll assume you already analysed costs and benefits for the migration; the C++ Core Guidelines say it better than I could. Don’t do it because it’s cool.

Back to the original question. The way I see it, you can only move safely if you know, or can choose, the compilers to be used; for instance, if you want to migrate proprietary code. If you have an open-source project, odds are that some of your users are stuck with older compilers; in the case of QuantLib, for instance, we have users working in financial institution and whose compilers are mandated by their IT departments (which tend to be pretty conservative—and rightly so, given the stakes).

If this is also your case, the safer choice is to stay with C++03. At least, it’s safer until compilers still accept deprecated features like std::auto_ptr. If you use them, you may already have to deal with a spew of compilation warnings from recent versions of gcc and clang, and future versions may turn them into errors. We’ll need to find and alternative before this happens (I’ll probably get back to this in a future post). Preferably, an alternative that doesn’t involve telling your users that they have to specify C++03 explicitly when compiling.

The other choice is to go ahead and migrate. I don’t think there’s a lot of middle ground: once you write the first auto in the code, older compilers are left out, so for all purposes you have migrated your code; and things like

    #ifdef HAS_AUTO
    auto i = ...;
    std::vector<T>::const_iterator i = ...;

would defeat the purpose of auto so completely that it might as well move into another country and start a new career in the performing arts. (That also goes for other features; no point in writing a lambda if you also have to maintain the corresponding function object.)

Of course, I don’t have the faintest idea which choice is right for your project.

As for me, I’m not migrating QuantLib to C++11; in our case, I think it’s the responsible choice as well as the safer one. So, did I write all this just to tell you to settle for the safer choice? Is Cat Stevens’ Father and Son playing in the background, with me as the former character? Not really. There are a couple of things I’m going to try.

To begin with, we can get ready for the future. The library is still C++03 code, but our automated builds also make sure that it compiles and runs correctly in C++14 mode, so that our users can link it to their modern C++ code. We might also target C++11 and C++17. (By the way, that’s another interesting question: if you migrate, what standard should you target? The latest and greatest, or C++11 so that more people can jump onboard as they slowly upgrade their compilers?)

Last, and more importantly, during this year I will perform an experiment. I’ll make parts of the migration in a development branch and report on the results and the problems that I will find. Fair warning: I’ll do in my spare time, so it will take a while. There are no guarantees that this will lead to something useful for the library; but my main purpose is to learn something, seeing as I haven’t had a chance to get hands-on experience with modern C++ until now. Another sub-experiment will be to try and keep the branch integrated with the master branch, to avoid divergence. I will report on this as well, even though it might fail faster than the main experiment.

At least, this whole thing will give me something to write about.

Subscribe to my Substack to receive my posts in your inbox, or follow me on Twitter or LinkedIn if you want to be notified of new posts, or subscribe via RSS if you’re the tech type: the buttons for all that are in the footer. Also, I’m available for training, both online and (when possible) on-site: visit my Training page for more information.