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
stl@microsoft.com

 

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

  • @jalf

    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.

Page 1 of 3 (38 items) 123