
C++11/14/17 Features in VS 2015 RTM - StephanTLavavej
http://blogs.msdn.com/b/vcblog/archive/2015/06/19/c-11-14-17-features-in-vs-2015-rtm.aspx
======
dman
I suspect sometimes that StephanTLavavej is way too productive to be just one
person. Maybe a pseudonym under which the whole MSVC compiler / stl team
operates (much like
[https://en.wikipedia.org/?title=Nicolas_Bourbaki](https://en.wikipedia.org/?title=Nicolas_Bourbaki)
) :)

Thanks for being great at outreach.

~~~
zerr
To be fair, and I always thought it quite interesting - Microsoft's STL (C++
Standard Library) is the work of a single person company Dinkumware run by P.
J. Plauger.

[https://en.wikipedia.org/wiki/P._J._Plauger#Dinkumware](https://en.wikipedia.org/wiki/P._J._Plauger#Dinkumware)

~~~
stinos
Is that still the case? Is there no real 'stl team' at MS and everything is
written by Dinkumware? Or is there a more entwined collaboration between them?

~~~
StephanTLavavej
It's entwined, and has been for nearly a decade. MS licensed Dinkumware's STL
back in the mid-90s (and I know almost nothing about the early history).
Around 2005, MS was doing things like adding security features to the STL, but
not really sustained development. In Jan 2007, I joined the VC team and since
then I've spent almost all of my time on the STL (with one brief detour). For
a long time, I fixed bugs, dealt with MS-specific stuff (DLLs, calling
conventions), reported compiler bugs, that sort of stuff, with PJP delivering
new features (starting with TR1 in 2008 SP1). I review all STL checkins,
preventing bugs from happening in the first place. In the last few years, I've
tackled larger overhauls and started implementing larger features. For
example, in this release I rewrote the TR1-era <functional> implementation
(keeping only std::function's skeleton), implementing C++17 invoke() as a side
effect.

Other MS devs have contributed STL bugfixes in this release, and a couple of
features (e.g. uncaught_exceptions() and sized deallocation), so it's not just
the PJP and STL show.

------
sytelus
Just curious... what has changed in C++ land so suddenly? It was hard to get
any improvement in language out for like a decade and how we are seeing C++14
features already standardized and implemented in just an year!! Something
dramatic has happened in C++ standardization process but can't find much
information on that.

~~~
pmelendez
Herb Sutter gives a hint of what's going on in this video:

[https://channel9.msdn.com/Events/GoingNative/2013/Keynote-
He...](https://channel9.msdn.com/Events/GoingNative/2013/Keynote-Herb-Sutter-
One-Cpp)

~~~
kbd
Thanks for the link! Would you mind summarizing a few relevant points from the
hour and a half long video? ;)

~~~
pmelendez
He mentioned stuff like shifting from an static to a living language
(figuratively speaking and mostly referring to the revision frequency).

There were also a proposal to include mature libraries into the standard (i.e
boost, cairo, etc. He also said that was impossible with number of people on
the comittee and they included more members in the form of study groups
focusing in different features/libraries.

I believe the major points would be that they recognized the need to make the
ISO C++ revision cycle faster

~~~
obstinate
I'm also curious what proportion of the committee was made up of "old guard"
folks ten years ago compared to today.

~~~
FabioFracassi
Well since there were ~30-50 regulars on the committee before 2012 and
attendance is now closer to ~100 (can't find the source now, IIRC one of Herbs
talks) it is quite easy to see that there is lot of "fresh blood".

------
krylon
Just this week, I had to perform some maintenance programming on an
application written C++ in the mid- to late 1990s. It required Visual Studio
6.0 (!!!) to build. I do not know what features were supported back then, but
the application only made use of classes (no inheritance, though, except for
GUI stuff derived from library components) and new/delete. (I was really
lucky, the code I had to look at was highly readable.)

C++, where it goes beyond those simple basics, always gives me mixed feelings.
On the one hand, C++ has its good sides (Qt rocks, or at least it did the last
time I used it (around version 4.8)), but every time I approach C++, I seem to
succumb to the temptation of making things overly complex. I sometimes think
the biggest problem with C++ is not learning the language but developing the
discipline to use it properly (where "properly" might mean different things to
different people).

~~~
batou
Similar thoughts here.

The biggest problem for C++ that I see is that it has historically not had any
batteries included. That strokes the ego of an average programmer and gets the
creative juices flowing. Rather than doing discliplined research and picking
an off the shelf solution, you end up with a poor copy or incongruent
invention. Or even worse, some crap bolted onto MFC.

Roll on a few years later and the patterns haven't scaled well, the original
programmers have left after becoming frustrated with the corner they coded
themselves into and the only justifiable cost is to put 12 months of cash on
the table and start again because your business' greatest cash generator is a
hairball and you can no longer evolve it cost effectively.

The last three chunks of work I have done are to get companies out of these
situations. Not pretty and a loveless task, but for me I'm right at home. The
crimes I've seen are worst in the C++ and PHP areas. I suspect they suffer
from the same problems and most of the problems are caused by inexperience and
the ability to merely hit a few keys to generate a large hand grenade.

~~~
krylon
Part of the problem might be experience. A number of people seem to have come
to C++ from C, and the transition can be overwhelming.

PHP is on of the few languages I've met I truly dislike, but I have had only
very limited contact with it, and that was about 11 years ago, so I cannot
comment on the current state of affairs. (I do remember it did have good
documentation, though.)

I have had to take on other people's code a few times, but I was very lucky in
so far as the applications I inherited were written and organized in a very
sanity-preserving way.

------
TillE
I'm glad that expression SFINAE is at least coming in an update. I like all
the features of modern C++ that let you do dynamic-ish things at compile time.
The syntax isn't usually pretty, but at least the functionality is there.

~~~
StephanTLavavej
Yeah, being able to determine the validity of arbitrary expressions at compile
time is extremely useful for libraries. For example, it allows libraries to
sense the presence of member functions in user-defined types, calling them
when present and falling back to default behaviors when missing.

~~~
jjtheblunt
Like Objective C dynamic dispatch, without the runtime cost?

~~~
StephanTLavavej
Yes. In fact, the usual mechanism for doing so is referred to as tag dispatch.
For example, an algorithm can take an arbitrary Iterator type, and select
between a correct-but-slow algorithm for weak iterators like forward
iterators, and a fast algorithm for strong iterators like random-access
iterators. The easiest way to achieve this is to call a helper function and
pass a tag object whose type is iterator_traits<Iterator>::iterator_category,
which might be forward_iterator_tag or random_access_iterator_tag. The helper
function is then overloaded on those tags, achieving the effect of a compile-
time if. Everything optimizes away (the compiler is very good at noticing do-
nothing tag objects).

Expression SFINAE offers the ability to detect more properties of things, like
is_callable or has_member_function_meow. This can then be used in tag
dispatch, or other mechanisms (SFINAE can be used directly to dispatch, but
it's a more lengthy explanation).

------
pmelendez
Kudos for having constexpr in this release. In the previous post said that
constexpr wouldn't be completely ready in 2015. Great to see that wasn't the
case after all!

~~~
StephanTLavavej
It was a close call, but we got it done just in time. (It took a month and a
half to constexprize the STL. I went through 84 shelveset revisions, which
would be like feature branch checkins in git, and that's not counting the
numerous compiler fixes that Tanveer, our front-end dev working on constexpr,
checked in.)

~~~
pmelendez
Great job guys! Thanks for the effort! constexpr is an useful feature that
some library devs have been waiting for.

------
frozenport
Wacky Idea: First compiler to implement modules will out-innovate its
competition because it will be faster to build the compiler.

Maybe MS is slow to implement C++ features because they don't have modules?
Whats the compile time on MSVC?

~~~
pmelendez
I think some compilers already have modules as a language extension (not very
portable though)

[http://clang.llvm.org/docs/Modules.html#includes-as-
imports](http://clang.llvm.org/docs/Modules.html#includes-as-imports)

I have been in projects where a full build would be around an hour but mostly
because the dependencies. That said, I seldom performed a full rebuild so it
wasn't a huge deal for me. The major hassle is to wait for the build machine
when you are sending a version to QA.

------
peterfirefly
And C99?

~~~
albinofrenchy
[https://msdn.microsoft.com/en-
us/library/hh409293.aspx](https://msdn.microsoft.com/en-
us/library/hh409293.aspx)

2013 has a lot, and it looks like 2015 almost closes the gap. I'm content with
the 2013 additions, but I simply do not understand why c99 wasn't fully
supported 10 years ago, much less in the latest VS edition. C++ is better in
many ways but when you need to compile C specific code, it is incredibly
frustrating.

~~~
justin66
> I simply do not understand why c99 wasn't fully supported 10 years ago, much
> less in the latest VS edition

MSFT doesn't need it and 99% of the compiler's users do not need it. I'm not
happy about it but I can understand why it's not a priority for them.

