STL Bugs Fixed In Visual Studio 2012

STL Bugs Fixed In Visual Studio 2012

Rate This
  • Comments 38

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:

ID Title
492128 std::locale constructor modifies global locale via "setlocale()"
492561 STL streams cannot be used concurrently
498533 iostreams should use codepage of their imbued locales instead of the current c locale
506966 New warning 4986 prevents clean compile at warning level 4
524342 Implement std::max_align_t in Visual C++
532883 Visual C++: int_fast8_t Not Always Signed
532897 Problems constructing a bitset from an unsigned long in the VC RC
533131 Bug in std::deque. Non-conforming invalidation of iterators after pop_front()
533464 The <initializer_list> header in the VC10 release candidate
534457 C++ map<tuple<...>, V> compilation problems
534756 std::is_function does not work on rvalue reference types
539946 search_n fails with a Debug Assertion
540098 Problem with non-const operator() and bind
540813 Add support for the new C++0x library
541226 C++ Defect Report 445 Implementation
548693 Visual C++: numeric_limits<char> min/max incorrect when using /J
552541 Library or compiler bug with Visual C++ 2010
553629 Visual C++ forces conversion to char in push_back
556348 C++ compiler NULL broken??
557117 std::unordered_set equality comparison broken in Visual C++ 2010
558044 std::copy should not check _Dest when _First == _Last
558339 tr1:regex has different behavior between vs2008 and vs2010 on some regular expression
558993 std::pair members are not members of std::pair
560987 In Visual C++ 2010, std::tr1::shuffle_order_engine incorrectly defines min and max members, rendering the class (and std::tr1::knuth_b) unusable
560994 In Visual C++ 2010, std::tr1::discrete_distribution and std::tr1::negative_binomial_distribution are missing nested input_type types, making them unusable with std::tr1::variate_generator
565500 Crash in C++ runtime when compiling with /MDd and /vd2 switch
565748 Include support compile-time rational arithmetic specified in C++0x
566516 std::ifstream/std::ofstream change double value
567859 Visual C++: std::unordered_map Destructor Performance in Debug Configuration
568054 std::use_facet interferes with subsequent call to FatalExit
569997 [VC10] Compiler refers to std::shared_ptr as std::tr1::shared_ptr
571397 C++ setfill Can't Be Applied To wofstream - Irritating Error Message
576750 [C++0X] std::to_string is non conforming
577672 iterator assignment operator crashes in debug builds due to stl changes in vc10
596771 type_info::before returns type of int and not bool
598887 const const_iterator cannot be supplied to set::insert
603381 VS2010 STL for_each implementation breaks existing code
606746 Incorrect Overload Resolution
612692 std::bitset
616702 operator>> for basic_istream crashes with multibyte character set as locale
616827 Nested std::bind functions give bad error (with no reference to the file being compiled)
618807 Calling a bound lambda through a std::function variable
621653 Including stdint after intsafe generates warnings
626291 STL hash element cannot hash custom allocated strings
627639 std::fstream use 32-bit int as pos_type even on x64 platform
628197 std::string::erase is stupidly slow when erasing to the end, which impacts std::string::resize
633809 std::thread
633905 Visual C++: Ill-Formed unique_ptr Function Call Syntax
635833 std::uniform_int_distribution and std::uniform_int not returning correct values
635837 Low value of std::uniform_int_distribution and std::uniform_int not appearing when it's set to a negative number
640602 VS2010 Debugger: watching std::string with _ITERATOR_DEBUG_LEVEL = 0 does not work
640619 Move-construction can slice objects
640961 Visual C++: Argument Forwarding Bugs in std::bind Function Callers
641845 std::regex bug in vs2010
642277 std::regex bug in vs2010
642557 [random] uniform_int_distribution can produce out of range results
642600 system_error::what() returns incorrect value
645116 VC10 STL: emplace functions are not implemented for more than 1 parameter
645641 tr1 regex crashes in debug builds due to illegal use of iterator
646532 strsafe.h triggers many warnings with STL header files
648543 tr1::regex doesn't match a valid pattern with repetition
649268 std::bind and std::function generate a crazy number of copy.
649274 std::bind and std::function are not move-aware
649531 Compile error when explicitly instantiating shared_ptr
650567 Unhomed std::locale::facet and std::locale::_Locimp destructors cause crashes
651285 std::ref works incorrectly with classes that overload operator &
668921 std::numeric_limits<float>::max_digits10 value of 8 is wrong and should be 9
671328 Visual C++: User-Defined Bind Expressions with std::bind
674424 tr1 regex case-insensitive search not working
674652 non-conformant behavior of std::minmax in MSVC 2010
680313 std::merge invalidates source data because it uses move semantics
683483 MFC C++ fails to compile use of codecvt_utf8 in Debug Configuration
685726 INT64_C and UINT64_C should be defined in more cross-platform way
688731 std::bind with std::reference_wrapper<T> argument doesn't work on function object with template operator()
688797 std::thread crashes with error "f:\dd\vctools\crt_bld\self_x86\crt\src\thr\mutex.cpp(206): unlock of unowned mutex"
689342 unordered_map thousand time slower than the vc++ 2010 version
689689 Visual C++ (VS2010): Incorrect returned value of uniform_int_distribution
692248 Visual C++ ostringstream & ios_base::app broken
692988 std::vector::resize should take a const reference
694663 Check inside std::vector::_Reserve() triggers integer underflow and fails to detect invalid parameter passed to std::vector::resize()
694704 std::vector::reserve() contains a suboptimal check against max_size
694705 std::vector::_Insert() contains a suboptimal check against max_size
694881 std::vector::_Reserve() contains a suboptimal check against max_size
694887 std::vector::_Insert_n() contains a suboptimal check against max_size
695529 std::exception_ptr does not satisfy the requirements of NullablePointer
696109 std::pair move constructor not standard conformant, potentially dangerous behavior for pair of references
696151 std::reference_wrapper does not work with lambda functions
696316 Typo in std::deque::resize() comment
698286 std::begin and std::end ADL lookup failure
705089 C++ std::atomic<> missing constructor
705152 This instantiation of std::codecvt template does not meet standard requirements for std::codecvt::out
705993 Incorrect Type Name references in defaultvis.natvis visualizers for standard library
707067 Failed to parse expression: class "std::_Ref_count_base" has no member "Uses"
712897 Invalid ## arguments in _VAR_TYPE in xstddef
712984 std::uniform_int_distribution produces incorrect results when min0 is negative
714853 valarray operator[] const
716468 Heap corruption when CObject-derived class throws from constructor when being called from make_shared
716995 std::make_shared needs default constructor to compile
718865 STL: hypot not hoisted into the std namespace by cmath
721456 Debugger cannot display content of the std::string - "<Error reading characters of string.>"
721786 stdint.h UINTPTR_MAX has the same value as UINT32_MAX for 64-bit platforms
723427 Compile error in mutex
726398 Creating threads using std::thread class causes application crash
727368 std::reference_wrapper fails to wrap reference to object of abstract class
727374 std::exception_ptr only partially comparable to null
729760 std::async fails compilation for Callable with two or more arguments.
730454 Emulation of variadic templates in C++11 standard library does not work
732529 std::result_of not working with functors
733204 std::map Debug Visualisers not working for vs2011
733222 Compiler error on <mutex>:304
733729 debug assertion "string subscript out of range" is incorrect for [size()]
734888 shared_ptr in unordered_set
735224 VS2011 Beta fires assertion about unlocking of unowned mutex
735731 std::async(std::launch::async, ...) does not behave as std::thread(...)
735732 STL Vector of Vector Insertion Problem
735875 Wrong output in std::put_time
736356 No more than two arguments can be passed to <future> : async.
736924 Packaged task & thread compile error bug
737812 std::thread does not accept std::move
738919 std::locale::global() / std::locale() thread-safety issue
739016 std::make_shared call error (c++)
742642 Ambiguous use of the overloaded function std::string to_string(int val);
742856 BUG with std::async ?
742965 Operator < incorrect for tuples with more members than _VARIADIC_MAX
745614 <system_error>: error C2382 when compiling with '/Za' (Disable Language Extensions)
745643 error C2382 on "std::generic_category", "std::iostream_category", "std::system_category"
745967 Compiler Error C2382 with Standard Header File <system_error> in Visual C++ 2012 RC

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.

Stephan T. Lavavej
Senior Developer - Visual C++ Libraries


  • jalf> Not counting a fix to the lambda implementation, and slightly less incomplete implementation of strongly typed enums.

    * You have omitted the range-based for-loop. It was a major feature, both in terms of user demand and complexity of implementation.

    * 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.)

  • stephan> You have omitted the range-based for-loop. It was a major feature, both in terms of user demand and complexity of implementation.

    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

    @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

    @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 (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.

Page 2 of 3 (38 items) 123