C++98 Support Costs Extra!

I should note, right up front, that this post reflects my personal opinion and not that of my employer. In particular, KDAB currently does not require extra payment for C++98 support, even though, as this post will make abundantly clear, I personally wouldn’t mind if it did :).

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.]]

About these ads

About marcmutz
Marc Mutz is a Senior Software Engineer, Trainer, and Consultant with KDAB.

27 Responses to C++98 Support Costs Extra!

  1. Ivan Čukić says:

    +1

    I don’t think this is a real possibility, but I’d really like if we all went for C++11 and made a list of unsupported compilers.

  2. Nightwish says:

    I don’t get some programmers; apparently throwing everything that works into the garbage bin and spending a couple of years doing it again with new errors to be found is the way forward.

    • marcmutz says:

      I’m not talking about re-writing existing code in C++11. That’d be ridiculous.

      I’m talking about using C++11 for new code and (where necessary) fixing up old code to compile with C++11 (only necessary if old code uses auto in the old sense or an identifier that in C++11 became a keyword) instead of restricting new code to pre-98-standard C++ in a vain attempt to support obsolete platforms or compilers.

      PS: I like your Nick :)

  3. Full support and if it comes to a discussions on the relevant KDE mailing lists, I will express my wish to make use of C++11 in KWin

    • thorGT says:

      This. Someone must start, just go and do it, even if it breaks things for a while. Just like Lennart has always done :)
      (Also, it’s definitely a fun project to try to marry Qt and libsigc++/Boost.Signals. Nearly impossible, but funny nevertheless. But it would take some real manpower, I’m afraid, this would be the real obstacle.)

  4. thorGT says:

    Well, Trolltech are the first ones in this list. “Not all compilers support templates, we will not use meta programming based signals nor any parts of Boost, esppecially pointers.” This very company also refuses to accept STL, even though there’s Boost which covers almost (if not all) constructs that STL’03 lacks. In this sense, GTK and Gnome seem to be, if not light years ahead of Qt and KDE, at least more appealing to those users who know what code is and who appreciate code quality/clarity. The day Qt adopts all those things will be one of the most important and celebrated programming holidays, I believe. :)

    • tmartins says:

      Let’s be honest, reflection features (which are provided by moc) are very important to RAD developing, and those are still missing from C++ (who knows, maybe in C++21).

      Now, on the lambda/functional front, I’d say Trolltech is doing a lot better than you give them credit for: http://developer.qt.nokia.com/wiki/New_Signal_Slot_Syntax

    • marcmutz says:

      > Well, Trolltech are the first ones in this list.

      I beg to differ. I like the way Trolltech has handled the new libraries introduced in the Qt 4 lifetime; how they didn’t try to support them on older compilers. That’s exactly what I’m calling for: Maintain the old version/code to support the old compilers, but leave the shackles of non-standard compilers behind for new versions/code.

  5. Thiago Maciiera says:

    thorGT: Qt has used templates for at least 10 years and meta-programming has been in use for that long. Some uses of template features were withheld for some time, such as partial template specialisation, as some compilers we still needed to support didn’t have them.

    That’s also past. There are now few features of C++98 that we cannot use, like template-template parameters and template friends. Even in 2011, those features aren’t completely supported.

    As for Boost, the problem isn’t that Boost uses templates, but the fact that Boost has a horrible API (from Qt’s point of view) and cannot promise binary compatibility. When they start to learn how to maintain long-term support, we’ll consider using boost.

    And finally, I don’t think you’ve ever read Gtk code if you say their code is clear to read. Really, I mean it.

  6. Konstantin Tokarev says:

    >Why do we care about the quirks of GCC 3.3, or heaven forbid, 2.95?

    FYI, we have to use 2.95 for embedded development in 2011 :)

  7. Pingback: C++11 support in Qt 5 » Thiago Macieira's blog

  8. Afiefh says:

    I’m all for using as much C++11 as possible. Having written some code with it, it feels like a completely new language.

    I used to tell people that with Qt, C++ is fun again. Now with C++11 it’s also fun. I long for the time Qt uses C++11.

    From my point of everything that can be done in standard C++11 should be dropped from the MOC. Yes MOC can still support Qt4 style signals/slots but instead of outputting the old code for them it can now output templated signals/slots the way a user would do them in C++11.

  9. “less fun, so you should need to pay extra” I hope Kalle will like when I start charging extra for all the time I work on a certain big-bulky project since it’s rarely any fun :)

    Marc for president (of the EU).

  10. Matt says:

    I think your assessment of the current Microsoft situation is a little rose-tinted. According to this:

    http://blogs.msdn.com/b/vcblog/archive/2011/09/12/10209291.aspx

    they still have considerable work to do, and their progress does not look very rapid.

    Otherwise, I agree with you. Having two open-source compilers dedicated to swift and conforming implementations of the new standard is a wonderful situation for C++ developers.

  11. Andreas Hartmetz says:

    What’s the problem with Clang? It seems to support the most desirable features of C++11 already, see here:

    http://clang.llvm.org/cxx_status.html

    At least one of the Clang guys has worked on GCC for a long time, and I suspect that the people writing Clang would like to support C++11 fully ASAP, but their employer lets them implement Apple extensions to Objective-C instead. I have a checkout and I skim the commit messages every couple of days.
    In any case there is rapid progress in Clang and the team will need something to do when the Objective-C extensions are done ;)

    • marcmutz says:

      One of the most prominent new C++11 features are lambda functions. It’s one thing to not support constexpr, which you can trivially define to nothing without losing that much, but it’s another to fail to support lambdas, for which a similar workaround is not possible. Clang, according to pages such as the one you’ve cited, is the only one that does not already support lambdas (VC, GCC, EDG all do).

      • pixelpapst says:

        Could you define constexpr to const, to catch a subset of the errors ? Or would that break, syntax-wise ?

        • marcmutz says:

          It would break when you put constexpr on functions (incl. constructors):

          class Point {
              int m_x, m_y;
          public:
              constexpr Point() : m_x( 0 ), m_y( 0 ) {}
              constexpr Point( int x, int y ) : m_x( x ), m_y( y ) {}
              // ...
              constexpr int x() const { return m_x; }
              constexpr int y() const { return m_y; }
              // ...
          };
          
      • Vicugna Nova says:

        “without loosing too much”?
        constexpr is probably (maybe modulo the threading stuff) the biggest new chunk in *11 by far. It’s nothing short of a second compile-time language, next to template metaprogramming. Much easier to use, and certainly more powerful for many (not all) things, not least because its the access to floating point and array data, plus string literals. Probably also a nightmare to implement, no wonder that only GCC even tries (with varying success).

        Then again, GCC is sorely lacking delegating constructors and template aliases, both of which
        Clang offers today.

        • marcmutz says:

          > “without loosing too much”?

          Yes. constexpr and rvalue references are two of those language features that will speed up applications just by recompiling under a C++11 compiler. In Qt 5, Qt::AlignLeft|Qt::AlignTop now doesn’t invoke a function anymore, but produces a compile-time constant, and a static const array of QPoints now ends up in ELF .rodata. Similarly, assigning to an implicitly shared value class instance from an rvalue now just swaps pointers and doesn’t manipulate d->ref anymore.

          It’s a lot of work for to add constexpr and rvalue semantics to a library, but applications don’t need to care and still profit.

          This is not true for lambdas and auto, say.

  12. fdskljaflskldfja says:

    I do the same for web development. IE(before 9) support not only takes more time to code (obviously), any code that is written only for IE is charged at double hourly rate. I am open about it for my clients and they don’t complain.

    Pushes the client to consider banning IE8 and older and to upgrade their own workstations.

  13. oliver says:

    No objections to dropping support for older compilers, as long as you keep support for older platforms. For example, building KDE4 on RHEL5 requires a newer g++ anyway, which can be downloaded and compiled with the system-wide g++. Much more important is that the build system correctly supports libs and tools installed in non-standard locations (like in home directory), which is not always the case (eg. for Boost).

  14. Sean says:

    I tried doing this for my projects. Then reality kicked in and I had to support MSVC on Windows. Even though I only support the latest version (2010), I cannot use the vast majority of C++11 features. The next version of MSVC adds almost none of the currently missing features. You won’t find C++11 supported on the preferred Windows developer stack until at least 2014, and probably not until several years after that. Unless you plan on dropping Windows support, or plan on forcing all devs to use toolchains with poor Windows integration, you can’t use much of anything from C++11 besides auto, gimped decltype, and gimped lambdas. (GCC for instance does not produce debugging information in the “standard” Windows format, ad expected by the system debugger, and any IDE that isn’t MSVC Visual Assist is just a pain in the ass… And MSVC is pretty bad already)

  15. Martins Mozeiko says:

    While I like C++11 features very much I don’t see how ditching C++98 can happen very soon.

    Just think about Wii, Xbox360, PS3 – all these platforms are very popular, and all of them provide old GCC compilers (not sure if they use GCC on xbox360 at all). So how can all the developers of these platforms switch to C++11, if they don’t have such compiler available at all?

    • marcmutz says:

      I’m running Debian Lenny. The latest GCC that’s available for it (even counting backports) is 4.3. So how do I experiment with C++11?

      I compile GCC v4.6 or trunk (upcoming v4.7) myself :)

  16. Gamedev says:

    Sir, you need to think less about the language and more about making Qt/KDE efficient. Do you know why game programmers restrict C++ to “C with classes”, and shun STL or – heaven forbid – that Beast, i.e. Boost?

    Because when you impose budgets on memory used by your application and try to combat memory fragmentation (by avoiding dynamic allocations), when you start to think about your vtbl size and how many memory fetches it takes to call your function, all these fancy “academic” language features and metaprogramming start to get in your way and you crave for simpler, if more manual, language – basically, something like C/C99.

    Unfortunately, because Linux applications are often written by “students” who prefer academic approaches, do not care about anything but latest fads in both software and hardware and treat application development as a “fun pet project”, Linux desktop is no more an example of efficiency (frankly, it has never really been, given X Window abomination).

    Current desktop environments are not comfortable to work with in 512MB, let alone 256MB of RAM – which is a SHAME. Console programmers manage to put not only the game code (which is quite complicated these days and usually is 15-40 MB unpacked), but also a lot of assets in that space.

    Reducing the memory footprint of KDE, making it available everywhere (which implies supporting as many compilers as possible), is much more noble goal than “I want to type less”.

    Please, make basic KDE application suite finally usable on my 1GB netbook with Atom.

    • ju says:

      That’s funny cause my only pc is a 1GB netbook with Atom (plus an external monitor) and I use KDE. Oh, and from 4.8 I even use nepomuk and strigi.

      I also do some occasional Qt application (despite the requests for web applications is far broader).
      I frankly don’t get why the “academic approach” should be wrong.
      The first reason I don’t get it is that they never taught me one.
      At college they care about applications which are as efficient as possible, but they never actually taught us anything about doing things in the real world. That’s left to the student as an exercise.
      Wasting memory means having to do again an exam.

      Maybe the real problem is with lazy developers who don’t know how to use the advanced “academic” features and get back to hacking their code (a friend of mine used to solve all its problems using globals variables).

      Oh, KDE is quite efficient indeed – and I’m not as sure as you it’s being made mostly by students.
      I wholeheartedly agree with you about the X problem, it’s really become a pain to maintain.
      Luckily wayland is making its first moves and there is already Qt support for it.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: