As I promised last week in my post about the STL changes in VS14 CTP1, here are tables listing the implementation status of C++11/14 Core Language/Standard Library features.
First, let's look at the Core Language. (Previous tables: VS 2008 and VS 2010, VS 2012, VS 2013.)
C++11 Core Language Features
Non-static data member initializers
Trailing return types
Right angle brackets
Default template args for function templates
Strongly typed enums
Forward declared enums
Explicit conversion operators
char16_t and char32_t
Unicode string literals
Raw string literals
Universal character names in literals
Standard-layout and trivial types
Defaulted and deleted functions
Extended friend declarations
Local and unnamed types as template args
override and final
Minimal GC support
C++11 Core Language Features: Concurrency
Reworded sequence points
Strong compare and exchange
Data-dependency ordering: attributes
quick_exit and at_quick_exit
Atomics in signal handlers
C++11 Core Language Features: C99
Extended integer types
C++14 Core Language Features
Tweaked wording for contextual conversions
auto and decltype(auto) return types
NSDMIs for aggregates
Notes for this table (some of which I've previously mentioned):
Now, let's look at the Standard Library. VS14 CTP1 fully supports the C++11 Standard Library including the C99 Standard Library, with the following exceptions:
As for the C++14 Standard Library, I'd like to thank libc++'s maintainers for their table of the papers and Library Issue resolutions that have been voted into C++14. (They saved me the time it would have taken to dig through the minutes of the meetings, trying to figure out what was voted in.) Here's my table:
Constexpr Library Additions: complex, v2
Terminology for Container Element Requirements - Rev 1
Making Operator Functors greater<>
std::result_of and SFINAE
Constexpr Library Additions: chrono, v3
Constexpr Library Additions: containers, v2
Constexpr Library Additions: utilities, v3
An Incremental Improvement to integral_constant
Null Forward Iterators
TransformationTraits Redux (excluding part 4)
Adding heterogeneous comparison lookup to associative containers
Compile-time integer sequences
Shared Locking in C++
Fixing constexpr member functions without const
Addressing Tuples by Type
Making non-modifying sequence operations more robust
User-defined Literals for std::complex
Constexpr Library Additions: functional
Consistent Metafunction Aliases
A proposal to rename shared_mutex to shared_timed_mutex
Discouraging rand() in C++14
Insufficient/inconsistent key immutability requirements for associative containers
Contradiction in regex_constants
String exception inconsistency in erase.
unordered_map::insert(T&&) protection should apply to map too
Reporting out-of-bound values on numeric string conversions
is_* traits for binding operations can't be meaningfully specialized
Unexpected output required of strings
Do library implementers have the freedom to add constexpr?
Incorrect pre-conditions for some type traits
regex_traits::isctype Returns clause is wrong
Further incorrect usages of result_of
Preconditions of reserve, shrink_to_fit, and resize functions
Issues with std::reverse and std::copy_if
No definition of "Stable" for copy algorithms
forward_list::merge and forward_list::splice_after with unequal allocators
Incorrect "mixed" move-assignment semantics of unique_ptr
Unnecessary mem_fn overloads
is_destructible is underspecified
Unordered associative containers do not use allocator_traits to define member types
Errors in regex bitmask types
future_errc enums start with value 0 (invalid value for broken_promise)
valarray and begin/end
make_move_iterator and arrays
More noexcept issues in basic_string
Minimal allocator interface
packaged_task should have deleted copy c'tor with const parameter
Inconsistent exception spec for basic_string move constructor
Off by one error in std::reverse_copy
Progress guarantees, lock-free property, and scheduling assumptions
Throw specification of async() incomplete
Specify when once_flag becomes invalid
Allocator requirements should include CopyConstructible
const-qualification on weak_ptr::owner_before
Wrong description of effect 1 of basic_istream::ignore
Overly generic type support for math functions
iostream_category() and noexcept
Misplaced effect in m.try_lock_for()
Vague Wording for condition_variable_any
Throws clause of condition_variable::wait with predicate
duration conversion overflow shouldn't participate in overload resolution
Incorrect constraints of future::get in regard to MoveAssignable
packaged_task constructors should be constrained
promise throws clauses
Unnecessary constraints of va_start() usage
Timed waiting functions cannot timeout if launch::async policy used
Why is std::launch an implementation-defined type?
unique_lock move-assignment should not be noexcept
Inconsistent requirements on const_iterator's value_type
Incorrect requirements for hash specializations
remove can't swap but note says it might
User-defined classes that cannot be derived from
What should async do if neither 'async' nor 'deferred' is set in policy?
merge() stability for lists versus forward lists
merge() allocator requirements for lists versus forward lists
Absence of global functions cbegin/cend
missing ordering constraints for fences
Unclear requirement for exceptions thrown in condition_variable::wait()
atomic_flag::clear ordering constraints
common_type trait produces reference types
packaged_task::operator() synchronization too broad?
ios_base::xalloc should be thread-safe
Missing noexcept specification in type_index
error_category default constructor
Unclear hint type in Allocator's allocate function
Hashing enums should be supported directly by std::hash
Concerns about 20.8/5
Unclear specification of find_end
allocator_traits::max_size missing noexcept
nth_element requires inconsistent post-conditions
Missing reset() requirements in unique_ptr specialization
Does atomic_compare_exchange_* accept v == nullptr arguments?
wstring_convert::converted() should be noexcept
string_convert and wbuffer_convert validity
Special members for wstring_convert and wbuffer_convert
Requirements on Copy/MoveInsertable
Exceptions from std::seed_seq operations
Container::[const_]reference types are misleadingly specified
Missing throws clause for future/shared_future::wait_for/wait_until
Incomplete action on async/launch::deferred
vector<bool> is missing emplace and emplace_back member functions
Reverse iterator does not fully support targets that overload operator&
ordering of condition variable operations, reflects Posix discussion
Default constructors for standard library containers are explicit
Impossible container requirements for adaptor types
Specification of is_*[copy/move]_[constructible/assignable] unclear for non-referencable types
Specification of is_[un]signed unclear for non-arithmetic types
Data race avoidance for all containers, not only for sequences
scoped_allocator_adaptor uses wrong argument types for piecewise construction
Problematic postconditions of regex_match and regex_search
basic_string::at should not have a Requires clause
assign() overspecified for sequence containers
Missing allocator-extended constructor for allocator-aware containers
Replace ambiguous use of "Allocator" in container requirements
Return value of std::regex_replace
Inconsistency in description of forward_list::splice_after single-element overload
Unrealistic header inclusion checks required
Standard code conversion facets underspecified
DR 704 removes complexity guarantee for clear()
Undefined behavior without proper requirements on basic_string constructors
Probable misuse of term "function scope" in [thread.condition]
unique_ptr assignment effects w.r.t. deleter
Type traits and std::nullptr_t
Strong guarantee on vector::push_back() still broken with C++11?
Simplify container requirements with the new algorithms
a.erase(q1, q2) unable to directly return q2
Comparing iterators and allocator pointers with different const-character
Setting a default argument in the declaration of a member function assign of std::basic_string
regex_traits::lookup_classname specification unclear
quoted should use char_traits::eq for character comparison
Why is forward_as_tuple not constexpr?
User-defined literals for Standard Library types
begin / end for arrays should be constexpr and noexcept
Inconsistency in allocator_traits::max_size
Inconsistent requirements for shared mutexes
std::hash is vulnerable to collision DoS attack
Wrong facet used by num_put::do_put
is_nothrow_constructible is always false because of create<>
Effects of inaccessible key_compare::is_transparent type are not clear
Redundant sections for map and multimap members should be removed
Why is std::tie not constexpr?
Complexity of count in unordered associative containers
match_results::reference should be value_type&, not const value_type&
Clarify container destructor requirements w.r.t. std::array
tuple_size should always derive from integral_constant
apply() should return decltype(auto) and use decay_t before tuple_size
weak_ptr should be movable
weak_ptr::lock() should be atomic
The type property queries should be UnaryTypeTraits returning size_t
select_on_container_copy_construction() takes allocators, not containers
Associative(initializer_list, stuff) constructors are underspecified
vector::resize(n, t)'s specification should be simplified
Insert iterator constructors should use addressof()
regex_match()/regex_search() with match_results should forbid temporary strings
regex("meow", regex::icase) is technically forbidden but should be permitted
regex_iterator/regex_token_iterator should forbid temporary regexes
Wording issue in nth_element
Inconsistency between basic_ostream::seekp(pos) and basic_ostream::seekp(off, dir)
quoted()'s interaction with padding is unclear
integral_constant's member functions should be marked noexcept
min, max, and minmax should be constexpr
Stability of erasure in unordered associative containers
Remaining "Assignable" requirement
How does regex_constants::nosubs affect basic_regex::mark_count()?
reverse_iterator::operator*() is unimplementable
Remove gets from C++14
Here's what my Status entries mean:
I hope this info will be useful to you.
Stephan T. Lavavej
Senior Developer - Visual C++ Libraries
Thank you so much STL. You are our C++ hero! :)
> Minor omissions - I am currently aware of <uchar.h>/<cuchar> and <exception>'s nested_exception, throw_with_nested(), and rethrow_if_nested(). Also, while we have <ctgmath> for C++11, we don't have C99 compiler support for <tgmath.h>.
- Does it include Unicode?
- Does it mean <uchar> and <tgmath> would not appear in VC world soon / ever?
Hi, thanks for this very useful. Maybe I'm missing this in your post but could you confirm that VS2013 refers to VS2013 Update 2 and not something earlier or Update 3 CTP.
Also if your allowed can you comment on whether VS 2013 will be updated to see any more C++ 11/14 fetures or is it all VS 2014 from now on?
Perhaps if we implement support for digit separators this release we could refer to it as "Visual Studio 1'4"? ;-)
Tony> Does it include Unicode?
I don't understand the question. Can you clarify what you mean?
> Does it mean <uchar> and <tgmath> would not appear in VC world soon / ever?
My coworker Pat Brenner is actually adding <uchar.h> to the CRT right now, and I've given him <cuchar> to add to the STL. Unless a meteor strikes, this will get into VS14 RTM.
I don't expect compiler support for <tgmath.h> to appear any time soon (nor will I shed any tears).
David Hunter> could you confirm that VS2013 refers to VS2013 Update 2 and not something earlier or Update 3 CTP.
In this post, "VS 2013" means "this feature shipped in VS 2013 RTM and is present in all later Updates". There's only one exception: initializer lists in 2013 RTM and 2013 Update 1 suffered from a severe compiler bug where temporaries would be destroyed too early (affecting std::maps constructed from initializer lists, among other things). This compiler bug was fixed in 2013 Update 2.
> Also if your allowed can you comment on whether VS 2013 will be updated to see any more C++ 11/14 fetures or is it all VS 2014 from now on?
It is highly unlikely that compiler features will be backported to VS 2013. STL features definitely won't be backported to VS 2013, for the "latency vs. bandwidth" reasons that I explained in blogs.msdn.com/.../c-11-14-stl-features-fixes-and-breaking-changes-in-vs-2013.aspx Q4 and Q5.
Also, 14 is a version number, not a year. VS14 RTM "will most likely be available sometime in 2015" according to DevDiv's Corp VP.
James McNellis: I recommend Visual Studio 0b11'10 for maximum fun/confusion.
STL> I don't understand the question. Can you clarify what you mean?
C unicode tr. I think its part of uchar..
Thanks for the answers! :)
Tony: Yeah, the C Unicode TR specified uchar.h, and was incorporated into C++11 and C11. We missed it in VS 2013 because it technically wasn't part of C99.
First I want to congratulate on the awesome work! Would not have imagined this much progress in C++ support a few years back.
By the way, I see that integer_sequence and friends have been implemented in the latest STL, but it seems there is no fix for the template instantiation depth issue, and the compiler errors out with internal error for sequences big enough. I was hoping it would use some kind of compiler hook to get away from this limitation, but it seems to be no better, or worse, than a handwritten implementation.
Any plans to improve this in the future?
make_integer_sequence<int, 492> isn't enough for you?
Seriously though, the compiler is trying to detect and complain about infinitely recursive template instantiations, instead of just running out of memory. IIRC, the compiler's limit is 500. N3936's suggested limit is 1024 or greater, so I'll ask the compiler team to consider changing this.
Nope! I need to go over 9000!
Seriously though, I need only 8192 max, and I can get away with this just fine in VS2013 and CTP 14 by using a hand-expanded implementation that only handles N divisible by 128, which is fine in my particular case...
Was kinda hoping an official implementation would use some compiler magic to implement this!
Are the features in this CTP destined for VS 14, or might they appear in VS 13 as Update 3?
David Hunter asked this question earlier in the thread, but I don't see an answer. Thanks for the detailed information in these posts.
Why is "Extended integer types" N/A? I reckoned that was one of the shiny feature of Cpp11 standard.
Does that mean we won't get there support in VS?
Matheus Izvekov: The compiler stops at 500 to avoid stack overflow. We could use library tech as a workaround, but it's unclear to me how useful enormous integer_sequences would be given the compiler limitation.
Adrian: Already answered in a previous comment, where I said:
FLEET COMMAND: Already answered in the post, where I said:
And "Extended Integer Types" is the purest form of N/A - this permits but doesn't require implementations to have such types, and VC doesn't have them.
They are useful in my case to populate arrays during compilation, and they do this well, having an integer sequence that goes to N translates directly into being able to populate an array of N elements.
My use case is for generating arrays of function pointers, where each element points to a different instance of a function template. This is used to implement a reasonably fast software rasterizer in 450 lines of code, which would normally take tens of thousands of highly repetitive code, and without having to JIT anything.
In VS2012 and before, the same arrays were generated by external scripts.
Could you please close the door to the Direct-Call-To_Constructors? It is there for almost 6 years...
Looks really weird...
Something looks like:
A o1, * p = &o1;
Yes its really weird !
BTW is it "o1.A::A();" OR "o1::A();" ? Why an extra .A?