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.
Interesting - I published this just now (6/20), but the apparent date is when I created the draft (6/15). I consider that to be a bug!
Oh man, that to_string() definition has been *super annoying*. I wish I didn't have to support XP so I could take up these fixes (I'm not blaming you for that, and I'm aware of the post-release update announced, which is nice). Nice to see DRs actually leading to a better language to use.
You probably know this already, but there's a workaround for to_string() (that will compile with the conformant overload set too): static_cast to long long or unsigned long long. It's definitely annoying, though!
@STL: don't start tracking bugs in your blogging software. Down that path lies misery and pain.
The bug where comments just disappear when you post them, with no error message or anything, has been there for 3-4 years now. A blogging platform which can't handle comments probably can't be trusted to get post dates right either... ;)
I think most people have given up on ever getting that fixed. If you know who's responsible, it'd be nice if you could wake them up... :)
(It just happened again when posting this comment. Good thing I've made a habit of copying my comments to the clipboard before submitting them on a MSDN blog. Talk about hard-learned lessons ;))
Excellent! Thank you.
there is bug in std::vector.back() . VS11 beta express windows phone.
in case myVector.size() > 1, call myVector.back() will crash ,but myVector.at(myVector.size()-1) is work. is this call same index ? . my code work fine in vs 2008.
@jalf : yeah , I entered and retyped comment twice.
There is a phone version of 11? Where is the phone version of 11? How would I get the phone version of 11? Is this the 8 version of phone version of 11? Where is the 8 version of phone version of 11? How would I get the 8 verion of phone version of 11?
jalf> If you know who's responsible, it'd be nice if you could wake them up... :)
I don't, unfortunately.
crexedi> there is bug in std::vector.back()
Please provide a self-contained test case so I can see what you're seeing. back() is one of the simplest functions in the world, so the bug must be elsewhere (possibly in your code).
I do that TOO! I have had too many well crafted MSDN blog comments go up in smoke. Now I always, always, alwasy copy my comment to the clipboard before I post it. I find about 1 in 5 don't get posted.
<Ctrl+a, Ctrl+c, Post>
Nice post - thanks! It was good to see my <deque> issue on there.
Great to see MS investing (i know not how much resources however some is better than none) on it's C++ Libraries(MFC/ATL, STL). Keep up the good work, WinRT looks excellent from a C++ developers view if one bothers to delve into what the compiler is generating for you, now if MS would put a little effort and port that technology to be used on their classic com stack (i know classic com == IUnknown , WinRT == IInsepctable) and enable developers to use true c++ exception handling and modern c++ semantics for desktop development as well. Stephan is doing excellent work on the STL, Pat is churning out fixes for the MFC. The compiler team has been churning out features of the C++ 11 standard (I know the community at large is screaming for complete conformance , I say to them pick up a book on compiler development, and if one feels compelled enough to post nasty comments to the VC team, implement a compiler yourself. Come back in 2 years time and we'll see how much of the C++ 11 features THEY get implemented). Overall Keep up the good work MS!
I just saw it today. std::greater is not available in algorithm header ? I could not compile the code using std::greater. Not sure if I am missing something.
Sorry for the earlier comment. I found it in <functional>.
David: That deque bug was very tricky, thanks for reporting it - we wouldn't have found it otherwise.
Johnathon> now if MS would put a little effort and port that technology to be used on their classic com stack
Have you looked at WRL, about which I know virtually nothing? (I know more about C++/CX because of writing collection.h, although my interaction with Windows 8 has never extended beyond writing console programs that print PASS or FAIL.)
Sai Jagannath> std::greater is not available in algorithm header ?
The Standard says that STL headers include each other in unspecified ways. This means that users should always be careful to include the headers that the Standard says they need, instead of depending on header X to drag in header Y. We can, have, and will break such assumptions. The natural tendency is for every header to want to include every other header (only circular dependencies get in the way), but enormous header dependencies lead to slower compiles so we try to avoid the worst of it. Dragging in all of <functional> (which is really, really big after TR1 and C++11 got their hands on it) when only std::less is needed makes the compiler team (rightfully) complain that we're making them slower, so we've taken steps to put various machinery in sub-headers that we can include individually.
This is notoriously true for string, where we put basic_string in a subheader (<xstring>, and please DO NOT include internal headers directly), while its operators live in the public header <string>. This leads to people accidentally dragging in just basic_string, but not its operators, and being confused when op+ or op<< don't work.
@Johnathon: I think this topic has been pretty thoroughly beaten into the ground already, but...
> The compiler team has been churning out features of the C++ 11 standard
Are they? The common complaint is not "you don't yet have full C++11 conformance, shame on you", but "you basically haven't improved VC11's C++11 core language support over VC10".
In short, they have *not* been churning out features of the C++11 standard. We are basically where we were two years ago. Not counting a fix to the lambda implementation, and slightly less incomplete implementation of strongly typed enums.
There might be a million good reasons for this, or a million reasons to expect this to change in the future. But no, so far, they have not been "churning out features of the C++11 standard". Let's be honest. They haven't.