VS 2015 Update 2's STL is C++17-so-far Feature Complete

In VS 2015 Update 2, we’ve implemented every C++ Standard Library feature that’s been voted into C++11, C++14, and the C++17-so-far Working Paper N4567. (See the end of this post for Update 2 availability information.) Here’s the table:

Status	Std	Paper	Title
Update 2	C++14	N3462	SFINAE-Friendly result_of
Update 2	C++17	N4387	Improving pair And tuple
Up2 Win7+	C++17	N4508	shared_mutex (Untimed)
Up2 opt-in	C++17	P0004R1	Removing Deprecated Iostreams Aliases
Update 2	C++17	P0006R0	Variable Templates For Type Traits (is_same_v, etc.)
Update 2	C++17	P0007R1	as_const()
Update 2	C++17	P0013R1	Logical Operator Type Traits (conjunction, etc.)
Update 2	C++17	P0074R0	owner_less<>
Update 2	C++17	P0092R1	<chrono> floor(), ceil(), round(), abs()
Update 2	C++17	P0156R0	Variadic lock_guard
VS 2015	C++14	N3302	constexpr For <complex>
VS 2015	C++14	N3469	constexpr For <chrono>
VS 2015	C++14	N3470	constexpr For <array>
VS 2015	C++14	N3471	constexpr For <initializer_list>, <tuple>, <utility>
VS 2015	C++14	N3545	integral_constant::operator()()
VS 2015	C++14	N3642	UDLs For <chrono>, <string> (1729ms, “meow”s, etc.)
VS 2015	C++14	N3644	Null Forward Iterators
VS 2015	C++14	N3654	quoted()
VS 2015	C++14	N3657	Heterogeneous Associative Lookup
VS 2015	C++14	N3658	integer_sequence
VS 2015	C++14	N3659	shared_mutex (Timed)
VS 2015	C++14	N3668	exchange()
VS 2015	C++14	N3669	Fixing constexpr Member Functions Without const
VS 2015	C++14	N3670	get<T>()
VS 2015	C++14	N3671	Dual-Range equal(), is_permutation(), mismatch()
VS 2015	C++14	N3778	Sized Deallocation
VS 2015	C++14	N3779	UDLs For <complex> (3.14i, etc.)
VS 2015	C++14	N3789	constexpr For <functional>
VS 2015	C++14	N3887	tuple_element_t
VS 2015	C++14	N3891	Renaming shared_mutex (Timed) To shared_timed_mutex
VS 2015	C++17	N3911	void_t
VS 2015	C++17	N4089	Safe Conversions In unique_ptr<T[]>
VS 2015	C++17	N4169	invoke()
2015 opt-in	C++17	N4190	Removing auto_ptr, random_shuffle(), And Old <functional> Stuff
VS 2015	C++17	N4258	noexcept Cleanups
VS 2015	C++17	N4259	uncaught_exceptions()
VS 2015	C++17	N4277	Trivially Copyable reference_wrapper
VS 2015	C++17	N4279	insert_or_assign()/try_emplace() For map/unordered_map
VS 2015	C++17	N4280	size(), empty(), data()
VS 2015	C++17	N4366	Precisely Constraining unique_ptr Assignment
VS 2015	C++17	N4389	bool_constant
VS 2013	C++14	N3346	Minimal Container Element Requirements
VS 2013	C++14	N3421	Transparent Operator Functors (less<>, etc.)
VS 2013	C++14	N3655	Alias Templates For <type_traits> (decay_t, etc.)
VS 2013	C++14	N3656	make_unique()
VS 2013	C++17	N4510	Supporting Incomplete Types In vector/list/forward_list
N/A	C++14	N3924	Discouraging rand()
N/A	C++17	N4284	Contiguous Iterators

“N/A” means that these proposals altered the Standard’s wording, but did not physically affect implementers or users. I’ve listed them as Not Applicable for the sake of completeness.

We previously announced that compiler support for Expression SFINAE became Partial in Update 1. While it’s still Partial in Update 2, the compiler team was able to improve it to the point where the STL could carefully take a dependency on it. As a result, Update 2’s STL fully supports N3462 “SFINAE-Friendly result_of” and LWG 2132 “std::function ambiguity”. This is verified by exhaustive unit tests that run for every build. (LWG 2132 allows meow(function<void (int)>) and meow(function<void (int, int)>) to be overloaded, then meow() can be called with a lambda taking 1 or 2 ints, and the corresponding overload will be selected.)

A notable consequence of N4387 “Improving pair And tuple” is that tuples can now be brace-returned when it’s safe to do so. For example, { “cute”, “fluffy”, “kittens” } can be returned as tuple<string, string, string>, because std::string has an implicit constructor from const char *.

N4508 “shared_mutex (Untimed)” isn’t supported on XP/Vista-class OSes (both client and server). This is because our implementation of std::shared_mutex wraps SRWLOCK, and requires OS APIs that were introduced in Win7-class OSes. Like std::forward_list, the whole purpose of std::shared_mutex is to offer lower overhead at the cost of reduced functionality. Attempting to support XP/Vista with dynamic checks would compromise std::shared_mutex’s reason for existing. If you require XP/Vista support, you should use std::shared_timed_mutex, which offers strictly greater functionality.

P0004R1 “Removing Deprecated Iostreams Aliases” is opt-in. If you define _HAS_OLD_IOSTREAMS_MEMBERS to 0 project-wide, we’ll remove this old machinery (which was “born deprecated” in C++98). Similarly, LWG 2385 “function::assign allocator argument doesn’t make sense” is requested by defining _HAS_FUNCTION_ASSIGN to 0 project-wide, and N4190 “Removing auto_ptr, random_shuffle(), And Old <functional> Stuff” is requested by defining _HAS_AUTO_PTR_ETC to 0 project-wide. In future major versions, we intend to make these removals opt-out and then unconditional.

Now, I should mention some caveats. “Feature complete” doesn’t mean “literally every electron in the Standard”. We’re still missing a few things that are smaller than entire proposals:

* A very small number of constexpr occurrences are missing. The exhaustive list is: in C++11, mutex’s default constructor requires a major representation change (which we can’t ship in an Update). In C++14, error_category’s default constructor requires a minor representation change (also forbidden in 2015 Updates, but already fixed for the next major version). Finally, C++14’s min()/max()/minmax() for initializer_list and C++17’s min_element()/max_element()/minmax_element() inherently contain loops, so they require C++14 extended constexpr support from the compiler, which is not yet available.

* Our C99 Standard Library implementation is complete, except for tgmath.h (which is irrelevant in C++) and the CX_LIMITED_RANGE/FP_CONTRACT pragma macros.

* We’ve made substantial progress in implementing C++14/17’s Library Issue resolutions (see table below; Library Issues are bugs in the Standard itself), but 8 Library Issues fixed in C++14 and 11 Library Issues fixed in C++17-so-far remain to be implemented.

* More features will inevitably be voted into C++17 before its final publication, but we’re caught up as of this very moment.

* There are still bugs, which we’re working on fixing. (We’ve fixed approximately 36 STL bugs in Update 2 so far. I’ll post a changelog for the final release of Update 2.)

Here’s our Library Issue table:

Status	Std	Issue	Title
Update 2	C++14	LWG 2005	unordered_map::insert(T&&) protection should apply to map too
Update 2	C++14	LWG 2021	Further incorrect usages of result_of
Update 2	C++14	LWG 2132	std::function ambiguity
Update 2	C++14	LWG 2196	Specification of is_*[copy/move]_[constructible/assignable] unclear for non-referencable types
Update 2	C++17	LWG 2101	Some transformation types can produce impossible types
Update 2	C++17	LWG 2106	move_iterator wrapping iterators returning prvalues
Update 2	C++17	LWG 2127	Move-construction with raw_storage_iterator
Update 2	C++17	LWG 2217	operator==(sub_match, string) slices on embedded ”s
Update 2	C++17	LWG 2353	std::next is over-constrained
Update 2	C++17	LWG 2354	Unnecessary copying when inserting into maps with braced-init syntax
Update 2	C++17	LWG 2367	pair and tuple are not correctly implemented for is_constructible with no args
Up2 opt-in	C++17	LWG 2385	function::assign allocator argument doesn’t make sense
Update 2	C++17	LWG 2455	Allocator default construction should be allowed to throw
Update 2	C++17	LWG 2466	allocator_traits::max_size() default behavior is incorrect
Update 2	C++17	LWG 2469	Wrong specification of Requires clause of operator[] for map and unordered_map
Update 2	New	LWG 2549	Tuple EXPLICIT constructor templates […] will create dangling references
missing	C++14	LWG 2064	More noexcept issues in basic_string
missing	C++14	LWG 2078	Throw specification of async() incomplete
missing	C++14	LWG 2135	Unclear requirement for exceptions thrown in condition_variable::wait()
missing	C++14	LWG 2140	notify_all_at_thread_exit synchronization
missing	C++14	LWG 2203	scoped_allocator_adaptor uses wrong argument types for piecewise construction
missing	C++14	LWG 2210	Missing allocator-extended constructor for allocator-aware containers
missing	C++14	LWG 2252	Strong guarantee on vector::push_back() still broken with C++11?
missing	C++14	LWG 2350	min, max, and minmax should be constexpr
missing	C++17	LWG 1169	num_get not fully compatible with strto*
missing	C++17	LWG 2059	C++0x ambiguity problem with map::erase
missing	C++17	LWG 2063	Contradictory requirements for string move assignment
missing	C++17	LWG 2156	Unordered containers’ reserve(n) reserves for n-1 elements
missing	C++17	LWG 2219	INVOKE-ing a pointer to member with a reference_wrapper as the object expression
missing	C++17	LWG 2369	constexpr max(initializer_list) vs max_element
missing	C++17	LWG 2408	SFINAE-friendly common_type / iterator_traits is missing in C++14
missing	C++17	LWG 2415	Inconsistency between unique_ptr and shared_ptr
missing	C++17	LWG 2439	unique_copy() sometimes can’t fall back to reading its output
missing	C++17	LWG 2476	scoped_allocator_adaptor is not assignable
missing	C++17	LWG 2485	get() should be overloaded for const tuple&&
VS 2015	C++14	GB 9	Remove gets from C++14
VS 2015	C++14	LWG 2009	Reporting out-of-bound values on numeric string conversions
VS 2015	C++14	LWG 2094	duration conversion overflow shouldn’t participate in overload resolution
VS 2015	C++14	LWG 2097	packaged_task constructors should be constrained
VS 2015	C++14	LWG 2103	std::allocator_traits<std::allocator<T>>::propagate_on_container_move_assignment
VS 2015	C++14	LWG 2104	unique_lock move-assignment should not be noexcept
VS 2015	C++14	LWG 2112	User-defined classes that cannot be derived from
VS 2015	C++14	LWG 2144	Missing noexcept specification in type_index
VS 2015	C++14	LWG 2145	error_category default constructor
VS 2015	C++14	LWG 2162	allocator_traits::max_size missing noexcept
VS 2015	C++14	LWG 2174	wstring_convert::converted() should be noexcept
VS 2015	C++14	LWG 2176	Special members for wstring_convert and wbuffer_convert
VS 2015	C++14	LWG 2187	vector<bool> is missing emplace and emplace_back member functions
VS 2015	C++14	LWG 2193	Default constructors for standard library containers are explicit
VS 2015	C++14	LWG 2247	Type traits and std::nullptr_t
VS 2015	C++14	LWG 2268	Setting a default argument in the declaration of a member function assign of std::basic_string
VS 2015	C++14	LWG 2272	quoted should use char_traits::eq for character comparison
VS 2015	C++14	LWG 2275	Why is forward_as_tuple not constexpr?
VS 2015	C++14	LWG 2278	User-defined literals for Standard Library types
VS 2015	C++14	LWG 2280	begin / end for arrays should be constexpr and noexcept
VS 2015	C++14	LWG 2285	make_reverse_iterator
VS 2015	C++14	LWG 2301	Why is std::tie not constexpr?
VS 2015	C++14	LWG 2306	match_results::reference should be value_type&, not const value_type&
VS 2015	C++14	LWG 2315	weak_ptr should be movable
VS 2015	C++14	LWG 2324	Insert iterator constructors should use addressof()
VS 2015	C++14	LWG 2329	regex_match()/regex_search() with match_results should forbid temporary strings
VS 2015	C++14	LWG 2332	regex_iterator/regex_token_iterator should forbid temporary regexes
VS 2015	C++14	LWG 2339	Wording issue in nth_element
VS 2015	C++14	LWG 2344	quoted()’s interaction with padding is unclear
VS 2015	C++14	LWG 2346	integral_constant’s member functions should be marked noexcept
VS 2015	C++17	LWG 2129	User specializations of std::initializer_list
VS 2015	C++17	LWG 2133	Attitude to overloaded comma for iterators
VS 2015	C++17	LWG 2212	tuple_size for const pair request header
VS 2015	C++17	LWG 2234	assert() should allow usage in constant expressions
VS 2015	C++17	LWG 2365	Missing noexcept in shared_ptr::shared_ptr(nullptr_t)
VS 2015	C++17	LWG 2399	shared_ptr’s constructor from unique_ptr should be constrained
VS 2015	C++17	LWG 2400	shared_ptr’s get_deleter() should use addressof()
VS 2015	C++17	LWG 2401	std::function needs more noexcept
VS 2015	C++17	LWG 2403	stof() should call strtof() and wcstof()
VS 2015	C++17	LWG 2407	packaged_task(allocator_arg_t, const Allocator&, F&&) should neither be constrained nor explicit
VS 2015	C++17	LWG 2420	function<void(ArgTypes…)> does not discard the return value of the target object
VS 2015	C++17	LWG 2433	uninitialized_copy()/etc. should tolerate overloaded operator&
VS 2015	C++17	LWG 2440	seed_seq::size() should be noexcept
VS 2015	C++17	LWG 2442	call_once() shouldn’t DECAY_COPY()
VS 2015	C++17	LWG 2454	Add raw_storage_iterator::base() member
VS 2015	C++17	LWG 2458	N3778 and new library deallocation signatures
VS 2015	C++17	LWG 2464	try_emplace and insert_or_assign misspecified
VS 2015	C++17	LWG 2467	is_always_equal has slightly inconsistent default
VS 2015	C++17	LWG 2483	throw_with_nested() should use is_final
VS 2015	C++17	LWG 2484	rethrow_if_nested() is doubly unimplementable
VS 2015	C++17	LWG 2486	mem_fn() should be required to use perfect forwarding
VS 2015	C++17	LWG 2487	bind() should be const-overloaded, not cv-overloaded
VS 2015	C++17	LWG 2488	Placeholders should be allowed and encouraged to be constexpr
VS 2015	C++17	LWG 2489	mem_fn() should be noexcept
VS 2013	C++14	LWG 1214	Insufficient/inconsistent key immutability requirements for associative containers
VS 2013	C++14	LWG 2011	Unexpected output required of strings
VS 2013	C++14	LWG 2018	regex_traits::isctype Returns clause is wrong
VS 2013	C++14	LWG 2033	Preconditions of reserve, shrink_to_fit, and resize functions
VS 2013	C++14	LWG 2039	Issues with std::reverse and std::copy_if
VS 2013	C++14	LWG 2047	Incorrect “mixed” move-assignment semantics of unique_ptr
VS 2013	C++14	LWG 2049	is_destructible is underspecified
VS 2013	C++14	LWG 2050	Unordered associative containers do not use allocator_traits to define member types
VS 2013	C++14	LWG 2056	future_errc enums start with value 0 (invalid value f or broken_promise)
VS 2013	C++14	LWG 2061	make_move_iterator and arrays
VS 2013	C++14	LWG 2067	packaged_task should have deleted copy c’tor with const parameter
VS 2013	C++14	LWG 2074	Off by one error in std::reverse_copy
VS 2013	C++14	LWG 2083	const-qualification on weak_ptr::owner_before
VS 2013	C++14	LWG 2087	iostream_category() and noexcept
VS 2013	C++14	LWG 2096	Incorrect constraints of future::get in regard to MoveAssignable
VS 2013	C++14	LWG 2128	Absence of global functions cbegin/cend
VS 2013	C++14	LWG 2138	atomic_flag::clear ordering constraints
VS 2013	C++14	LWG 2141	common_type trait produces reference types
VS 2013	C++14	LWG 2143	ios_base::xalloc should be thread-safe
VS 2013	C++14	LWG 2148	Hashing enums should be supported directly by std::hash
VS 2013	C++14	LWG 2188	Reverse iterator does not fully support targets that overload operator&
VS 2013	C++14	LWG 2197	Specification of is_[un]signed unclear for non-arithmetic types
VS 2013	C++14	LWG 2213	Return value of std::regex_replace
VS 2013	C++14	LWG 2229	Standard code conversion facets underspecified
VS 2013	C++14	LWG 2284	Inconsistency in allocator_traits::max_size
VS 2013	C++14	LWG 2293	Wrong facet used by num_put::do_put
VS 2013	C++14	LWG 2313	tuple_size should always derive from integral_constant
VS 2013	C++14	LWG 2317	The type property queries should be UnaryTypeTraits returning size_t
VS 2013	C++14	LWG 2330	regex(“meow”, regex::icase) is technically forbidden but should be permitted
VS 2013	C++14	LWG 2341	Inconsistency between basic_ostream::seekp(pos) and basic_ostream::seekp(off, dir)
VS 2013	C++14	LWG 2359	How does regex_constants::nosubs affect basic_regex::mark_count()?
VS 2013	C++14	LWG 2360	reverse_iterator::operator*() is unimplementable
VS 2013	C++17	LWG 2244	Issue on basic_istream::seekg
VS 2013	C++17	LWG 2273	regex_match ambiguity
VS 2013	C++17	LWG 2473	basic_filebuf’s relation to C FILE semantics

I’ve omitted 125 N/A issues, which require no action from implementers as far as I can tell.

One issue here is special. The Proposed Resolution for LWG 2549 “Tuple EXPLICIT constructor templates […] will create dangling references” hasn’t been voted into C++17 yet, but I implemented it and listed it here because it’s required to implement C++17’s N4387 “Improving pair And tuple” safely.

Frequently Asked Questions

Q: Argh, you’re implementing C++17 library features before finishing C++11 compiler features.

A: That’s not a question.

Q: Whyyyy?

A: Much better. There are at least two reasons. First, library devs aren’t interchangeable with compiler devs. The library and compiler codebases are totally different, and while we’re all advanced C++ programmers, the required skillsets for library vs. compiler development are non-overlapping to a much greater extent than most people appreciate. It’s very rare for someone to work on both (Gor Nishanov is a notable exception; he’s been adding support for await to both). The effort that’s going into the STL isn’t being withheld from the compiler, really! Second, STL development exercises/stresses compiler features, making the compiler more robust. Several examples: implementing C++14 result_of/function SFINAE in the STL led to improvements in the compiler’s ongoing implementation of C++11 Expression SFINAE (pointer-to-data-member expressions were especially tricky), implementing C++11/14/17 occurrences of constexpr throughout the STL led to numerous improvements in the compiler’s support for C++11 constexpr, and implementing C++17’s pair/tuple changes (which involved a novel use of SFINAE in the STL) identified numerous compiler bugs that are being worked on. So, all of this STL work is indirectly making the compiler better, especially for code that behaves like the STL (e.g. Boost).

Q: What’s new in the compiler?

A: We’ll publish an updated feature table for the compiler, but the changes since RTM are that Expression SFINAE is Partial in Update 1, and Variable Templates are Yes in Update 2 (and are used by the STL’s is_same_v/etc.). However, support for variable templates is restricted to C1XX and Clang, the compiler front-ends used for actual code generation. The EDG front-end used for Intellisense won’t support variable templates in Update 2 (support is planned for Update 3). Therefore, while using compiler or STL variable templates will compile, they’ll produce red squiggles in the IDE. While unusual, we thought that this was better than artificially holding back C1XX/STL support.

Q: When was the last time that VS’s STL was caught up with the C++ Working Paper’s features?

A: I believe it was 2006, before TR1 was voted into C++0x.

Q: When was the last time you shipped STL features outside of a major version?

A: 2008 SP1, when we added TR1.

Q: C++17 sounds kinda futuristic. Are your implementations of these C++17 STL features highly experimental, or something?

A: Everything we’ve added is fully supported for production use. I’ve personally reviewed every line, and I believe it’s very high quality. Of course, the C++ Standardization Committee can change anything before final publication, but things that are voted into the C++ Working Paper tend to be relatively stable.

Q: Will all of this stuff be available in the Community Edition?

A: Yes. We have neither the ability nor the desire to offer differing levels of STL features across different editions.

Q: What’s next for the STL?

A: We’re going to work on more bugfixes, especially for performance. After that, we’ll look into implementing the rest of the Library Issues, plus any more features that are voted in, and we’ll begin to look into various Technical Specifications (no specific promises at this time).

Q: When will Update 2 be available?

A: We haven’t announced that publicly yet, but the first preview build will contain these features and will be available Soonish(TM). (Edited on 2/16/2016 to add: That first preview build, the VS 2015 Update 2 CTP, is now available. Additionally, we’ve released the compiler/library toolset as a NuGet package, see Andrew Pardoe’s post for more info.)

Q: Can I play with this stuff now?

A: Yes! We’ve updated the Visual C++ webcompiler with our current development build, so you can compile example programs and try out these features.

I’ll update this post with a download link when that preview build of Update 2 becomes available, and again for the final build. You can download the Community Edition of VS 2015 Update 1 right now, containing support for all of the purple/blue table rows above.

Special thanks to Billy O’Neal (@MalwareMinigun) and Steve Wishnousky (@SteveWishnousky), who made this possible so soon by implementing several features, issues, and bugfixes.

Stephan T. Lavavej (@StephanTLavavej)

Senior Developer – Visual C++ Libraries

stl@microsoft.com

VS 2015 Update 2's STL is C++17-so-far Feature Complete

Author

0 comments

Read next

Top 10 reasons to use Visual Studio for C++ Android Development!

Your Version Control Experiences