{"id":20925,"date":"2018-09-18T17:04:15","date_gmt":"2018-09-18T17:04:15","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/vcblog\/?p=20925"},"modified":"2019-02-18T17:47:42","modified_gmt":"2019-02-18T17:47:42","slug":"stl-features-and-fixes-in-vs-2017-15-8","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/cppblog\/stl-features-and-fixes-in-vs-2017-15-8\/","title":{"rendered":"STL Features and Fixes in VS 2017 15.8"},"content":{"rendered":"<p>15.7 was <a href=\"https:\/\/blogs.msdn.microsoft.com\/vcblog\/2018\/05\/07\/announcing-msvc-conforms-to-the-c-standard\/\">our first feature complete C++17 library (except floating-point &lt;charconv&gt;)<\/a>, and in 15.8 we have addressed large numbers of outstanding bugs. As usual, we\u2019ve maintained a detailed list of the STL fixes that are available. Visual Studio 2017 15.8 is available at <a href=\"https:\/\/visualstudio.microsoft.com\/vs\/\">https:\/\/visualstudio.microsoft.com\/vs\/<\/a>.<\/p>\n<h6>New Features<\/h6>\n<ul>\n<li>Implemented floating-point <code>from_chars()<\/code> in C++17 &lt;charconv&gt;. It&#8217;s approximately 40% faster than the CRT&#8217;s <code>strtod()<\/code>\/<code>strtof()<\/code>.<\/li>\n<li>Implemented C++20 feature-test macros in the compiler and STL (except for <code>__has_cpp_attribute<\/code> which will be implemented in the future). The feature-test macros are always provided regardless of the Standard mode option (<code>\/std:c++14<\/code> vs. <code>\/std:c++17<\/code> etc.) &#8211; that is, individual feature-test macros are defined (or not) according to the Standard mode option and fine-grained options, but there&#8217;s no option for enabling or disabling feature-test macros in their entirety.<\/li>\n<li>Implemented <code>std::is_aggregate<\/code>.<\/li>\n<li>Added officially supported hooks to allow user iterator type interaction with iterator debugging, already in use by the Guidelines Support Library. See <code>gsl::span<\/code> for an <a href=\"https:\/\/github.com\/Microsoft\/GSL\/blob\/1995e86d1ad70519465374fb4876c6ef7c9f8c61\/include\/gsl\/span#L264\">example implementation of the following customization points<\/a>, or the type <code>_String_view_iterator<\/code> in the internal header <code>&lt;xstring&gt;<\/code>.<br \/>\nThe customization points are, given a <code>const user_iterator_type cit<\/code>; and a <code>user_iterator_type it<\/code>:<\/p>\n<dl>\n<dt><code>_Verify_range(cit, cit)<\/code><\/dt>\n<dd>Requests that the iterator type check that the parameters form a valid [First, Last) range iterator pair. The standard library provides a version for pointers under <code>_ITERATOR_DEBUG_LEVEL != 0<\/code>. We strongly recommend this customization point be implemented as a &#8220;hidden friend function&#8221;, as demonstrated in the <code>gsl::span<\/code> example.<\/dd>\n<dt><code>cit._Verify_offset(difference_type off)<\/code><\/dt>\n<dd>For random-access iterators, verifies that <code>cit + off<\/code> is a valid iterator. Typically used to provide better diagnostics of the form &#8220;the iterator range passed to this algorithm was invalid&#8221; rather than &#8220;the iterator was incremented off the end of the range&#8221;.<\/dd>\n<dt><code>static constexpr bool user_iterator_type::_Unwrap_when_unverified<\/code><\/dt>\n<dd>Declares to the standard library whether an iterator type wants to be &#8220;unchecked&#8221; or &#8220;unwrapped&#8221; even if it can&#8217;t be verified in advance by <code>_Verify_range<\/code> or <code>_Verify_offset<\/code>. For example, the standard containers set this to true if and only if <code>_ITERATOR_DEBUG_LEVEL == 0<\/code>. This allows an iterator type to request range checks even in release builds (as desired by <code>gsl::span<\/code>). If this member is not present, it defaults to false.<\/dd>\n<dt><code>cit._Unwrapped()<\/code><\/dt>\n<dd>Returns an &#8220;unchecked&#8221; or &#8220;unwrapped&#8221; iterator denoting the same element as <code>cit<\/code>. This will be called by the standard library after a <code>_Verify_range<\/code> or <code>_Verify_offset<\/code> call, or if <code>_Unwrap_when_unverified<\/code> is true.<\/dd>\n<dt><code>it._Seek_to(cit)<\/code> \/ <code>it._Seek_to(<em>return value from <code>_Unwrapped()<\/code><\/em>)<\/code><\/dt>\n<dd>Moves the position of the &#8220;wrapped&#8221; or &#8220;checked&#8221; iterator <code>it<\/code> to the position of the &#8220;unwrapped&#8221; \/ &#8220;unchecked&#8221; iterator supplied. This is generally not intended to perform range checks. This allows algorithms that return iterators like <code>std::fill_n<\/code> to form their return values without needing each iterator operation in the body of the algorithm to be subject to debugging checks.<\/dd>\n<\/dl>\n<li>The header structure of the STL was changed to allow use of a subset of the library in conditions where the user can&#8217;t link with msvcp140.dll, such as driver development. (Previously the hard dependency on msvcp and pragma detect mismatch were injected by our base configuration header included by everything.) The following headers are now considered &#8220;core&#8221; and don&#8217;t inject our runtime dependencies (though we do still assume some form of CRT headers are present):\n<ul>\n<li>&lt;cstddef&gt;<\/li>\n<li>&lt;cstdlib&gt;<\/li>\n<li>&lt;initializer_list&gt;<\/li>\n<li>&lt;ratio&gt;<\/li>\n<li>&lt;type_traits&gt;<\/li>\n<\/ul>\n<p>We aren&#8217;t actually driver developers ourselves and are interested in feedback in this area if there are things we can do to make these more usable in constrained environments.\n<\/ul>\n<h6>Correctness Fixes<\/h6>\n<ul>\n<li>Implemented Library Issues <a href=\"https:\/\/cplusplus.github.io\/LWG\/issue2510\">2510<\/a>, <a href=\"https:\/\/cplusplus.github.io\/LWG\/issue2729\">2729<\/a>, and <a href=\"https:\/\/cplusplus.github.io\/LWG\/issue2958\">2958<\/a> for <code>pair<\/code> and <code>tuple<\/code>, constraining their assignment operators. This implementation contained a minor regression affecting assignments to <code>std::pair<\/code> from a type that implicitly converts to <code>std::pair<\/code>. We&#8217;ve fixed that regression for VS 2019 16.0 and are planning to backport the fix to VS 2017 15.9. In the meantime, if you encounter that compiler error, explicitly converting to <code>std::pair<\/code> is a workaround.<\/li>\n<li>Because user iterators can now officially participate in the iterator debugging system, the <code>_SCL_SECURE_NO_WARNINGS<\/code> family of warnings has been removed. The previously-pseudo-documented struct <code>_Is_checked_helper<\/code> remains present in order to avoid breaking user specializations, but it is no longer used by the library directly.<\/li>\n<li>Changed <code>num_get<\/code> overloads to store default values in the event of a failed parse, as the standard requires.<\/li>\n<li>Fixed incorrect values <code>numeric_limits&lt;<em>integral<\/em>&gt;::is_modulo<\/code> and <code>numeric_limits&lt;<em>floating-point<\/em>&gt;::tinyness_before<\/code>.<\/li>\n<li>Rewrote several streambuf operations to resolve cases where the streambuf would become confused; for example, cases where <code>seekg(0)<\/code> would not reset the streambuf position even when the current offset was nonzero.<\/li>\n<li>Fixed cases where <code>basic_filebuf<\/code> would become confused when set to some multibyte locales; the lead byte table was populated using the &#8220;fake POSIX support&#8221; locale function <code>_ismbslead<\/code>, but then used the standard locale function <code>_isleadbyte<\/code> later in processing, corrupting the state of the <code>basic_filebuf<\/code>.<\/li>\n<li>Fixed conditions where one could form a corrupted <code>basic_stringbuf<\/code> (or <code>stringstream<\/code>) by forcing it to attempt to represent a string of more than <code>INT_MAX<\/code> characters. The <code>INT_MAX<\/code> size restriction unfortunately must remain due to ABI compatibility, but at least we now consistently enforce that restriction.<\/li>\n<li>Overhauled <code>std::ws<\/code> to Do What The Standard Says.<\/li>\n<li>The off-by-default warning C4365 &#8220;conversion from &#8216;type_1&#8217; to &#8216;type_2&#8217;, signed\/unsigned mismatch&#8221; is now supported by the STL.<\/li>\n<li>Fixed a case C4365 found in <code>put_money<\/code> where a narrowed <code>wchar_t<\/code> was emitted instead of the proper raw <code>wchar_t<\/code>.<\/li>\n<li>Fixed creating an <code>istreambuf_iterator::proxy<\/code> returning the value stored in the proxy rather than returning the value one would expect from a copied <code>istreambuf_iterator<\/code>.<\/li>\n<li>Fixed a case where <code>linear_congruential_engine<\/code> would use <code>unsigned int<\/code> to do intermediate calculations even when <code>unsigned int<\/code> could not properly store the intermediate values.<\/li>\n<li>Fixed <code>linear_congruential_engine::seed()<\/code> to Do What The Standard Says.<\/li>\n<li>Changed parallel algorithms&#8217; partitioning behavior to not special case the foreground thread, improving performance in situations where the system threadpool detects an I\/O bound workload and decides to oversubscribe the machine.<\/li>\n<li>Fixed a race condition in <code>std::async<\/code> that could cause crashes or deadlocks.<\/li>\n<li>Fixed C++17 <code>std::filesystem<\/code>&#8216;s support .obj containing a <code>__declspec(dllexport)<\/code>, causing unusual conditions like .exes with export tables.<\/li>\n<li>Fixed <code>recursive_directory_iterator::disable_recursion_pending()<\/code> not being reset after an increment operation.<\/li>\n<li>Fixed a long-standing bug that caused <code>aligned_storage<\/code> to treat requests for alignment greater than <code>alignof(max_align_t)<\/code> as requests for alignment equal to <code>alignof(max_align_t)<\/code>. We can\u2019t enable this fix unconditionally without breaking ABI since doing so changes layout of types with members whose type is a highly-aligned specialization of <code>aligned_storage<\/code>. As an interim solution until a future ABI-breaking release, compilation of programs that use highly-aligned <code>aligned_storage<\/code> produces a compile error explaining this issue and asking the user to define either <code>_ENABLE_EXTENDED_ALIGNED_STORAGE<\/code> to request the conforming-but-potentially-ABI-breaking behavior, or <code>_DISABLE_EXTENDED_ALIGNED_STORAGE<\/code> to request the previous incorrect-but-ABI-safe behavior.<\/li>\n<\/ul>\n<h6>Performance and Throughput Improvements<\/h6>\n<ul>\n<li>Fixed iterator wrappers like <code>move_iterator<\/code> and <code>reverse_iterator<\/code> defeating iterator debugging optimizations. These wrappers remained &#8220;checked&#8221; even after verified by algorithms. For example, <code>fill(someVectorOfInt.rbegin(), someVectorOfInt.rend())<\/code> will properly check the range and convert to <code>reverse_iterator&lt;int *&gt;<\/code> instead of staying a <code>reverse_iterator&lt;vector::iterator&gt;<\/code> as in previous releases.<\/li>\n<li>Changed several calls of <code>basic_string::append(1, ch)<\/code> to <code>basic_string::push_back<\/code> for micro-perf improvements in iostreams machinery.<\/li>\n<li>Implemented a fast path for binary I\/O in iostreams, <b>quadrupling<\/b> bulk I\/O performance.<\/li>\n<\/ul>\n<h6>Other Changes<\/h6>\n<ul>\n<li>Removed <code>_NOEXCEPT<\/code> and other internal non-Standard macros.<\/li>\n<li>Increased readability by consistently using <code>nullptr<\/code> in the STL&#8217;s headers.<\/li>\n<\/ul>\n<p>If you have any feedback or suggestions for us, let us know. We can be reached via the comments below, via email (<a href=\"mailto:visualcpp@microsoft.com\">visualcpp@microsoft.com<\/a>) and you can provide feedback via <a href=\"https:\/\/docs.microsoft.com\/en-us\/visualstudio\/ide\/how-to-report-a-problem-with-visual-studio-2017\">Help &gt; Report A Problem in the product<\/a>, or via <a href=\"https:\/\/developercommunity.visualstudio.com\/topics\/C%2B%2B.html\">Developer Community<\/a>. You can also find us on Twitter (<a href=\"https:\/\/twitter.com\/visualc\">@VisualC<\/a>) and Facebook (<a href=\"https:\/\/www.facebook.com\/msftvisualcpp\">msftvisualcpp<\/a>).<\/p>\n","protected":false},"excerpt":{"rendered":"<p>15.7 was our first feature complete C++17 library (except floating-point &lt;charconv&gt;), and in 15.8 we have addressed large numbers of outstanding bugs. As usual, we\u2019ve maintained a detailed list of the STL fixes that are available. Visual Studio 2017 15.8 is available at https:\/\/visualstudio.microsoft.com\/vs\/. New Features Implemented floating-point from_chars() in C++17 &lt;charconv&gt;. It&#8217;s approximately 40% [&hellip;]<\/p>\n","protected":false},"author":328,"featured_media":35994,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[216],"tags":[],"class_list":["post-20925","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-documentation"],"acf":[],"blog_post_summary":"<p>15.7 was our first feature complete C++17 library (except floating-point &lt;charconv&gt;), and in 15.8 we have addressed large numbers of outstanding bugs. As usual, we\u2019ve maintained a detailed list of the STL fixes that are available. Visual Studio 2017 15.8 is available at https:\/\/visualstudio.microsoft.com\/vs\/. New Features Implemented floating-point from_chars() in C++17 &lt;charconv&gt;. It&#8217;s approximately 40% [&hellip;]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/posts\/20925","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/users\/328"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/comments?post=20925"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/posts\/20925\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/media\/35994"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/media?parent=20925"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/categories?post=20925"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/tags?post=20925"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}