Hacker News new | ask | show | jobs
by putzdown 4170 days ago
Does anyone know how the support for C++11 is looking in this version? It would be pretty great if Microsoft could finally close [the gap](http://blogs.msdn.com/b/vcblog/archive/2014/06/11/c-11-14-fe...) on C++11 support a mere four years after GCC and Clang completed their support for the standard. That would also give some hope that Visual Studio might have full support for C++14 in a year or two (which GCC and Clang have today). Is there an updated support chart somewhere?
5 comments

Microsoft is doing a mix of C++11 and C++14 support.

http://channel9.msdn.com/Events/Visual-Studio/Connect-event-...

Still, outside the open source world, from all vendors selling compilers, Microsoft is the most up to date.

Before anyone mentions ICC, no not even version 15 is fully compliant.

https://software.intel.com/en-us/articles/c0x-features-suppo...

IBM just realeased XLC with partial C++11 support.

Others are even worse.

And odd bits of proposed C++17. Picking the low-hanging fruit, I imagine, based on their discussion of the difficulty in supporting other features.

I'm waiting impatiently for expression SFINAE. I like the features of C++ that let you write dynamic-esque code that's evaluated at compile time. It enables little bits of cleverness that save you from large complicated solutions.

> outside the open source world

Which is quite large, considering that Clang and GCC are the standard compilers for just about every major non-Microsoft platform, including the mobile ones.

> Which is quite large, considering that Clang and GCC are the standard compilers for just about every major non-Microsoft platform, including the mobile ones.

I have worked with a few enterprise customers (Fortune 500) that only allowed the compilers from the respective OS vendors. And new versions required an approval process to be followed.

There is more out there than just GNU/Linux, Mac OS X, *BSD and Android.

Granted, this was around 10 years ago, but I doubt the situation changed at all in such environments.

The C++17 bits are things proposed by people on the VC++ team, since verifying that something is actually implementable is an important part of writing a good proposal.
By my count, none of VC 2015 RTM's C++17 features will have been proposed by MS. N3922 auto and N4086 trigraphs were proposed by Googlers. Same for another Core feature that might be checked in. In the Library, I just checked in void_t, invoke(), and trivially copyable reference_wrapper, none of which I proposed (or anyone else at MS). I did propose auto_ptr/etc.'s removal which was voted into C++17, but it's too late for me to remove that stuff from 2015 RTM.
I suppose I could see the "most up to date" argument, but Intel looks like it has the most complete commercial compiler at the moment for C++11.

But certainly, the next most complete support for C++11 in a commercial compiler might just be from Oracle Solaris Studio (which, despite the name, is available for Solaris and Linux both):

http://docs.oracle.com/cd/E37069_01/html/E37071/gncix.html#s...

It supports all C++11 features excluding: C++ 11 concurrency and atomic operations, and User-defined literals.

Notably, Oracle Solaris Studio is also one of the few compilers to include full C99 support.

> I suppose I could see the "most up to date" argument, but Intel looks like it has the most complete commercial compiler at the moment for C++11.

Except that some of the features are only available on UNIX based OS. So you cannot use them if you are after portable code.

If an ANSI C++ feature is currently OS specific on a multi-platform compiler, on my manual it isn't supported.

> But certainly, the next most complete support for C++11 in a commercial compiler might just be from Oracle Solaris Studio

Interesting. I wasn't aware of it.

The last time I spend coding on Solaris was around 2011.

> Notably, Oracle Solaris Studio is also one of the few compilers to include full C99 support.

Even as C++ fanboy, I do concede it is to be expected that a UNIX vendor does support the latest C standards.

After all, it is because of UNIX that we got C and I don't see it being re-written into something else.

There I would like that at least they support "Bounds-checking interfaces (Annex K)" from C11, which is optional.

  There I would like that at least they support
  "Bounds-checking interfaces (Annex K)" from C11,
  which is optional.
The bounds-checking interfaces are really something that has to be provided by libc, so Solaris itself will provide those.

Although it isn't highlighted in the release notes in an obvious way, most of the support for C11 is also available in the 12.4 release of the Solaris Studio compiler. The primary things missing are the same things they don't have for C++11: concurrency and atomic primitives.

Historically Visual C++ has never been the goto compiler for anyone interested in the latest feature set. They have always had an amazing optimizer since they've had to build NT with it. I doubt they're ever going to catch up to GCC/Clang. msvc has to remain ABI compatible with other MS C++ libs like MFC/ATL/etc, and so ABI breaking changes have to wait for the next major version of VC. I think some stuff like COM has work across multiple VC versions without ever breaking.
True. In addition, builds can sometimes be slow on MSBuild. Of course, if you're interested in cross platform development Visual Studio 2015 provides some great new features. Additionally, coupled with IncrediBuild (https://www.incredibuild.com/cross-platform.html) you can get some blazing fast builds
It would be nice if you wouldn't derail the conversation with another tired old "but it's not as good as gcc when it comes to X". This is a CTP. You split hairs over minor points of standards compliance that many devs won't even use on gcc yet because the features are so new, and completely avoid mentioning that the productivity of Visual Studio (for both .NET as well as native C++, including cross-platform C++) arguably dwarfs any other IDE on the market. Have you used, I mean really used, a recent version of Visual Studio for C++ work? Or are you making this comment because you haven't and you find it threatening? Tell you what. You build your C++ app with Xcode 6 or command-line gcc for all it matters. I'll build mine with Visual Studio 2013 or later. We'll see who wins. By the way, I love gcc. Love, love, love. That doesn't mean I have to take pot shots at Visual Studio, which is tooled to the Nth, completely stable, and not at all the old restrictive MS dev environment of yore. The times have changed.
It is a fair question given the fact that Visual Studio 2013 doesn't even support basic C++11 features like constexpr. When doing multi-platform C++11 work the code usually must be dumbed down a lot if it needs to compile also in VStudio, e.g.:

- can't use many of the new initializer mechanisms in the class declaration (initializer lists, etc...)

- no constexpr

- std::chrono high resolution click isn't actually high resolution but only has millisecond accuracy

Complete list of missing C++11 features up to VS2013 is here: http://msdn.microsoft.com/en-us/library/hh567368.aspx

Microsoft should first complete their C++11 support before moving on to C++14, otherwise it will probably never get fixed.

Visual Studio is a fine IDE, but the C++ compiler lags behind quite a bit.

Microsoft obviously should NOT first "complete" their C++11 support since there may very well be more important features in C++14 than some arcane features no-one would use in C++11. Same applies to all the other compiler vendors and all versions of the standard.
Arcane features that no-one uses should not be in the standard but in some sort of optional extension, and a feature that is not supported by all major compilers might as well not exist, since it cannot be used in a portable code base.
The init list bug has been fixed for 2015 RTM. Also, I fixed the clocks back in 2015 CTP1 (alpha 1). Sorry about that bug, we just didn't get a chance to fix it in 2013 - in that release we were insanely busy converting the whole STL over to real variadic templates.
Nice! Thanks a lot for your hard work, it's really appreciated despite my ranting ;)
Parity on standard compliance matters because many of us want to compile our code on different platforms, and that is all we download MSVC for. FWIW, it is also the only thing I look for in the gcc and Xcode/clang change logs.
They are making progress. The latest chart I saw (for the 2015 Preview ) is at

http://blogs.msdn.com/b/vcblog/archive/2014/11/17/c-11-14-17...

Good to see the two things I've tried to use and wouldn't work in VC++ 2013 (generic lambdas and noexcept) have been implemented.