

C++98 Support Costs Extra (or why we should switch to C++11 now) - zeugma
http://marcmutz.wordpress.com/2011/09/20/c98-support-costs-extra/

======
HardyLeung
I used C++ for years, and then switched to C#, and recently switched back to
C++ in my new company (choice of language reflects only the nature of the
software we develop, not language superiority). Just yesterday I was
evaluating the new features of C++11, and I was pleasantly surprised by (1)
the new language features, and (2) the extent of support already by existing
compilers (gcc 4.4 and VC++ 2010).

I can see that we'll immediately benefit from a few improvements, such as auto
variable, lambda support, standard support for unique/shared/weak_ptr. Even
old school C++ users who have no interest in fancy new idioms would benefit
from these "syntactic sugar" features found in other modern languages. There
are a lot more that I'm still exploring, but so far I like what I saw.

Also these new features just work on the compilers. Given how long the
standard process has been, a lot of the features were already baked in. Modern
g++ and VC++2010 both have very good support. I listened to a BUILD
presentation on C++ and the Microsoft folks are very committed to full C++11
compliance in VS11 (next version of Visual Studio), but AFAIK, VS2010 is
already quite capable.

So, I agree, if you have a choice, switch NOW.

------
colomon
And in the (rather depressing) real world, I have gotten flack in the past
year for making changes to my source code that required C++98 compatibility,
which made said code no longer compile on Microsoft Visual Studio 6.0.

~~~
wazoox
Do they still run Windows NT4 on their dev systems, too? This is quite
surprising.

~~~
colomon
No idea, and I'm kind of scared to ask.

------
p9idf
"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."

I'm not familiar with the author's product and can't say whether C++11 is the
right choice for him, but I wouldn't consider the constant API churn of OS X
or the constant web standard and web standard extension churn to be a good
argument in favor of anything.

~~~
jacobolus
For existing large applications (in particular, Adobe’s and Microsoft’s) OS
X’s relatively quick change has been somewhat frustrating, and for any
application there’s no need to replacing working code with newer different
code just for the sake of it... but for new projects, OS X’s API “churn” has
been great news, letting smaller teams tackle harder projects and create
richer user interactions in less time.

I think it’s pretty reasonable to argue in favor of using new language
features and APIs for new projects, assuming enough of the target audience is
using platforms which support them.

------
calloc
GCC, Clang, Visual C++ 11 provide charts where they show how far they have
completed c++0x support (renamed to c++11):

GCC: <http://gcc.gnu.org/projects/cxx0x.html>

Clang: <http://clang.llvm.org/cxx_status.html>

Visual C++:
[http://blogs.msdn.com/b/vcblog/archive/2011/09/12/10209291.a...](http://blogs.msdn.com/b/vcblog/archive/2011/09/12/10209291.aspx)

~~~
greyfade
Apache also maintains a list:
<http://wiki.apache.org/stdcxx/C++0xCompilerSupport>

And IBM:
[https://www.ibm.com/developerworks/mydeveloperworks/blogs/58...](https://www.ibm.com/developerworks/mydeveloperworks/blogs/5894415f-be62-4bc0-81c5-3956e82276f3/entry/xlc_compiler_s_c_11_support50?lang=en)

And Digital Mars: [http://www.digitalmars.com/ctg/CPP0x-Language-
Implementation...](http://www.digitalmars.com/ctg/CPP0x-Language-
Implementation.html)

~~~
calloc
That Apache one looks like it is a comparison matrix, which is extremely
handy.

------
xsmasher
This is analogous to the "let's drop IE6!" movements. If your client doesn't
need backward compatibility, great for you. If they do, then good luck
charging them for a new version that's _worse_ (no longer works/compiles) in
their environment.

------
iam
I want to completely agree with this guy, I really do. But Visual Studio 2010
supported more of C++11 then most other major compilers (except I think for
Comeau and GCC) when it was released.

Apple didn't choose Clang over GCC for political reasons, a lot of Clang devs
are actually on the Apple payroll.. and Clang is just a far superior compiler
to GCC architecture-wise -- it just needs a few more years to catch up to full
C++11 support.

The fact of the matter is that unless you're starting a new project you're
probably tied to your old version of the compiler, to upgrade to something
newer would require weeks of updating the toolchain.

~~~
beagle3
> Apple didn't choose Clang over GCC for political reasons, a lot of Clang
> devs are actually on the Apple payroll.. and Clang is just a far superior
> compiler to GCC architecture-wise -- it just needs a few more years to catch
> up to full C++11 support.

Do you have any insider knowledge of this? Because the prevailing wisdom
around the net is that Apple didn't like to be dependent on a GPL3'd product
(which gcc became at some point), so they propped up the only viable
alternative at the time, which was LLVM.

~~~
iam
That may be so (and I'm not an Apple insider, although I do know a few LLVM
devs). I guess you could say a driving motivator to find an alternative
solution to GCC was to not be reliant on a GPLv3 license. Traditionally I
don't think the license has stopped Apple from contributing a lot back to the
OSS community (just look at WebKit).

Besides, a compiler is just a compiler. Maybe someday down the road they will
start producing their own ISA, but until then even if they're making their own
ARM chips it's really hard to get it to do special Mac/iPad-only magic.

What I do know is that Clang was funded by Apple almost from the start, it was
engineered right from the start to be more than just a compiler but something
you could plug into the IDE as well (as the latest XCode demonstrates, it has
completely unbeatable C insight).

LLVM itself is also far more extensible than GCC, just look at the slew of
new-ish (last 3-4 years) of projects that have launched using LLVM. Have you
heard of any such projects being launched with GCC? I can't think of any
(maybe if they did, they weren't proud of it).

~~~
beagle3
> Traditionally I don't think the license has stopped Apple from contributing
> a lot back to the OSS community (just look at WebKit).

GPL3 makes a world of difference (KHTML/WebKit is GPL2 if I'm not mistaken);
e.g., it may interfere with Apple's executable signing policy

> Have you heard of any such projects being launched with GCC?

Not as many as LLVM, but ... GCCXML, GCC Go frontend, GCC D frontend. Things
still happen in GCC world.

------
blub
C++11 would be nice, but I think it will be a while before I can use it. I
don't think any of the mobile platforms support it...

I am now using GCC 4.4 and haven't used MSVC in a while.

------
Animus7
Our company's been C++0x-heavy since the first bits rolled out in GCC. We're
lucky enough not to have any legacy, so we can afford this.

The other day I was stuck on a system with only a C++ (03) compiler, and it
was a truly crippling experience without lambdas and the new STL.

Anecdotes aren't worth much, sure, but I find it difficult to disagree with
this article.

------
angersock
Some entertaining bits from the article:

"How many Mac applications still support OS X 10.2? 10.3? 10.4?"

"Then why should we be so conservative when it comes to C++, the very core of
what we work with?"

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

I'm as much for iconoclasm as the next person, but this whole C++ madness is
starting to make me worry. While the rest of us have been off in the trenches
of maintenance and production, some cabal of academics and chuckleheads has
been cooking up this monstrosity of a language, and now it is finally coming
to a head.

Folks, conservatism in software design is appreciated--in language design,
essential. Python 3 is still not support by many useful libraries. Perl 5,
over ten years later, is still in production and use. ECMA/Javascript is only
now really taking off, after 15 years.

And on the darker, even more depressing side of things, you've still F77 codes
in "production" and _active maintenance_ \--a friend of mine who is a graduate
student is dealing with this right now. These are souls being fed to the
gaping maw of legacy code.

I'm sure C++ has some interesting features. I understand, for example, why the
"auto" keyword is being given new meaning (because the syntax of the STL,
classes, and templates is so mindnumbingly awful!). I understand why explicit
defaulting and deleting of function might lead to cleaner code (regardless of,
say, an explicit that already exists). I understand why I might want 3
different declensions of 'u' in front of a string to support various forms of
Unicode (where is your liberalism about forcing everyone to using UTF-8 and
being done with it?).

I also understand that D probably has a better execution on these ideas than
C++.

And that Javascript and C# have a better implementation of lambdas and
closures.

And that for raw power and readability, C with embedded assembly (still!) can
probably eat the lunch of any C++. (for an example of rational language
evolution, see C1X: <http://www.open-std.org/jtc1/sc22/wg14/> )

And that C++ still doesn't have anything other than a crackheaded set of half-
idioms for exporting classes for dynamic linking in a crossplatform way, or
even for binding to another language! Go ask the poor bastard who wrote SWIG's
comments on the same--he quit programming for several years to stop dealing
with C++'s increasing garbage.

I feel reasonable in saying this: C++ is not going away soon. One day (even
sooner if you are in academic circles and dealing with libraries) we
maintenance programmers are going to have to start dealing with code written
to take advantage of the new features in C++11.

And on that day, all of us will be wondering why the hell we are still using
that katamari of language features, instead of something less baroque--perhaps
Perl.

~~~
marshray
I think your missing a key point: C++11 is a better, cleaner language. It's
not C++98 with a bunch more not-fully-baked and overly complex stuff thrown
in. Much of the new stuff that's added is there to make the old complexity go
away.

Most of the old mile-long redundant type definitions can go away now, being
replaced with just the 'auto' keyword.

The old std:: argument binders were like poor man's lambdas. Now we have real
lambdas and don't need them.

The old practice of defining tons of template overloads is no longer required
because we have proper variadic templates now. To unfairly pick one example at
random of what should no longer be necessary:
[http://svn.boost.org/svn/boost/trunk/boost/type_traits/detai...](http://svn.boost.org/svn/boost/trunk/boost/type_traits/detail/is_function_ptr_helper.hpp)
Of course this is special purpose-library code that isn't the kind of things
most applications would need to write, but it could easily end up in a
compiler warning or error message.

Sure, of the people who really didn't like C++ before then C++11 might not
change all their minds. But for those of us who used and liked C++ already,
these new features represent great _simplifying_ improvements that are only
going to help with ongoing maintenance.

~~~
angersock
The issue is that there are already many better, cleaner languages than
C++98/03.

C++ is a good language, with some clunk to it. The best parts of it are
arguably the bits inherited from C (which C++11 looks like it might break
with). The OOPy parts (classes, polymorphism, etc.) have been done better by
languages like Java, Javascript, and Smalltalk. Templates exist to get around
grossness of the rest of the language, and were done better by Java's generics
anyways. Multiple inheritance was done better by Java in the form of
interfaces.

The rhetoric is that these changes somehow simplify the language--that's cool
and all, and may even be true for the most trivial of examples or the most
basic of beginners. The problem is that these new features are going to be
released in the wild alongside many libraries who don't use them, being old,
and who won't be updated, being cumbersome or trusted. And so, the burden of
making the ends meet is going to fall on the rest of us who now have to
support, in effect, two languages.

If the improvements are incremental, then this wasn't worth doing, If the
improvements are such a new, cleaner, simpler language, why the hell call it
C++? Again, see D.

Lastly, most of the fixes are syntactic sugar which do nothing to help fix
some very real issues with the deployment of the language.

How do I bind these things to other languages cleanly? In C this is trivial--
why isn't this fixed in C++11?

How do I load libraries of classes dynamically at runtime? From C wrappers?

When interfacing with old libraries (which actually do exist), how often am I
going to have to write some kind of NULL-nullptr glue code?

Why do we not have variable length arrays (they're in C99)?

~~~
marshray
I'm nothing like an official C++ spokesperson, but I'll take a shot at these
questions.

 _If the improvements are incremental, then this wasn't worth doing_

Well maybe C++ is not your cup of tea, but I find the improvements worthwhile.

 _If the improvements are such a new, cleaner, simpler language, why the hell
call it C++? Again, see D._

Yeah, I think it's a better C++ not an entirely new language.

 _Lastly, most of the fixes are syntactic sugar which do nothing to help fix
some very real issues with the deployment of the language._

Systems languages _are_ syntactic sugar for the underlying runtime model. I
consider C++ to be a systems language (the ISO spec explicitly defines a
minimal profile suitable for embedded systems for example). But C is probably
a slightly more "systems" of a language (in no small part because it's the
language which defines most system's APIs).

 _How do I bind these things to other languages cleanly? In C this is trivial
--why isn't this fixed in C++11?_

If you think this is trivial in C I suspect it's because you have so much
familiarity with it and/or these other languages are implemented in C and
define their external APIs directly in C. C has an unfair advantage in this
regard, but it's just not that hard to integrate C++ and C.

Sometimes C++ has advantages too, some people swear by Boost.Python for
example. Looks much simpler than C to me.

 _How do I load libraries of classes dynamically at runtime? From C wrappers?_

That's one way. The main reason dynamic loading works in C is because the
types are all so primitive (and it doesn't have "classes"). You can use those
primitive types for your APIs and in C too.

Another way is to define the classes interfaces in terms of something binary
stable over the scope you wish to separately compile these libraries. This
requires some understanding of the guarantees of the platform and
complier/linker. MS-COM for example gets a lot of mileage out of some
relatively minimal abstract class layout conventions.

 _When interfacing with old libraries (which actually do exist), how often am
I going to have to write some kind of NULL-nullptr glue code?_

I've been writing some C++11 with C++4.6.0 and a bunch of old libraries and
haven't run into that. I don't use pointers in my code very much, so I don't
think I've even had to use nullptr yet.

So I would think "not very often", at least if your coding style is similar to
mine.

 _Why do we not have variable length arrays (they're in C99)?_

I don't know why the decision was made in the language committee, but
std::vector with the new initializer syntax works well for me for that
purpose. Perhaps the C99 construct could be a little more efficient, but I
don't see a reason that an alert compiler couldn't also allocate the storage
on the stack.

~~~
angersock
Thank you for your helpful response!

 _C has an unfair advantage in this regard, but it's just not that hard to
integrate C++ and C._

This is very true... as you pointed out C is very primitive in a lot of
respects, and this doubtless simplifies working with it from other languages.
The question is, how do I easily call the new C++11 code from something like
Lua, Java, Python, Ruby, etc.? How weird will my wrapping code end up looking?

I'm sorry to harp on this, but I'm in the middle of a medium-size engine
codebase written in C++, and even with our restraint so far on the use of some
of the more advanced language features, things like smart pointers and whatnot
are so useful that they become a concern (multithreaded code without smart
pointers is a recipe for madness).

 _I've been writing some C++11 with C++4.6.0 and a bunch of old libraries and
haven't run into that. I don't use pointers in my code very much, so I don't
think I've even had to use nullptr yet._

Out of curiosity, how much have you done with OpenGL/OpenAL/OpenCL, etc.? Have
you had any issues there yet? I'd like to know if that stuff fits okay with
C++11.

~~~
marshray
_The question is, how do I easily call the new C++11 code from something like
Lua, Java, Python, Ruby, etc.? How weird will my wrapping code end up
looking?_

Well, no weirder at least than the older C++. Which is certainly a matter of
perspective! :-)

In the ideal case, someone will write a C++ binding to your language that's
even easier than C. Like I said, some people love Boost.Python but I haven't
tried it.

I did play with Lua and C++ recently. The Lua interpreter itself can be
compiled as C++! It will then throw C++ exceptions instead of using
setjmp/longjmp, which is much saner IMHO. (I am really impressed with Lua.)

Just a feeling, but I bet that sooner or later somebody is going to come along
and do something really cool with C++11 lambdas and that multi-language
bindings problem.

 _I'm sorry to harp on this, but I'm in the middle of a medium-size engine
codebase written in C++, and even with our restraint so far on the use of some
of the more advanced language features, things like smart pointers and whatnot
are so useful that they become a concern (multithreaded code without smart
pointers is a recipe for madness)._

Yeah. How does one code without smart pointers in their toolkit? I couldn't go
back..(except when I have to thunk back to C for something).

Also, for multithreaded stuff, I'm getting addicted to the new std::atomics in
C++11!

Not new with C++11, but have you tried Boost.ASIO for multithreaded IO? It is
awesome.

 _Out of curiosity, how much have you done with OpenGL/OpenAL/OpenCL, etc.?
Have you had any issues there yet? I'd like to know if that stuff fits okay
with C++11._

I have, in fact, been doing some experiments with C++ and OpenGL in my spare
time. Made some wrapper classes for compiled shaders and buffer objects and
the like.

I had much of that code running before I switched to G++4.6.0 and starting
allowing myself to depend on C++11 features, but I know I've extended it some
since. I really don't recall noticing any difference in the switch.

One of the biggest advantages of C++ is something that many people miss. Much
of that "ugly" complexity is in support of some design principles that are
critical for large-scale software development: backwards compatibility (often
back to C), and you don't pay for new features you don't use.

------
cheez
If your supported platform list looks like this:

    
    
      Windows
    

Switch to C++11 NOW. You will kick yourself for not doing it earlier.

~~~
acqq
If you want your application to run on Windows 2000, you can't. VS 2008
doesn't have "auto" etc but it can produce binaries which run on Windows 2000.
The libraries for VS 2010 simply removed the code that allowed them to run on
Windows 2000. I can imagine you'll ask "who uses Windows 2000," well, if home
users don't, the companies still do.

~~~
cheez
I know which companies do. I chose not to support them for my software. There
are enough other companies to make money without it.

~~~
daemin
You could do that, or based on what the author of the article was saying, you
could just charge more for anyone that wanted Windows 2000 support.

