Visual Studio 2015 CTP 5 Available | Hacker News Reader

Visual Studio 2015 CTP 5 Available

blogs.msdn.com

134 pointstrickz32 comments

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?

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

http://blogs.msdn.com/b/vcblog/archive/2014/11/17/c-11-14-17... (via http://blogs.msdn.com/b/vcblog/archive/2014/11/12/visual-stu...)

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.

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.

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.

Windows 10 looks like it will feature windowed 'modern' apps so it'd be surprising if they didn't push those apps even further now.

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.

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.

Parts of VS may have a WPF UI, but I can assure you the vast majority of the codebase is C++.

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.

I'm not expecting much, the roadmap is pretty underwhelming: http://blogs.msdn.com/b/wpf/archive/2014/11/12/the-roadmap-f...

I was really surprised to read this:

    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)?

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.

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.

Apparently

VS -- Visual Studio

ALM -- Application Lifestyle Management

CTP -- Community Technology Preview

TFS -- Team Foundation Server

Reply on news.ycombinator.com