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.
jalf> Not counting a fix to the lambda implementation, and slightly less incomplete implementation of strongly typed enums.
* You have omitted the Standard spelling and semantics of override/final, a minor feature.
* I disagree with your phrasing of "slightly less incomplete". VC10 didn't have C++11's forward declared enums at all, and I listed its support of strongly typed enums as Partial only because it had explicitly specified underlying types. C++11's enum class was completely absent (ignoring managed code).
As the compiler's first and best customer, I want Core Language features more than anyone - I simply object to inaccurate generalizations. (Amusingly, the Standard Library is lagging with respect to strongly typed enums; we simulate them with nested namespaces. We attempted to use enum class during VC11's development, but ran into a problem where /clr gave enum class managed semantics, so we had to revert the changes. This was later fixed, but I never had time to go back and try using real enum classes again.)
I don't believe it, but I have no way to prove it as the poll on what feature was most in demand isn't publicly available. I don't believe that any serious C++ dev wanted range for over other MUCH more important features. I just don't believe it.
Secondly, you may disagree with what jalf said but none the less this is the facto the current state of affairs.
Thirdly, would you stop with this "I'm the best and first customer" cr*p? It's arogant, and ignorant (and I have strange feeling that it is a verbatim reflection of how you portray yourself as a C++ dev).
There are plenty of people who are:
a) better C++ devs than you
b) need better C++11 conformance than you
c) don't boast about how great they are and how important they are.
d) when they are interviewed they don't cut through (EVERY TIME) when interviewer didn't finish asking them a question. Maybe reflect on that?
Ok, so as you have always some smart as* answer to anyone who dares to disagree with you or critisize MS in anyway I'm looking forward to your smart as* answer.
@stl, I think jalf's comments, overall, accuately enough sum up the general community view of things to the extent that I wouldn't split hairs with him if I were you, just my opinion.
@KMNY, I think STL does a great job and your comments to him, don't do him any justice at all.
If you read STL's general responses to comments and bug reports in particular, he is consistent, thorough, and makes a good effort.
He deserves a promotion if anything, and your comments towards him don't reflect any of that relality at all, therefore, in my opinion, you are way off base.
@MS please find out who is in charge of the comment system, it is utter cr*p and has been broken like jalf says for ever. Everyone and their monkey has complained about it, but it's still not fixed, it still loses comments.
The web page timeout or something is just too short. Someone, please fix this.
@Glen would you ever get on... I didn't say anywhere that he doesn't do his job, did I? I just read what he says and very often he comes across as an arogant, ignorant and self congratulating smart as*. This has nothing, nothing to do with his technical skills/knowledge. I believe that he is good at what he does, but I also see that he is arogant and ignorant (plenty of examples). That's all. Those two things do not contradict each other. One can be skillful, arogant person, and I believe he is. But he is still young and he can change if he wants.
@Stephan T. Lavavej: The support of C++11 language features in VS2012 is a joke compared to gcc and clang. Just check wiki.apache.org/.../C%2B%2B0xCompilerSupport
@Glen: I agree with @'Knowing me knowing you, a-ha'. STL no doubt is competent in what he does, but he does appear to be arrogant at times.
@STL: oops, you updated the feature table? I wasn't aware range-based for loop was now in VC11. That's great news, and you're right, that's a significant feature, and I'm sorry I didn't take that into account.
About enums, I was wrong about part of it at least. According to the features table, it is completely implemented in VC11, and that's great. I remembered wrong, so thanks for correcting me.
However, about VC10, I stand by my claim: you (or whoever wrote the feature table) decided to list it as "partially supported". You can't have it both ways. You can't both say "VC10 was great for its time, it had partial support", and *also* "we implemented the feature completely from scratch in VC11". If it wasn't partially supported, then the feature table is just dishonest. Telling us that your team is willing to lie to us about its C++11 support probably isn't the way to win our hearts ;)
However, overall, I think it's clear that your team has had other priorities than C++11 support for the last two years (I'm guessing C++/CX), and that was the point I was trying to make. Sorry about the inaccuracies, and thanks for the corrections. :)
Yep, ninja update. Sorry, I never VCBlogged about it otherwise - there was a big reveal in my GoingNative presentation, but not everyone watches video. (JonCaves developed it over the weekends, I tested it exhaustively, and management was really very cool about letting this totally unplanned feature get checked in days before Beta lockdown. I felt a little bad when it became apparent that this was going to cause more work for the Intellisense team, who hadn't signed up for it.)
See my slides at channel9.msdn.com/.../STL11-Magic-Secrets (there is a link below the video), which cover range-for subtleties that you might not have thought of (efficiency, proxy iterators, etc.).
> you (or whoever wrote the feature table)
That post and its table were entirely my doing, except for title editing (I originally said "VC11" there), and table formatting (Diego ported my fancy coloring into the blog software which I still haven't figured out - observe the flat table here).
I dug through every single feature to figure out VC10 and VC11's support for it, in the process discovering minor inaccuracies in the previous version of my table. Any remaining errors are mine (e.g. I lumped uniform init into initializer lists, but they really deserve separate rows). And I still don't know how atomics interact with signal handlers (I said No support to be conservative).
> You can't both say "VC10 was great for its time, it had partial support", and *also* "we implemented the feature completely from scratch in VC11".
I didn't say that, and I'm very careful about how I use my words. In the original post, I said below the table:
"Strongly typed enums were partially supported in VC10 (specifically, the part about explicitly specified underlying types), and C++11's semantics for forward declared enums weren't supported at all in VC10. Both have been completely implemented in VC11."
This is objectively correct. Subjectively, I said nothing like "great for its time". I said "partially supported" and "weren't supported at all", respectively. I could have added that I would characterize explicitly specified underlying types to be maybe 20% of the feature (as a user). I also could have taken an explicit jab at VC's non-Standard (98/03/11) behavior of permitting forward declarations for enums without explicitly specified underlying types, but I resisted the temptation, referring only to "C++11's semantics".
Given that VC10 had ~20% and 0% of these features, and VC11 has 100% and 100%, I disagreed with "slightly less incomplete" (that would be a reasonable thing to say for 20% => 40%). That's all, and it's not a big deal. :->
> However, overall, I think it's clear that your team has had other priorities than C++11 support for the last two years (I'm guessing C++/CX), and that was the point I was trying to make.
Maybe it's a cultural expectation thing, where the 'hired help' should bow a few times.
Tangent bounce: Why only one dude doing this? I know Dinkum does the grunt work, but one dude? Need at least a helper or two.
@STL: yeah, once again, I was wrong in saying you'd made a "slightly less incomplete" implementation. It appears that VC11's implementation is complete. Sorry about that. :)
But once again, when you drew up the table, you chose to list VC10's support as "partial", and going by that, you didn't start from 0%. (If you did, then the table is incorrect in listing "partial" support)
Anyway, sorry for the exaggerations and inaccuracies. :)
I was unaware of your ninja edit, and remembered some other details wrong. serves me right for not checking my facts. My apologies.
oh, and just to be fair, unlike some other commenters, I don't doubt that range-based for loop is both a highly requested feature and a fairly big one to implement.
it's not at the top of my personal wishlist, but I know *a lot* of people are pining for it. So good job on implementing it. :)
Happy about the async bug fix. Thanks
@jalf, you were wrong before and you're wrong this time as well. Maybe for some kids range for is very important, but most devs treat this as a sugar which they can live without, or VERY easily make for themselfs by using "regular" for.
When I see comment like yours that something really trivial and already substitutable is very important I really wonder. Do you know other people who pining for range for? Wow, do you see them regularly in a sandbox every day?
I'm sorry, I don't want to attack you or be sarcastic, but there are SO, SO many other UNSUBSTITUTABLE features from C++11 not implemented, that when someone says what you've just said I see why this world is in such a mess.
In other words, kid've been promised/suggested motorbike but got shoes (and not really cool one, everyone else had them for at least few years now), even though the old one are in still pretty good condition. Kid is happy. Conclusion - kid is either very, very grown up for his age and understands that parents had bigger priorities and those consumed parents' resources or kid is mentally ill. I want to believe that you are the former.
I am wrong? Who are you to tell me that? How many C++ developers have you interviewed to determine that they don't care about the feature?
Most of the ones I've talked to put it near the top of their wishlist.
And it'd really suit you to ditch that attitude. You were a moron with a bad attitude on StackOverflow, and you haven't lost your edge. Why don't you just go sit in the corner for a bit? I haven't had any interest in talking to you ever since I encountered you there, and you're not doing anything to change it.
> When I see comment like yours that something really trivial and already substitutable is very important I really wonder. Do you know other people who pining for range for?
"other people"? What do you mean? I thought I said clearly that *I* personally don't care much for the feature. It's nice syntactic sugar, but not something I really want prioritized.
But yes, I do know a lot of people who want the feature. That is why I *said* that I know a lot of people want the feature.
Now, after your talk about kids and growing up, perhaps you, yourself, have some growing up to do? Then we can talk.
@jalf if anyone, it is you who is a moron, who doesn't know what he is talking about.
Just because I do critisize 9 out of 10 "things" it doesn't mean that I have bad attitude. The only thing it means that I have high standards and 9 out of 10 things are below it and I'm not satify it and I do express it.
As for stackoverflow? I stopped using it because it's (mostly with few notable exceptions) full of kids and morons like you who don't know what's really important.
And if you do not want to "talk" with me why did you ever mention me in your idiotic, apologetic and as* licking post?
I hope your castle was nice today, but if not, you can try and build another one tomorrow, maybe daddy could help you. And that's the place for you. Sandbox.
@Knowing me knowing you, a-ha: You went full retard, man. Never go full retard.