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 ) :)
Heh! Nobody's ever called me a collective entity before.
I just happen to enjoy writing and keeping track of these feature tables, which is why I publish them. My real work goes into STL features and fixes, which is just one part of a very large product that many other compiler and library devs work on.
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.
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?
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.
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.
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
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".
I'll have to look it up, but after ISO approved the 03 standard, the committee thought there was a waiting period before the next draft standard could be worked on, is my hazy recollection (there wasn't any wait period, but that took at least a decent chunk of time)
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).
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.
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.
> 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
I think it sounds like you need to crank out some C++ code for a few years (like any other language) before you start internalizing what works and what doesn't.
Full Disclosure: I am technically employed as a sysadmin, but before that, I worked as a programmer. I have only very little experience with C++; I have looked at it repeatedly over the years, but mainly by building small-time applications for my private amusement/education.
I do agree with you in that that it would probably take me a couple of years to get comfortable with C++. My point was that I feel it would take me substantially longer than it did with other languages.
Ah, okay, I see where you're coming from now. I write C++ code professionally, and I would never use it for a hobby project. It sounds like you're interested in learning, so I would advise you to just stick with it, if it's important enough to you (and probably add more languages to the mix). C++ offers unique performance benefits with a fairly high level syntax that reduces some of the tediousness of C. But it also suffers from reduced productivity when compared to other languages like say python or C#.
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.
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.
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).
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!
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.)
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.
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.
You know that's never going to happen. However, the parts necessary for C++ are implemented.
To quote the article, this is what is missing: "Our C99 Standard Library implementation is complete, except for tgmath.h (which is irrelevant in C++) and the CX_LIMITED_RANGE/FP_CONTRACT pragma macros."
Thanks for being great at outreach.