C++11/14 Feature Tables For Visual Studio 14 CTP1

C++11/14 Feature Tables For Visual Studio 14 CTP1

Rate This
  • Comments 42

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

VS 2013

VS14 CTP1

Rvalue references

Partial

Yes

ref-qualifiers

No

Yes

Non-static data member initializers

Yes

Yes

Variadic templates

Yes

Yes

Initializer lists

Yes

Yes

static_assert

Yes

Yes

auto

Yes

Yes

Trailing return types

Yes

Yes

Lambdas

Yes

Yes

decltype

Yes

Yes

Right angle brackets

Yes

Yes

Default template args for function templates

Yes

Yes

Expression SFINAE

No

No

Alias templates

Yes

Yes

Extern templates

Yes

Yes

nullptr

Yes

Yes

Strongly typed enums

Yes

Yes

Forward declared enums

Yes

Yes

Attributes

No

No

constexpr

No

Partial

Alignment

Partial

Yes

Delegating constructors

Yes

Yes

Inheriting constructors

No

Yes

Explicit conversion operators

Yes

Yes

char16_t and char32_t

No

No

Unicode string literals

No

No

Raw string literals

Yes

Yes

Universal character names in literals

No

No

User-defined literals

No

Yes

Standard-layout and trivial types

Yes

Yes

Defaulted and deleted functions

Partial

Yes

Extended friend declarations

Yes

Yes

Extended sizeof

No

Yes

Inline namespaces

No

Yes

Unrestricted unions

No

Yes

Local and unnamed types as template args

Yes

Yes

Range-based for-loop

Yes

Yes

override and final

Yes

Yes

Minimal GC support

Yes

Yes

noexcept

No

Yes

C++11 Core Language Features: Concurrency

VS 2013

VS14 CTP1

Reworded sequence points

N/A

N/A

Atomics

Yes

Yes

Strong compare and exchange

Yes

Yes

Bidirectional fences

Yes

Yes

Memory model

N/A

N/A

Data-dependency ordering

Yes

Yes

Data-dependency ordering: attributes

No

No

exception_ptr

Yes

Yes

quick_exit and at_quick_exit

No

RTM

Atomics in signal handlers

No

No

Thread-local storage

Partial

Partial

Magic statics

No

Yes

C++11 Core Language Features: C99

VS 2013

VS14 CTP1

__func__

Partial

Yes

C99 preprocessor

Partial

Partial

long long

Yes

Yes

Extended integer types

N/A

N/A

C++14 Core Language Features

VS 2013

VS14 CTP1

Tweaked wording for contextual conversions

No

No

Binary literals

No

No

auto and decltype(auto) return types

No

Yes

init-captures

No

Yes

Generic lambdas

No

Partial

Variable templates

No

No

Extended constexpr

No

No

NSDMIs for aggregates

No

No

Avoiding/fusing allocations

No

No

[[deprecated]] attributes

No

No

Sized deallocation

No

RTM

Digit separators

No

No

 

Notes for this table (some of which I've previously mentioned):

 

  • I'm still following the organization of GCC's tables, which is why some library features are listed here (e.g. exception_ptr).
  • "N/A" means Not Applicable, because there was nothing for us to do. ("Reworded Sequence Points" has basically no effect for single-threaded code; for multi-threaded code, implementations with non-Standard threading machinery basically had to follow these rules and those of the "Memory Model" already. 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.)
  • C++11 constexpr is listed as "Partial" because VS14 CTP1 doesn't support it on member functions. Note that there's a separate row for C++14 constexpr, which has not yet been implemented.
  • Thread-Local Storage is listed as "Partial" because VC provides __declspec(thread) (which is both limited and obviously a non-Standard extension).
  • C99 Preprocessor is listed as "Partial" because VC supports variadic macros.
  • C++14 Generic Lambdas are listed as "Partial" due to one limitation: they are not yet supported with [=] or [&] capture-defaults.
  • quick_exit and Sized Deallocation (which are both library features) are listed as "RTM" because they were implemented in our CRT very recently, but the checkins didn't get into CTP1.
  • "No" and "Partial" refer to a feature's status in VS14 CTP1, which is an alpha. The compiler team is still working on features, so some features might move from "No" to "Partial" or from "No/Partial" to "Yes" in VS14 RTM (and other previews).

 

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:

 

  • Missing compiler features - notably constexpr, plus minor things like char16_t/char32_t; we're also catching up with noexcept as I mentioned last week and with ref-qualifiers.
  • Bugs - which we're making steady progress on.
  • 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>.

 

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:

 

Status

Paper/Issue

Title

constexpr

N3302

Constexpr Library Additions: complex, v2

VS 2013

N3346

Terminology for Container Element Requirements - Rev 1

VS 2013

N3421

Making Operator Functors greater<>

SFINAE

N3462

std::result_of and SFINAE

constexpr

N3469

Constexpr Library Additions: chrono, v3

constexpr

N3470

Constexpr Library Additions: containers, v2

constexpr

N3471

Constexpr Library Additions: utilities, v3

constexpr

N3545

An Incremental Improvement to integral_constant

VS14 CTP1

N3642

User-defined Literals

VS14 CTP1

N3644

Null Forward Iterators

VS14 CTP1

N3654

Quoted Strings

VS 2013

N3655

TransformationTraits Redux (excluding part 4)

VS 2013

N3656

make_unique

VS14 CTP1

N3657

Adding heterogeneous comparison lookup to associative containers

VS14 CTP1

N3658

Compile-time integer sequences

missing

N3659

Shared Locking in C++

VS14 CTP1

N3668

std::exchange()

constexpr

N3669

Fixing constexpr member functions without const

VS14 CTP1

N3670

Addressing Tuples by Type

VS14 CTP1

N3671

Making non-modifying sequence operations more robust

VS14 RTM

N3778

Sized deallocation

VS14 CTP1

N3779

User-defined Literals for std::complex

constexpr

N3789

Constexpr Library Additions: functional

VS14 CTP1

N3887

Consistent Metafunction Aliases

missing

N3891

A proposal to rename shared_mutex to shared_timed_mutex

N/A

N3924

Discouraging rand() in C++14

VS 2013

LWG 1214

Insufficient/inconsistent key immutability requirements for associative containers

N/A

LWG 1450

Contradiction in regex_constants

N/A

LWG 2003

String exception inconsistency in erase.

missing

LWG 2005

unordered_map::insert(T&&) protection should apply to map too

VS14 CTP1

LWG 2009

Reporting out-of-bound values on numeric string conversions

N/A

LWG 2010

is_* traits for binding operations can't be meaningfully specialized

VS 2013

LWG 2011

Unexpected output required of strings

N/A

LWG 2013

Do library implementers have the freedom to add constexpr?

N/A

LWG 2015

Incorrect pre-conditions for some type traits

missing

LWG 2018

regex_traits::isctype Returns clause is wrong

missing

LWG 2021

Further incorrect usages of result_of

N/A

LWG 2028

messages_base::catalog overspecified

VS 2013

LWG 2033

Preconditions of reserve, shrink_to_fit, and resize functions

VS 2013

LWG 2039

Issues with std::reverse and std::copy_if

N/A

LWG 2044

No definition of "Stable" for copy algorithms

N/A

LWG 2045

forward_list::merge and forward_list::splice_after with unequal allocators

VS 2013

LWG 2047

Incorrect "mixed" move-assignment semantics of unique_ptr

N/A

LWG 2048

Unnecessary mem_fn overloads

VS 2013

LWG 2049

is_destructible is underspecified

VS 2013

LWG 2050

Unordered associative containers do not use allocator_traits to define member types

N/A

LWG 2053

Errors in regex bitmask types

VS 2013

LWG 2056

future_errc enums start with value 0 (invalid value for broken_promise)

N/A

LWG 2058

valarray and begin/end

VS 2013

LWG 2061

make_move_iterator and arrays

missing

LWG 2064

More noexcept issues in basic_string

N/A

LWG 2065

Minimal allocator interface

VS 2013

LWG 2067

packaged_task should have deleted copy c'tor with const parameter

N/A

LWG 2069

Inconsistent exception spec for basic_string move constructor

N/A

LWG 2071

std::valarray move-assignment

VS 2013

LWG 2074

Off by one error in std::reverse_copy

N/A

LWG 2075

Progress guarantees, lock-free property, and scheduling assumptions

missing

LWG 2078

Throw specification of async() incomplete

N/A

LWG 2080

Specify when once_flag becomes invalid

N/A

LWG 2081

Allocator requirements should include CopyConstructible

VS 2013

LWG 2083

const-qualification on weak_ptr::owner_before

N/A

LWG 2085

Wrong description of effect 1 of basic_istream::ignore

N/A

LWG 2086

Overly generic type support for math functions

VS 2013

LWG 2087

iostream_category() and noexcept

N/A

LWG 2091

Misplaced effect in m.try_lock_for()

N/A

LWG 2092

Vague Wording for condition_variable_any

N/A

LWG 2093

Throws clause of condition_variable::wait with predicate

missing

LWG 2094

duration conversion overflow shouldn't participate in overload resolution

VS 2013

LWG 2096

Incorrect constraints of future::get in regard to MoveAssignable

VS14 CTP1

LWG 2097

packaged_task constructors should be constrained

N/A

LWG 2098

promise throws clauses

N/A

LWG 2099

Unnecessary constraints of va_start() usage

N/A

LWG 2100

Timed waiting functions cannot timeout if launch::async policy used

N/A

LWG 2102

Why is std::launch an implementation-defined type?

VS14 CTP1

LWG 2103

std::allocator_traits<std::allocator<T>>::propagate_on_container_move_assignment

VS14 CTP1

LWG 2104

unique_lock move-assignment should not be noexcept

N/A

LWG 2105

Inconsistent requirements on const_iterator's value_type

N/A

LWG 2109

Incorrect requirements for hash specializations

N/A

LWG 2110

remove can't swap but note says it might

VS14 CTP1

LWG 2112

User-defined classes that cannot be derived from

N/A

LWG 2120

What should async do if neither 'async' nor 'deferred' is set in policy?

N/A

LWG 2122

merge() stability for lists versus forward lists

N/A

LWG 2123

merge() allocator requirements for lists versus forward lists

VS 2013

LWG 2128

Absence of global functions cbegin/cend

N/A

LWG 2130

missing ordering constraints for fences

SFINAE

LWG 2132

std::function ambiguity

missing

LWG 2135

Unclear requirement for exceptions thrown in condition_variable::wait()

VS 2013

LWG 2138

atomic_flag::clear ordering constraints

missing

LWG 2140

notify_all_at_thread_exit synchronization

VS 2013

LWG 2141

common_type trait produces reference types

N/A

LWG 2142

packaged_task::operator() synchronization too broad?

VS 2013

LWG 2143

ios_base::xalloc should be thread-safe

VS14 CTP1

LWG 2144

Missing noexcept specification in type_index

VS14 CTP1

LWG 2145

error_category default constructor

N/A

LWG 2147

Unclear hint type in Allocator's allocate function

VS 2013

LWG 2148

Hashing enums should be supported directly by std::hash

N/A

LWG 2149

Concerns about 20.8/5

N/A

LWG 2150

Unclear specification of find_end

N/A

LWG 2159

atomic_flag initialization

VS14 CTP1

LWG 2162

allocator_traits::max_size missing noexcept

N/A

LWG 2163

nth_element requires inconsistent post-conditions

N/A

LWG 2169

Missing reset() requirements in unique_ptr specialization

N/A

LWG 2172

Does atomic_compare_exchange_* accept v == nullptr arguments?

VS14 CTP1

LWG 2174

wstring_convert::converted() should be noexcept

N/A

LWG 2175

string_convert and wbuffer_convert validity

VS14 CTP1

LWG 2176

Special members for wstring_convert and wbuffer_convert

N/A

LWG 2177

Requirements on Copy/MoveInsertable

N/A

LWG 2180

Exceptions from std::seed_seq operations

N/A

LWG 2182

Container::[const_]reference types are misleadingly specified

N/A

LWG 2185

Missing throws clause for future/shared_future::wait_for/wait_until

N/A

LWG 2186

Incomplete action on async/launch::deferred

VS14 CTP1

LWG 2187

vector<bool> is missing emplace and emplace_back member functions

VS 2013

LWG 2188

Reverse iterator does not fully support targets that overload operator&

N/A

LWG 2190

ordering of condition variable operations, reflects Posix discussion

VS14 CTP1

LWG 2193

Default constructors for standard library containers are explicit

N/A

LWG 2194

Impossible container requirements for adaptor types

VS 2013

LWG 2196

Specification of is_*[copy/move]_[constructible/assignable] unclear for non-referencable types

VS 2013

LWG 2197

Specification of is_[un]signed unclear for non-arithmetic types

N/A

LWG 2200

Data race avoidance for all containers, not only for sequences

missing

LWG 2203

scoped_allocator_adaptor uses wrong argument types for piecewise construction

N/A

LWG 2205

Problematic postconditions of regex_match and regex_search

N/A

LWG 2207

basic_string::at should not have a Requires clause

N/A

LWG 2209

assign() overspecified for sequence containers

missing

LWG 2210

Missing allocator-extended constructor for allocator-aware containers

N/A

LWG 2211

Replace ambiguous use of "Allocator" in container requirements

VS 2013

LWG 2213

Return value of std::regex_replace

N/A

LWG 2222

Inconsistency in description of forward_list::splice_after single-element overload

N/A

LWG 2225

Unrealistic header inclusion checks required

VS 2013

LWG 2229

Standard code conversion facets underspecified

N/A

LWG 2231

DR 704 removes complexity guarantee for clear()

N/A

LWG 2235

Undefined behavior without proper requirements on basic_string constructors

N/A

LWG 2240

Probable misuse of term "function scope" in [thread.condition]

N/A

LWG 2246

unique_ptr assignment effects w.r.t. deleter

VS14 CTP1

LWG 2247

Type traits and std::nullptr_t

missing

LWG 2252

Strong guarantee on vector::push_back() still broken with C++11?

N/A

LWG 2257

Simplify container requirements with the new algorithms

N/A

LWG 2258

a.erase(q1, q2) unable to directly return q2

N/A

LWG 2263

Comparing iterators and allocator pointers with different const-character

VS14 CTP1

LWG 2268

Setting a default argument in the declaration of a member function assign of std::basic_string

N/A

LWG 2271

regex_traits::lookup_classname specification unclear

VS14 CTP1

LWG 2272

quoted should use char_traits::eq for character comparison

constexpr

LWG 2275

Why is forward_as_tuple not constexpr?

VS14 CTP1

LWG 2278

User-defined literals for Standard Library types

constexpr

LWG 2280

begin / end for arrays should be constexpr and noexcept

VS 2013

LWG 2284

Inconsistency in allocator_traits::max_size

VS14 CTP1

LWG 2285

make_reverse_iterator

N/A

LWG 2288

Inconsistent requirements for shared mutexes

N/A

LWG 2291

std::hash is vulnerable to collision DoS attack

VS 2013

LWG 2293

Wrong facet used by num_put::do_put

N/A

LWG 2298

is_nothrow_constructible is always false because of create<>

N/A

LWG 2299

Effects of inaccessible key_compare::is_transparent type are not clear

N/A

LWG 2300

Redundant sections for map and multimap members should be removed

constexpr

LWG 2301

Why is std::tie not constexpr?

N/A

LWG 2304

Complexity of count in unordered associative containers

VS14 CTP1

LWG 2306

match_results::reference should be value_type&, not const value_type&

N/A

LWG 2308

Clarify container destructor requirements w.r.t. std::array

VS 2013

LWG 2313

tuple_size should always derive from integral_constant

N/A

LWG 2314

apply() should return decltype(auto) and use decay_t before tuple_size

VS14 CTP1

LWG 2315

weak_ptr should be movable

N/A

LWG 2316

weak_ptr::lock() should be atomic

VS 2013

LWG 2317

The type property queries should be UnaryTypeTraits returning size_t

N/A

LWG 2320

select_on_container_copy_construction() takes allocators, not containers

N/A

LWG 2322

Associative(initializer_list, stuff) constructors are underspecified

N/A

LWG 2323

vector::resize(n, t)'s specification should be simplified

VS14 CTP1

LWG 2324

Insert iterator constructors should use addressof()

VS14 CTP1

LWG 2329

regex_match()/regex_search() with match_results should forbid temporary strings

VS 2013

LWG 2330

regex("meow", regex::icase) is technically forbidden but should be permitted

VS14 CTP1

LWG 2332

regex_iterator/regex_token_iterator should forbid temporary regexes

VS14 CTP1

LWG 2339

Wording issue in nth_element

VS 2013

LWG 2341

Inconsistency between basic_ostream::seekp(pos) and basic_ostream::seekp(off, dir)

VS14 CTP1

LWG 2344

quoted()'s interaction with padding is unclear

VS14 CTP1

LWG 2346

integral_constant's member functions should be marked noexcept

constexpr

LWG 2350

min, max, and minmax should be constexpr

N/A

LWG 2356

Stability of erasure in unordered associative containers

N/A

LWG 2357

Remaining "Assignable" requirement

VS 2013

LWG 2359

How does regex_constants::nosubs affect basic_regex::mark_count()?

VS 2013

LWG 2360

reverse_iterator::operator*() is unimplementable

VS14 CTP1

GB 9

Remove gets from C++14

 

Here's what my Status entries mean:

 

  • VS 2013 - Implemented in VS 2013 RTM (and possibly in previous versions; I limited my programmer-archaeology to 2013).
  • VS14 CTP1- Implemented in VS14 CTP1.
  • VS14 RTM- Checked into source control, will ship in VS14 RTM. May appear in other previews (I am being vague because this depends on when branches are merged).
  • constexpr- Not yet implemented, blocked on compiler support for constexpr. (Because we have plenty of other work to do, I'm not going to attempt to enable constexpr in the STL until the compiler supports C++11 constexpr in its entirety.)
  • SFINAE - Not yet implemented, blocked on compiler support for Expression SFINAE.
  • missing - Not yet implemented. May be implemented for VS14 RTM if time permits.
  • N/A- Not Applicable. As far as I can tell, this issue's resolution doesn't require any action from an STL maintainer. For example, wording changes to Notes and Examples are clearly N/A (because Notes and Examples are "informative", not "normative"). Eliminating redundant normative wording is also N/A. Some resolutions affect users but not implementers - for example, when preconditions are added without required enforcement, that matters to users but it's N/A as far as I'm concerned here. I was somewhat aggressive with marking issues as N/A - for example, when mostly-clear wording was further clarified, or when nonsensical wording was removed and the correct behavior was always obvious. According to me, LWG 2316 "weak_ptr::lock() should be atomic" is N/A because this was obvious to every implementer even if the Standard forgot to say it. (But LWG 2315 "weak_ptr should be movable" required action, even if it was pretty obvious.)

 

I hope this info will be useful to you.

 

Stephan T. Lavavej

Senior Developer - Visual C++ Libraries

stl@microsoft.com

Leave a Comment
  • Please add 4 and 7 and type the answer here:
  • Post
  • 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?

    Thank you!

  • 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:

    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.

    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.

  • @S.T.L

    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:

    class A

    {

    public:

       A(void) {};

    };

    ...

    A o1, * p = &o1;

    o1.A::A();//1

    p->A::A();//2

  • @Simon Dan:

    Yes its really weird !

    BTW is it "o1.A::A();" OR "o1::A();" ? Why an extra .A?

Page 1 of 3 (42 items) 123