C++11/14/17 Features In VS 2015 RTM - C++ Team Blog (original) (raw)
We’re still working on finishing VS 2015 RTM, but we’re definitely done with adding new features, so we can publish final feature tables. Let’s start with the STL, where we implemented a bunch of stuff after publishing 2015 RC’s features in April. Whenever I mention C++17 below, I’m referring to the current Working Paper N4527.
Standard Library This table of C++14/17 Library features contains new rows for the features that were voted into C++17 in May:
| Status | Std | Paper | Title |
|---|---|---|---|
| missing | C++14 | N3462 | SFINAE-Friendly result_of |
| missing | C++17 | N4387 | Improving pair And tuple |
| missing | C++17 | N4508 | shared_mutex (Untimed) |
| VS 2015 | C++14 | N3302 | constexpr For |
| VS 2015 | C++14 | N3469 | constexpr For |
| VS 2015 | C++14 | N3470 | constexpr For |
| VS 2015 | C++14 | N3471 | constexpr For <initializer_list>, , |
| VS 2015 | C++14 | N3545 | integral_constant::operator()() |
| VS 2015 | C++14 | N3642 | UDLs For , (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() |
| 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 (3.14i, etc.) |
| VS 2015 | C++14 | N3789 | constexpr For |
| 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 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 |
“2015 opt-in” means that this is guarded by a macro. By default, we provide auto_ptr/etc. If you define _HAS_AUTO_PTR_ETC to 0 project-wide (which you should do via the command line or project file, not via #define), then we won’t provide auto_ptr/etc. In the next major version, I’m planning to make this opt-out, and in the major version after that, I’m planning to eliminate auto_ptr/etc. entirely. Now would be a good time to start migrating your code. “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. Here’s a detailed summary of our status: 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. On top of that, our C++11 Standard Library implementation is complete. On top of that, our C++14 Standard Library implementation is complete, except for Expression SFINAE in result_of (N3462) and std::function (LWG 2132), plus 11 more Library Issues. On top of that, our C++17-so-far Standard Library implementation is complete, except for pair/tuple improvements (N4387) and untimed shared_mutex (N4508), plus 10 Library Issues. Any remaining exceptions are bugs. (By the way, we’ve fixed roughly 160 bugs in the STL between 2013 and 2015. A year ago, I listed the first batch of fixes. I’ll write about the rest of the fixes soon.) For example, we’ve implemented every occurrence of constexpr in C++17-so-far’s STL, with a very small number of exceptions, which are tracked by DevDiv#1184873/Connect#1414341 and DevDiv#1188232:
- (C99) offsetof
- (C++11) numeric_limits<float/double/long double>::quiet_NaN()/signaling_NaN()
- (C++11) mutex’s default constructor
- (C++14) error_category’s default constructor
- (C++14) min()/max()/minmax() for initializer_list
- (C++17) min_element()/max_element()/minmax_element()
We’ve been focused on achieving Standard conformance, which is higher priority than implementing the various Technical Specifications that are being produced by the Committee. (We think TSes are important, but the Standard is even more important.) However, we’ve implemented a couple of TS things: the Filesystem “V3” TS (N4100) and Uniform Container Erasure (N4529 [container.erasure]). Core Language
[RTM] These features were implemented between RC and RTM. [1] We’re planning to start implementing Expression SFINAE in the compiler immediately after 2015 RTM, and we’re planning to deliver it in an Update to 2015, supported for production use. (But not necessarily 2015 Update 1. It might take longer.) [2] C99 preprocessor support is unchanged. It’s Partial because while the compiler supports variadic macros, our preprocessor’s behavior doesn’t conform to C99/C++11 in many ways. [3] “Extended integer types” are listed as Not Applicable because the Standard permits but doesn’t require support for types longer than long long. We’ve chosen not to support such types, which is conformant behavior. Neither GCC nor Clang has implemented such types. [4] “Avoiding/fusing allocations” is listed as Not Applicable because the Standard permits but doesn’t require this optimization. We’ve chosen not to implement it (at least for now), which is conformant behavior. A note about C++11 constexpr: this is a large feature with complicated interactions throughout the Core Language, implemented in a compiler codebase undergoing modernization, being shipped for the first time. It contains bugs/limitations, some of which you might notice, and many of which will be fixed in Updates. (For example, the compiler is currently unable to emit initializers for non-scalar static constexpr data members, including character arrays. This scenario has been blocked with a warning-as-error C4579.) Nevertheless, I’ve chosen to list the compiler’s support for C++11 constexpr as being complete, because the STL is successfully using it, and quite intensively so. (The STL’s handful of missing constexpr occurrences are due to library-only issues, the absence of magic compiler hooks, and the absence of C++14 extended constexpr loops.) Finally, we’d like to thank everyone who’s reported bugs during 2015’s development cycle, not just in constexpr but throughout the whole product. If you encounter any more bugs, please report them via Microsoft Connect or Send A Smile/Frown. Stephan T. Lavavej Senior Developer – Visual C++ Libraries
Author
Pronounced Steh-fin Lah-wah-wade, or just STL.