After Pat's post last week about MFC bugs fixed in Visual Studio 2012 (aka VC11), I thought that a similar list for the STL would be interesting:
A few notes on various arcane topics:
This list of 127 bugs consists of all of the bugs that I could find in our "old database" and "new database" (we use Team Foundation Server for bug tracking and version control, but we switched TFS databases a couple of years ago, making archaeological expeditions "fun") which were created by Connect, filed against the C++ Standard Library, resolved by me as Fixed, and fixed between VC10 SP1 and VC11 RTM. It's reasonably comprehensive, but it might not be absolutely exhaustive. I have intentionally excluded all non-Connect bugs (the grand total of fixed bugs found by Connect, myself, and other MS employees is roughly 330 - and that doesn't count things that were really bugs but never tracked as such) and private Connect bugs (a few people who file Connect bugs mark them as private, which prevents the world from seeing them - I recommend against doing this unless the bug's repro somehow contains information that you don't want the world to see). Additionally, I have made no attempt to group bugs resolved as fixed that are actually duplicates (e.g. the many uniform_int_distribution bugs, fixed by a comprehensive rewrite).
I have presented the bugs' original titles from their submitters, although they're often renamed internally. This is almost never interesting (there is a certain format that I like, so my bugs sort nicely), but I can share one exception. Connect#533464 arrived as "The <initializer_list> header in the VC10 release candidate". I improved this to "<initializer_list>: Zombie header hungers for our delicious brains". (In VC10, I screwed up by leaving a nonfunctional <initializer_list> header in the product.)
Finally, you may be wondering where all of these bugs come from. (I take all STL bugs personally, and I'd hate for someone to see this list and go around thinking "wow, the STL sure is buggy".) Our STL implementation is very solid, but it is also very large and must deal with an enormous variety of complicated situations. C++11 churn has led to two categories of bugs: those where the Working Paper said something bogus at the time that we implemented it (e.g. this happened with to_string(), bitset, and async()), and those where it permits more complicated inputs than we've had to deal with before (typically rvalue references and movable-only types). Totally new features (e.g. atomics/threads/futures) arrive with totally new bugs. There's the perennial gotcha of users doing "weird stuff" (e.g. obscure compiler switches like /J and /vd2). And because the STL has no control over how demanding its users' performance requirements are, things that would be evil premature optimizations in ordinary application code are treated as totally legitimate performance bugs in the STL. (A number of micro-optimizations in vector were suggested by a user and implemented in VC11, for example.)
The bottom line is that we're continuously improving the STL, so you should always upgrade to the latest major version and service pack as soon as possible - and that reporting bugs through Microsoft Connect really helps.
@Never, yes, you may be right there. Maybe I shouldn't. But I'm relly fed up with smart asses/douchebag like jalf who don't even have the ba*l to tell me straight to the face that he disagreeing with me, and instead he mentiones me indirectly as a "someone". I do agree with you that I went full retard. Fair enough. But jalf went full old, used wh*re.
STL, this is an impressive list of bug fixes. Some changes are obvious new features (new C++11 support), as well as optimizer improvements that don't appear on the list, and it makes sense for those to show up as a new product version. But I feel that the actual bug fixes, especially ones which were noted during the RC and simply missed the triage bar, should be released at no charge as part of a Service Pack. Can you please pass that up to your management?
It'd be nice to be able to go back and fix some of this stuff in VC10, and it's painful to have to tell people to wait for VC11, but there are reasons why we work like this.
* We break binary compatibility between major versions, but preserve it between hotfixes and service packs. Therefore, we can't hotfix/SP anything that affects the interface of separately compiled code. Unlike other libraries, the STL's separately compiled part is fairly small (and it got smaller in VC10 when I ripped a bunch of stuff out of the DLL), but it's nonzero and some of the scariest stuff (i.e. locales) lives in there.
* Shipping individual hotfixes is enormously, psychotically expensive. The fix has to be individually tested, packaged, and then tested in its packaged form. (The packaging process is also incredibly complicated, and usually explodes multiple times.) I had to do one for VC10 (limited release, not general) and it took something like a week of my time, on and off.
* Getting fixes into a service pack is not quite as onerous, but service pack scheduling is a division-wide thing.
* Most importantly, fixing stuff outside of a major release cycle (a) takes time (that we could be using to improve the next major version), (b) really needs to avoid making things worse, and (c) needs to involve a really small, targeted fix. In general, I view all compilation errors as not meeting the bar for a service pack (unless they are astoundingly bad). Runtime errors may qualify, but they have to be really bad and in really common code. That's why we fixed 3 STL bugs in VC10 SP1 (the std::string memory leak, the vector::erase debug assert, and the is_sorted_until bogus result).
There is some human judgment involved here - I pushed for the debug assertion to be fixed even though it could be avoided with a simple code change and didn't affect release mode, because it really made people miserable and made them want to turn off IDL=2.
I hope this clarifies things. We aren't trying to be mean by keeping delicious fixes from you until you pay for a major version (or get Express, etc.). It's just that fixes have to get through a bunch of filters (preserving binary compatibility, reported early enough to make it into a service pack, severe enough to merit the risk/time involved in fixing it, yet with a simple fix whose correctness we can absolutely swear on), so very few do. These constraints do not apply to major release cycles (except at the very end) - we can get away with very risky rewrites because there's time to go back and glue together the pieces (as happened to locales multiple times, etc.).
Hey Stephan, that's a positive communication, thanks!
Some days I'm really surprised about the activity of the C++ community. To be fair, I use std::regex often but finding the following bug (connect.microsoft.com/.../641845) really states that there is interest in the C++11 features in the community.
These communications as useful, don't mind "Knowing me knowing you, a-ha". You are not arrogant at all, your posts and videos are very comprehensive and to the point. In the list I found bugs I didn't realized they were there, and I used the functionality. Must have been lucky :).
One of the things that I've learned about the STL by maintaining it for the last 5 years is that everything is used by somebody. Even valarray.
Steve: appreciate all your great work on the STL, keep it up
The blog system running on blogs.office.com, blogs.msdn.com, windowsteamblog.com etc. is a product of "Telligent" corp.
I have reported this bug to Ted Johnson -> Microsoft IE blogger. He reffered me to the guys responsible at telligent team. I sent them the whole list of bugs including:
- The session timeout (15 minutes for anonymous users and unlimited for signed-in users)
- Lack of error & warning notifications
- Lack of retaining the message in the <textarea> when the page is refreshed without posting your comment
- If the message was moderated out due to inappropriate statement show notification while retaining the message in the textarea with "consider-reviewing" notification, so the user can edit
The bug reports on telligent issue tracker are still opened (T00020087 & T00020932 on 04/26 and 06/23 respectively). Never heard back from them. If you know someone personally in Telligent, please ask him to escalade these annoying bugs in their product.
Talking about a decent blogging system, there are number of blog system example (with source code) on MSDN tutorials for ASP-MVC3 Entity Framework alone!! So why don't they just deploy one of their own example rather buying the product from crippled Telligent... Looks like someone at Microsoft has made a fishy deal with Telligent guys.. *mutual benefits*.. Microsoft needs to laywer up and sue his caboose... (pardon my French)...
Talking about a decent blogging system, there are number of blog system example (with source code) on MSDN tutorials for ASP-MVC3 Entity Framework alone!! So why don't they just deploy one of their own example rather buying the product from crippled Telligent... Looks like someone at Microsoft has made a fishy deal with Telligent guys.. *mutual benefits*.. Microsoft needs to laywer up and sue his ca'boose... (pardon my French)...