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?
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):
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
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.
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.
I remember reading that Microsoft was moving the WPF framework into maintenance mode as they focus on the WinRT variant of UI development. Interesting that from the release notes, WPF appears to be getting feature development again. Hard to know without Windows 10 consumer announcements if Microsoft internally is back-tracking on the idea of fullscreen desktop apps.
Visual Studio itself is a WPF app, for what it's worth. I can't imagine Visual Studio being rewritten as a "Modern" app any time soon. So, it makes sense that MS will continue to invest in WPF.
When no dialogs are open, the overwhelming majority of the UI is WPF now though, to my knowledge. I remember running debug builds of 2010 that showed paint rectangles and there was basically nothing that wasn't WPF even in that first WPF version.
Enterprise backlashed and they had to respond. There is no need to suffer through backwards-compatible legacy stuff (JS, HTML, CSS) if you are not building something public-facing.
We have rebuilt the XAML language service on top of the .NET
Compiler Platform ("Roslyn") to provide an improved XAML editing
experience with rich IntelliSense that is faster and more reliable.
My understanding was that Roslyn was heavily geared towards languages that are largely procedural like C# and VB.NET. So functional languages, like F#, aren't suited to being parsed by Roslyn. But all of a sudden they're using Roslyn with a declarative language (XAML)?
Having used XAML recently for purposes not even related to WPF, I can definitively see what this might bring.
XAML is at its core a format to describe an object graph declaratively. The objects can be any .NET object.
The current XAML editor already understands a lot about the objects you describe - i.e. it loads the assembly and introspects the types to give you intellisense while editing. The current one is not without its quirks and bugs, however.
I'd be thrilled to have a new, robust editor that intrinsically understands classes, properties, value converters etc to offer more assistance when writing raw XAML.
XAML is a markup language, that counts as declarative, but you can think of it as a subtraction of C# (the ability to create instances and bind their properties), it doesn't add any advanced declarative programming features and definitely nothing fancy type-wise as in F#.
I don't know what they did, but it seems reasonable that it would share a type checker with C# but have a unique parser.
