There seems to be a myth going around that Clang has or had better C++11 support. Apparently when the author did his last shootout Clang had a slight edge over GCC, but over the long run GCC has had the better support most of the time. I started using C++11 (or C++0x as it was still called) in February 2011 and at that time GCC 4.5 had significantly better support than Clang.

Not to denigrate Clang's other qualities - I wanted Clang's better error messages but had to stick with GCC to get the C++0x support I needed.

EDIT: Downvote all you want--you know it's true. It is seldom you'll get to write a new C++ project from scratch, totally, using only standard libraries.

It's stuff like https://github.com/marshray/qak in which I indulge my impulse to recreate the universe from scratch in C++11 on the weekends so I don't act foolishly during the week.

I've been porting it to the limitations of MSVC 2012 and looking at implementing a lightweight Node.js-like IO system in C++11.

For one, everybody does it them with XCode and auto-complete.

Second, the verboseness there plays a function: it makes them self-documenting, whereas with C++ types/iterators/etc you're just repeating yourself.

Which is not necessarily a good experience. From all the IDEs I had used in my life, XCode is the only one I really hate.

At least you didn't have to write UI code for it!

We were porting a particle simulation framework done in Objective-C with Renderman shaders to C++/Windows, because we thought NeXT would die soon.

This was way before Apple decided to buy NeXT.

The funniest thing I find about programming today are all the people who think this is some sort of fashion show.

You sound ageist.

If this includes OS X, I would love to see a source.

Intel's math libs are often 4-5x times faster - if you do a microbenchmark of a loop of powf() or sin() functions, it'll be that much faster using the Intel libs.

If building with fmath=fast for fast floating point math, Intel's fast versions are also quite a bit more accurate, and done't produce nans or infs as much.

Do you happen to remember which one? There have been a few "sporks" of glibc in the last few years and, if memory serves me correctly, Debian now use eglibc.

I think the sporks were done to address bloat, but I'm also curious if they address speed.

http://msdn.microsoft.com/en-us/library/hh872235.aspx

The vectorised code the compiler produces is also a lot better.

See http://stackoverflow.com/a/11227902/1346405

Private companies who deals with CFD (Computational Fluid Dynamics) and Aerodynamics simulations are companies with deep pockets and who generally pay for a bunch of licenses of these compilers, it's not a small market, I can assure you that.

For normal desktop applications it probably doesn't make sense.

But I doubt that it's really worth it. As I said the real advantage was numeric stuff. I doubt that the Kernel will show any real improvement.

Oh and support as well, very important in big companies.

One in Turbo Pascal 5.5, which allowed to use local variables as the function name.

Another one in IBM JDK in Linux, which produced core dumps.

Both were discussed with their respective vendors.

On that note, the whole list looks like it was written from the point of view of gcc. Features on other compilers that vary from gcc are given 'partial' credit, since I guess they do it differently and different is bad. And extensions in other compilers are not mentioned at all.

It looks like the 'shootout' was done by standing in gcc's corner and taking pot-shots at everybody else in the room.

And ICC tends to do quite well, though "twice as fast" is pretty spun (I'm sure there's a vectorizable routine somewhere that does that, certainly most typical code is going to be more in the "even to 10% better" range).

[1] https://github.com/alecthomas/entityx

I've been following the development of C++0x from the side-lines and had recently come across an excuse to get back into C++ (developing games).

I recently wrote about using smart-pointers to wrap resources acquired from C libraries. I was able to load textures that I could freely share through-out a tonne of procedural code and know that there would be no memory leaks. Having such implicit run-time support goes against the C philosophy but I think that with smart-pointers there is finally a good defence for breaking that rule.

http://agentultra.com/sdl-and-modern-c-plus-plus-images.html

Other stuff is mostly about fixing bugs in the standard (<cough> rvalue references </cough>), cleaning up the syntax (auto) or providing new syntax for useful but comparatively rare operations (lambdas). That's all good, but initializer lists can change the paradigm of how the code is presented, and that's better.

I think it is rare just because people is not used to it, once they discover the flexibility of lambdas functions you would start seeing them more often (even abuse of them)

I am remaking a event system that I did for a turn based card game and the use of lambdas is just so natural that I realized now how painful and weak was the previous code.

Other than node.js, virtually none of them make regular use of them. When they do, it's mostly just to have a convenient way of passing a callback.

Lambda's are good. But as implemented in C++11 they really don't do anything to change the nature of the code being written. On the other hand, proper use of initializers does, by virtue of not having to write a thousand setXXX() functions, etc...

I disagree with that statement. To the best of my knowledge, lambdas functions are implemented as functors which are created by the compiler. So to have a comparable code you have to create those functors by hand. Which can be a lot of repetitive and boring work if you are doing something like an event system.

"virtually all major languages (other than C and C++03) have some form of straightforward anonymous function"

What about Java? :)

"virtually none of them make regular use of them. When they do, it's mostly just to have a convenient way of passing a callback."

Coming from Scheme (which yeah we can argue whether is a major language or not) I can see a lot of benefits of using closures, way more than just a convenient way to pass a callback.

"Lambda's are good. But as implemented in C++11 they really don't do anything to change the nature of the code being written."

Even when is not as powerful as the implementation in other languages still is a huge gain rather not having them at all. If you use them accordingly you would found a more concise and clear code in comparison with not using them. At least that was my personal experience.

(Yes, I say "will" - I'm not yet working on something that lets me use C++11 features. Sigh.)

Sadly I am stuck in JVM/.NET on the day job.

Rvalue references/move semantics: being able to explicitly express ownership with std::unique_ptr<T> and moving ownership with std::move() has made correct code so much easier to write (especially with unique_ptrs in containers). I don't ever use the delete operator anymore, yet my code leaks no memory and doesn't have the overhead of reference counting or garbage collection.

Variadic templates: these have made templates so much more useful. I've been able to write amazing helper functions that take an arbitrary number of arguments of any types, such as concat_string() [1], which is probably the most useful helper function I've ever written. I've also done some pretty far-out template meta-programming which I'm slightly embarrassed to talk about.

I was surprised by how useful move semantics were, unsurprised by variadic templates, but also surprised that lambdas weren't as significant as I had expected. They're very useful but haven't transformed the way I write code, perhaps because my C++ code was already pretty functional before C++11. Also lately I've been annoyed with lambdas because it's not possible to move an object into a closure, putting them in conflict with my beloved move semantics.

[1] http://www.agwa.name/projects/templates/

OTOH, having local functions with upvalues was a benefit of lambdas I hadn't even originally considered, but that I've found myself delighting in.

For frequently recurring patterns like "return o.bar" you can write a templated helper function that returns a functor which you can use like this:

  getmem(&FooObject::bar)

I use this technique a lot. For instance I can do:

  std::sort(people.begin(), people.end(), compare_by_member(&Person::last_name))

Here's the code for compare_by_member if anyone's curious: https://gist.github.com/anonymous/5163229

On the desktop and server the world is moving from C to C++/Objective-C, with C still being very important in the embedded space.

Microsoft's official position is C++ is the future and C is legacy on Windows platforms.

Even the two most important open source C and C++ compilers are now both written in C++, although given their open source nature, I expect they to keep on supporting C contrary to the commercial vendors.

Certain C11 features (such as generic macros) could be very useful in Obj-C.

I admit, though, I have no idea what commercial compilers are popular in the Windows world. I am under the impression that you either used Intel's compiler, Microsoft's compiler, or a free port of the Unix toolchain, but I don't really do Windows development.

For commercial unixes, it's hard to find documentation on C versions supported by Oracle Solaris Studio, but it was last released in 2011. HPUX ACC was last released in 2010, so I would be very surprised if it supported the 2011 C standard already. That doesn't meant it won't, but it does mean that it moves slowly. Not surprising, since large unix vendors operate in a market where stability is valued above most other things. IBM XLC already supports C11.

The embedded market tends to use GCC, from what I can tell, although it may vary widely by company. ArmCC is around, but the last major looks like it was in 2011 (minor updates since). I don't know what future versions will bring, but I'd be surprised if they don't at least end up supporting the memory model and atomics. These are /useful/ when writing embedded code.

RTOS development is pretty much the same situation as embedded.

From what I understand, game development usually isn't done in C, but I'd be very curious to know how the compilers there differ from compilers used for normal desktop applications. Which ones are normally used for game development?

EDIT: And, apparently, Microsoft is going to be adding some C11 features to C, as well as most of C99, because it will be piggybacking off the C++11 updates. So even the company that said it was ignoring anything newer than C90 is adding C11 features. That was a surprise to me.

Perhaps you could list some widely used compilers that have said they will not be moving towards C11 support?

  For commercial unixes, it's hard to find documentation on C versions supported by Oracle Solaris Studio, but it was last released in 2011. HPUX ACC was last released in 2010, so I would be very surprised if it supported the 2011 C standard already. That doesn't meant it won't, but it does mean that it moves slowly. Not surprising, since large unix vendors operate in a market where stability is valued above most other things. IBM XLC already supports C11.

As for standards conformance, I "googled" it:

  http://docs.oracle.com/cd/E24457_01/html/E21990/bjabb.html

Support for C++11 is planned though:

  https://forums.oracle.com/forums/thread.jspa?messageID=10730210

I remember everyone ignored the ISO Extended Pascal, because Mac/Turbo Pascal were seen as the standard.

From HPC you left out Portland group, but they are giving good support.

For games I was thinking about the console vendors toolchains and vendors like Codeplay and SN Systems.

http://gcc.gnu.org/gcc-4.7/changes.html

> There is support for some more features from the C11 revision of the ISO C standard. GCC now accepts the options -std=c11 and -std=gnu11, in addition to the previous -std=c1x and -std=gnu1x. > * Unicode strings (previously supported only with options such as -std=gnu11, now supported with -std=c11), and the predefined macros __STDC_UTF_16__ and __STDC_UTF_32__. > * Nonreturning functions (_Noreturn and <stdnoreturn.h>). > * Alignment support (_Alignas, _Alignof, max_align_t, <stdalign.h>). > * A built-in function __builtin_complex is provided to support C library implementation of the CMPLX family of macros.

http://gcc.gnu.org/gcc-4.6/changes.html > There is now experimental support for some features from the upcoming C1X revision of the ISO C standard. This support may be selected with -std=c1x, or -std=gnu1x for C1X with GNU extensions. Note that this support is experimental and may change incompatibly in future releases for consistency with changes to the C1X standard draft. The following features are newly supported as described in the N1539 draft of C1X (with changes agreed at the March 2011 WG14 meeting); some other features were already supported with no compiler changes being needed, or have some support but not in full accord with N1539 (as amended). > * Static assertions (_Static_assert keyword) > * Typedef redefinition > * New macros in <float.h> > * Anonymous structures and unions

and glibc added support http://sourceware.org/ml/libc-alpha/2012-06/msg00807.html

> * ISO C11 support: > > + define static_assert > > + do not declare gets > > + declare at_quick_exit and quick_exit also for ISO C11 > > + aligned_alloc. NB: The code is deliberately allows the size parameter > to not be a multiple of the alignment. This is a moronic requirement > in the standard but it is only a requirement on the caller, not the > implementation. > > + timespec_get added > > + uchar.h support added > > + CMPLX, CMPLXF, CMPLXL added > > Implemented by Ulrich Drepper.

But I don't know what's still missing and I doubt that glibc will implement the range check library (Annex K).

Buried in those comments is one from a MS dev who claims that he is the only guy working on the standard library implementation. Kinda sad, really.

Doesn't Microsoft license its standard library from Dinkumware?

http://dinkumware.com/

They really need to fix that. It's not enough to just chant "Developers!" while running around a stage. You actually have to help them.

Without a reason?

libstdc++ is gcc's C++ stdlib; libc++ is clang's (although clang can used libstdc++). libc++ supports all of C++11, although there's still some bugs. libc++ is ABI incompatible with libstdc++, but it's explicitly designed to support using both libstdc++ and libc++ within the same program, so that's often not a program.

[1] http://gcc.gnu.org/wiki/Cxx11AbiCompatibility [2] http://stackoverflow.com/questions/12542971/using-libstdc-co...

    s/Yes/✔/g
    s/No/✘/g
    s/Partial/∂/g
    s/Don't know/?/g