C++11 Features in Visual C++ 11

C++11 Features in Visual C++ 11

UPDATE - March 2, 2012: the range-based for-loop and override/final v1.0 have been implemented in VC11 Beta.

 

There's a new C++ Standard and a new version of Visual C++, and it's time to reveal what features from the former we're implementing in the latter!

Terminology notes: During its development, the new C++ Standard was (optimistically) referred to as C++0x.  It's finally being published in 2011, and it's now referred to as C++11.  (Even International Standards slip their release dates.)  The Final Draft International Standard is no longer publicly available.  It was immediately preceded by Working Paper N3242, which is fairly close in content.  (Most of the people who care about the differences are compiler/Standard Library devs who already have access to the FDIS.)  Eventually, I expect that the C++11 Standard will be available from ANSI, like C++03 is.

As for Visual C++, it has three different version numbers, for maximum fun.  There's the branded version (printed on the box), the internal version (displayed in Help About), and the compiler version (displayed by cl.exe and the _MSC_VER macro - this one is different because our C++ compiler predates the "Visual" in Visual C++).  For example:

VS 2005 == VC8 == _MSC_VER 1400
VS 2008 == VC9 == _MSC_VER 1500
VS 2010 == VC10 == _MSC_VER 1600

The final branding for the new version hasn't been announced yet; for now, I'm supposed to say "Visual C++ in Visual Studio 11 Developer Preview".  Internally, it's just VC11, and its _MSC_VER macro is 1700.  (That macro is of interest to people who want to target different major versions of VC and emit different code for them.)  I say VC10 and VC11 because they're nice and simple - the 11 in VC11 does not refer to a year.  (VS 2010 == VC10 was a confusing coincidence.)

If you read C++0x Core Language Features In VC10: The Table last year, the following table will look familiar to you.  This time, I started with GCC's table again, but I reorganized it more extensively for increased accuracy and clarity (as many features went through significant revisions):

 

C++11 Core Language Features VC10 VC11
Rvalue references v0.1, v1.0, v2.0, v2.1, v3.0 v2.0 v2.1*
ref-qualifiers No No
Non-static data member initializers No No
Variadic templates v0.9, v1.0 No No
Initializer lists No No
static_assert Yes Yes
auto v0.9, v1.0 v1.0 v1.0
Trailing return types Yes Yes
Lambdas v0.9, v1.0, v1.1 v1.0 v1.1
decltype v1.0, v1.1 v1.0 v1.1**
Right angle brackets Yes Yes
Default template arguments for function templates No No
Expression SFINAE No No
Alias templates No No
Extern templates Yes Yes
nullptr Yes Yes
Strongly typed enums Partial Yes
Forward declared enums No Yes
Attributes No No
constexpr No No
Alignment TR1 Partial
Delegating constructors No No
Inheriting constructors No No
Explicit conversion operators No No
char16_t and char32_t No No
Unicode string literals No No
Raw string literals No No
Universal character names in literals No No
User-defined literals No No
Standard-layout and trivial types No Yes
Defaulted and deleted functions No No
Extended friend declarations Yes Yes
Extended sizeof No No
Inline namespaces No No
Unrestricted unions No No
Local and unnamed types as template arguments Yes Yes
Range-based for-loop No Yes
override and final v0.8, v0.9, v1.0 Partial Yes
Minimal GC support Yes Yes
noexcept No No

 

C++11 Core Language Features: Concurrency VC10 VC11
Reworded sequence points N/A N/A
Atomics No Yes
Strong compare and exchange No Yes
Bidirectional fences No Yes
Memory model N/A N/A
Data-dependency ordering No Yes
Data-dependency ordering: function annotation No No
exception_ptr Yes Yes
quick_exit and at_quick_exit No No
Atomics in signal handlers No No
Thread-local storage Partial Partial
Magic statics No No

 

C++11 Core Language Features: C99 VC10 VC11
__func__ Partial Partial
C99 preprocessor Partial Partial
long long Yes Yes
Extended integer types N/A N/A

 

Here's a quick guide to this table, but note that I can't explain everything from scratch without writing a whole book, so this assumes moderate familiarity with what's in C++11:

Rvalue references: N1610 "Clarification of Initialization of Class Objects by rvalues" was an early attempt to enable move semantics without rvalue references.  I'm calling it "rvalue references v0.1", as it's of historical interest only.  It was superseded by rvalue references v1.0, the original wording.  Rvalue references v2.0, which is what we shipped in VC10 RTM/SP1, prohibits rvalue references from binding to lvalues, fixing a major safety problem.  Rvalue references v2.1 refines this rule.  Consider vector<string>::push_back(), which has the overloads push_back(const string&) and push_back(string&&), and the call v.push_back("meow").  The expression "meow" is a string literal, and it is an lvalue.  (All other literals like 1729 are rvalues, but string literals are special because they're arrays.)  The rvalue references v2.0 rules looked at this and said, string&& can't bind to "meow" because "meow" is an lvalue, so push_back(const string&) is the only viable overload.  This would create a temporary std::string, copy it into the vector, then destroy the temporary std::string.  Yuck!  The rvalue references v2.1 rules recognize that binding string&& to "meow" would create a temporary std::string, and that temporary is an rvalue.  Therefore, both push_back(const string&) and push_back(string&&) are viable, and push_back(string&&) is preferred.  A temporary std::string is constructed, then moved into the vector.  This is more efficient, which is good!  (Yes, I'm ignoring the Small String Optimization here.)

The table says "v2.1*" because these new rules haven't been completely implemented in the VC11 Developer Preview.  This is being tracked by an active bug.  (Indeed, this is a Standard bugfix.)

Rvalue references v3.0 adds new rules to automatically generate move constructors and move assignment operators under certain conditions.  This will not be implemented in VC11, which will continue to follow VC10's behavior of never automatically generating move constructors/move assignment operators.  (As with all of the not-yet-implemented features here, this is due to time and resource constraints, and not due to dislike of the features themselves!)

(By the way, all of this v0.1, v1.0, v2.0, v2.1, v3.0 stuff is my own terminology, which I think adds clarity to C++11's evolution.)

Lambdas: After lambdas were voted into the Working Paper (v0.9) and mutable lambdas were added (v1.0), the Standardization Committee overhauled the wording, producing lambdas v1.1.  This happened too late for us to implement in VC10, but we've already implemented it in VC11.  The lambdas v1.1 wording clarifies what should happen in corner cases like referring to static members, or nested lambdas.  This fixes a bunch of bugs triggered by complicated lambdas.  Additionally, stateless lambdas are now convertible to function pointers in VC11.  This isn't in N2927's wording, but I count it as part of lambdas v1.1 anyways.  It's FDIS 5.1.2 [expr.prim.lambda]/6: "The closure type for a lambda-expression with no lambda-capture has a public non-virtual non-explicit const conversion function to pointer to function having the same parameter and return types as the closure type’s function call operator. The value returned by this conversion function shall be the address of a function that, when invoked, has the same effect as invoking the closure type’s function call operator."  (It's even better than that, since we've made stateless lambdas convertible to function pointers with arbitrary calling conventions.  This is important when dealing with APIs that expect __stdcall function pointers and so forth.)

decltype: After decltype was voted into the Working Paper (v1.0), it received a small but important bugfix at the very last minute (v1.1).  This isn't interesting to most programmers, but it's of great interest to programmers who work on the STL and Boost.  The table says "v1.1**" because this isn't implemented in the VC11 Developer Preview, but the changes to implement it have already been checked in.

Strongly typed/forward declared enums: Strongly typed enums were partially supported in VC10 (specifically, the part about explicitly specified underlying types), and C++11's semantics for forward declared enums weren't supported at all in VC10.  Both have been completely implemented in VC11.

Alignment: Neither VC10 nor VC11 implement the Core Language keywords alignas/alignof from the alignment proposal that was voted into the Working Paper.  VC10 had aligned_storage from TR1.  VC11 adds aligned_union and std::align() to the Standard Library.

Standard-layout and trivial types: As far as I can tell, the user-visible changes from N2342 "POD's Revisited; Resolving Core Issue 568 (Revision 5)" are the addition of is_trivial and is_standard_layout to <type_traits>.  (N2342 performed a lot of surgery to Core Language wording, but it just makes stuff well-defined that users could have gotten away with anyways, hence no compiler changes are necessary.)  We had these type traits in VC10, but they just duplicated is_pod, so I'm calling that "No" support.  In VC11, they're powered by compiler hooks that should give accurate answers.

Extended friend declarations: Last year, I said that VC10 partially supported this.  Upon closer inspection of N1791, I've determined that VC's support for this is essentially complete (it doesn't even emit "non-Standard extension" warnings, unlike some of the other Ascended Extensions in this table).  So I've marked both VC10 and VC11 as "Yes".

override and final: This went through a short but complicated evolution.   Originally (v0.8) there were [[override]], [[hiding]], and [[base_check]] attributes.  Then (v0.9) the attributes were eliminated and replaced with contextual keywords.  Finally (v1.0), they were reduced to "final" on classes, and "override" and "final" on functions.  This makes it an Ascended Extension, as VC already supports this "override" syntax on functions, with semantics reasonably close to C++11's.  "final" is also supported, but under the different spelling "sealed".  This qualifies for "Partial" support in my table.

Minimal GC support: As it turns out, N2670's only user-visible changes are a bunch of no-op Standard Library functions, which we already picked up in VC10.

Reworded sequence points: After staring at N2239's changes, replacing C++98/03's "sequence point" wording with C++11's "sequenced before" wording (which is more useful, and more friendly to multithreading), there appears to be nothing for a compiler or Standard Library implementation to do.  So I've marked this as N/A.

Atomics, etc.: Atomics, strong compare and exchange, bidirectional fences, and data-dependency ordering specify Standard Library machinery, which we're implementing in VC11.

Memory model: N2429 made the Core Language recognize the existence of multithreading, but there appears to be nothing for a compiler implementation to do (at least, one that already supported multithreading).  So it's N/A in the table.

Extended integer types: N1988 itself says: "A final point on implementation cost: this extension will probably cause no changes in most compilers. Any compiler that has no integer types other than those mandated by the standard (and some version of long long, which is mandated by the N1811 change) will likely conform already."  Another N/A feature!

That covers the Core Language.  As for the Standard Library, I don't have a pretty table of features, but I do have good news:

In VC11, we intend to completely support the C++11 Standard Library, modulo not-yet-implemented compiler features.  (Additionally, VC11 won't completely implement the C99 Standard Library, which has been incorporated by reference into the C++11 Standard Library.  Note that VC10 and VC11 already have <stdint.h>.)  Here's a non-exhaustive list of the changes we're making:

New headers: <atomic>, <chrono>, <condition_variable>, <future>, <mutex>, <ratio>, <scoped_allocator>, and <thread>.  (And I've removed the broken <initializer_list> header that I accidentally left in VC10.)

Emplacement: As required by C++11, we've implemented emplace()/emplace_front()/emplace_back()/emplace_hint()/emplace_after() in all containers for "arbitrary" numbers of arguments (see below).  For example, vector<T> has "template <typename... Args> void emplace_back(Args&&... args)" which directly constructs an element of type T at the back of the vector from an arbitrary number of arbitrary arguments, perfectly forwarded.  This can be more efficient than push_back(T&&), which would involve an extra move construction and destruction.  (VC10 supported emplacement from 1 argument, which was not especially useful.)

Faux variadics: We've developed a new scheme for simulating variadic templates.  Previously in VC9 SP1 and VC10, we repeatedly included subheaders with macros defined differently each time, in order to stamp out overloads for 0, 1, 2, 3, etc. arguments.  (For example, <memory> included the internal subheader <xxshared> repeatedly, in order to stamp out make_shared<T>(args, args, args).)  In VC11, the subheaders are gone.  Now we define variadic templates themselves as macros (with lots of backslash-continuations), then expand them with master macros.  This internal implementation change has some user-visible effects.  First, the code is more maintainable, easier to use (adding subheaders was a fair amount of work), and slightly less hideously unreadable.  This is what allowed us to easily implement variadic emplacement, and should make it easier to squash bugs in the future.  Second, it's harder to step into with the debugger (sorry!).  Third, pair's pair(piecewise_construct_t, tuple<Args1...>, tuple<Args2...>) constructor had "interesting" effects.  This requires N^2 overloads (if we support up to 10-tuples, that means 121 overloads, since empty tuples count here too).  We initially observed that this (spamming out so many pair-tuple overloads, plus all of the emplacement overloads) consumed a massive amount of memory during compilation, so as a workaround we reduced infinity.  In VC9 SP1 and VC10, infinity was 10 (i.e. "variadic" templates supported 0 to 10 arguments inclusive).  In the VC11 Developer Preview, infinity is 5 by default.  This got our compiler memory consumption back to what it was in VC10.  If you need more arguments (e.g. you had code compiling with VC9 SP1 or VC10 that used 6-tuples), there's an escape hatch.  You can define _VARIADIC_MAX project-wide between 5 and 10 inclusive (it defaults to 5).  Increasing it will make the compiler consume more memory, and may require you to use the /Zm option to reserve more space for PCHes.

This story has a happy ending, though!  Jonathan Caves, our compiler front-end lord, investigated this and found that something our tuple implementation was doing (specifically, lots of default template arguments), multiplied by pair's N^2 overloads, multiplied by how much pair tends to get used by STL programs (e.g. every map), was responsible for the increased memory consumption.  He fixed that, and the fix is making its way over to our STL branch.  At that point, we'll see if we can raise the _VARIADIC_MAX default to 10 again (as I would prefer not to break existing code unnecessarily).

Randomness: uniform_int_distribution is now perfectly unbiased, and we've implemented shuffle() in <algorithm>, which directly accepts Uniform Random Number Generators like mersenne_twister.

Resistance to overloaded address-of operators: C++98/03 prohibited elements of STL containers from overloading their address-of operator.  This is what classes like CComPtr do, so helper classes like CAdapt were required to shield the STL from such overloads.  During VC10's development, while massively rewriting the STL (for rvalue references, among other things), our changes made the STL hate overloaded address-of operators even more in some situations.  (You might remember one of my VCBlog posts about this.)  Then C++11 changed its requirements, making overloaded address-of operators acceptable.  (C++11, and VC10, provide the helper function std::addressof(), which is capable of getting the true address of an object regardless of operator overloading.)  Before VC10 shipped, we attempted to audit all STL containers for occurrences of "&elem", replacing them with "std::addressof(elem)" which is appropriately resistant.  In VC11, we've gone further.  Now we've audited all containers and all iterators, so classes that overload their address-of operator should be usable throughout the STL.  Any remaining problems are bugs that should be reported to us through Microsoft Connect.  (As you might imagine, grepping for "&elem" is rather difficult!)  I haven't audited the algorithms yet, but a casual glance indicated to me that they aren't especially fond of taking the addresses of elements.

We're also going beyond C++11 in a couple of ways:

SCARY iterators: As permitted but not required by the C++11 Standard, SCARY iterators have been implemented, as described by N2911 "Minimizing Dependencies within Generic Classes for Faster and Smaller Programs" and N2980 "SCARY Iterator Assignment and Initialization, Revision 1".

Filesystem: We've added the <filesystem> header from the TR2 proposal, featuring super-cool machinery like recursive_directory_iterator.  Note that the 2006 proposal (before work on TR2 was frozen due to C++0x running extremely late and turning into C++11) was derived from Boost.Filesystem V2.  It later evolved into Boost.Filesystem V3, but that will not be implemented in VC11.

Finally, in addition to numerous bugfixes, we've performed a major optimization!  All of our containers (loosely speaking) are now optimally small given their current representations.  This is referring to the container objects themselves, not their pointed-to guts.  For example, vector contains three raw pointers.  In VC10, x86 release mode, vector was 16 bytes.  In VC11, it's 12 bytes, which is optimally small.  This is a big deal if you have 100,000 vectors in your program - VC11 will save you 400,000 bytes.  Decreased memory usage saves both space and time.

This was achieved by avoiding the storage of empty allocators and comparators, as std::allocator and std::less are stateless.  (We'll activate these optimizations for custom allocators/comparators too, as long as they're stateless.  Obviously, we can't avoid storing stateful allocators/comparators, but those are quite rare.)

Here are all of the sizes for x86 and x64.  (32-bit ARM is equivalent to x86 for these purposes).  Naturally, these tables cover release mode, as debug mode contains checking machinery that consumes space and time.  I have separate columns for VC9 SP1, where _SECURE_SCL defaulted to 1, and for VC9 SP1 with _SECURE_SCL manually set to 0 for maximum speed.  VC10 and VC11 default _SECURE_SCL to 0 (now known as _ITERATOR_DEBUG_LEVEL).

 

x86 Container Sizes (Bytes) VC9 SP1 VC9 SP1
SCL=0
VC10 VC11
vector<int> 24 16 16 12
array<int, 5> 20 20 20 20
deque<int> 32 32 24 20
forward_list<int> N/A N/A 8 4
list<int> 28 12 12 8
priority_queue<int> 28 20 20 16
queue<int> 32 32 24 20
stack<int> 32 32 24 20
pair<int, int> 8 8 8 8
tuple<int, int, int> 16 16 16 12
map<int, int> 32 12 16 8
multimap<int, int> 32 12 16 8
set<int> 32 12 16 8
multiset<int> 32 12 16 8
hash_map<int, int> 72 44 44 32
hash_multimap<int, int> 72 44 44 32
hash_set<int> 72 44 44 32
hash_multiset<int> 72 44 44 32
unordered_map<int, int> 72 44 44 32
unordered_multimap<int, int> 72 44 44 32
unordered_set<int> 72 44 44 32
unordered_multiset<int> 72 44 44 32
string 28 28 28 24
wstring 28 28 28 24

 

x64 Container Sizes (Bytes) VC9 SP1 VC9 SP1
SCL=0
VC10 VC11
vector<int> 48 32 32 24
array<int, 5> 20 20 20 20
deque<int> 64 64 48 40
forward_list<int> N/A N/A 16 8
list<int> 56 24 24 16
priority_queue<int> 56 40 40 32
queue<int> 64 64 48 40
stack<int> 64 64 48 40
pair<int, int> 8 8 8 8
tuple<int, int, int> 16 16 16 12
map<int, int> 64 24 32 16
multimap<int, int> 64 24 32 16
set<int> 64 24 32 16
multiset<int> 64 24 32 16
hash_map<int, int> 144 88 88 64
hash_multimap<int, int> 144 88 88 64
hash_set<int> 144 88 88 64
hash_multiset<int> 144 88 88 64
unordered_map<int, int> 144 88 88 64
unordered_multimap<int, int> 144 88 88 64
unordered_set<int> 144 88 88 64
unordered_multiset<int> 144 88 88 64
string 40 40 40 32
wstring 40 40 40 32

 

Stephan T. Lavavej
Visual C++ Libraries Developer

  • sch: make_pair()'s signature has changed:

    C++03: template <class T1, class T2> pair<T1, T2> make_pair(T1 x, T2 y);

    C++11: template <class T1, class T2> pair<V1, V2> make_pair(T1&& x, T2&& y);

    There are several subtleties in both the C++03 and C++11 versions (C++03 taking values - changed from C++98 - and C++11 returning decayed types). As I recall, VC10 had four overloads, which may or may not have corresponded to a Working Paper at some point in time, but the final version of C++11 specifies the single function template above, and that's what we've implemented in VC11. It's Saturday, so I hope you won't mind if I skip directly to the high-level summary:

    C++11 make_pair() is now a perfect forwarding function. This is a good thing (it's more efficient), but it's also incompatible with most uses of explicit template arguments. As it turns out, that's fine because make_pair()'s whole purpose in life is to be used WITHOUT explicit template arguments.

    Here's why make_pair() exists. You can always write pair<A, B>(a, b) to construct a temporary pair. But you've already got a and b, and the compiler knows their types, so having to specify A and B again is annoyingly verbose (as usual, it could easily be pair<string, shared_ptr<Polygon>> or whatever). There's no such thing as "template argument deduction for class templates", so you can't write pair(a, b), but there is for function templates. Therefore, when you need a temporary pair, you can write make_pair(a, b). Giving explicit template arguments to make_pair() is unnecessary, and defeats its purpose.

    (Very rarely, when you need more control over the pair's type, you can say pair<unsigned short, unsigned short>(17, 29). Again, saying make_pair here would be more verbose.)

    This is one of a few breaking changes in the Standard Library that I'm aware of (the other major ones are immutable sets, and 2D vector construction).

    This is also a special case of a general rule - explicit template arguments shouldn't be given to function templates, except when they're specifically designed for it - for example, forward<T>(t) and make_shared<T>(args, args, args). Notice that in make_shared()'s case, only the object type is explicit - the argument types should be implicitly deduced. When you give explicit template arguments to function templates that weren't designed for it, you'll tend to run into trouble with perfect forwarders (where you end up generating the wrong type), other overloads (where you end up triggering compiler errors in unrelated code), and helper functions (where your explicit template arguments don't reach). Just let template argument deduction do its job, and all will be well.

  • So, the features marked with 'No' won't make it to VS11? Does it mean that the release of VS11 is really soon and there's no time? Or is it because at some point the VS team decides "let's freeze development and start testing/fixing bugs"? I mean if it's not going to be released in 6 months, you guys might as well push more C++11 features into it.

    I'm making guesses about it being released very soon because for VS10 Stephan posted C++11 features only a few days before the release. I know you guys can't say any exact dates, but I'm sure you can confirm if it's 'soon' or 'not soon'.

  • Re. using C++ in the new WinRT/Metro runtime. It looks good except the fact that we have to use the hat (^) as a fancy double pointer for say accessing XAML objects (and some other extensions like % for a tracking reference).

    Previously when used for C++/CLI I could understand the reasons for the hat, with the garbage collector moving memory around. But WinRT is supposed to use ref-counting/COM-style only. If I could call a CComPtr->method using standard C++ syntax 10 years ago, why cannot I do that today in WinRT?

    I'm hoping I am wrong here, but doesn't this just smell of "embracing and extending" the C++ standard?

  • @Henry,

    It is possible to be hatless in calling WinRT as Deon explains

    channel9.msdn.com/.../TOOL-690C

    You should also check out

    social.msdn.microsoft.com/.../threads

    Mr Brandon Paddock of [MSFT] wrote on Saturday:

    ___________________

    Hi guys.  Let me see if I can clear this up a bit more:

    First, WinRT, as mentioned, is built on an evolved version of COM.

    The WinRT library included with Windows 8 is built from interfaces defined in IDL just like COM intefaces in prior versions of Windows, and the implementations of those interfaces are called Runtime Classes (think of this as the evolution of "CoClass" in COM).

    Before you say "Ew, COM" (if you were going to say that), note two things:

    1) This is, as they say, not your grandfather's COM.  One small example: Intead of IUnknown as the base interface for all things, we now have IInspectable.  This brings a lightweight sort of "reflection" which is used in projecting these APIs to different languages and runtime environments, and also to enable better tooling.  The IDL compiler and syntax have seen huge investments as well.

    2) You don't have to know or care about how the internals work if you just want to work with the high-level projection.

    As a developer you have basically 4 options for interacting with the Windows Runtime:

    1) The JavaScript projection.

    2) The .NET projection.

    3) The C++ "high level" projection, which makes use of WinRT language extensions.

    4) No projection at all, what we call "the ABI."  No language extensions are needed.

    Option #3 will make a lot of sense for a great many C++ developers.  You get to take advantage of the performance and control of native code, without having to learn COM, and with the ability to write much more succinct code.  If you're a C++ developer I highly recommend you at least give this a shot.  I was skeptical when I first saw it (what's the crazy hat thing?!?) but after playing with it for even just a few minutes, the advantages became pretty obvious.  If you're a cross-platform dev, I expect you'll be asking for this on other platforms, versus wanting to get rid of it from ours.

    However, Option #3 is in the end syntactic sugar over #4.  Writing directly to the ABI will feel most natural to seasoned COM developers.  There's also a new template library (WRL) which someone mentioned earlier in this thread, which provides a lightweight set of utilities similar to what you may have used in ATL before (for example, ComPtr<>).  It also includes several new helpers for things like async callbacks.  And they're all template based (and very friendly to C++ 0x features like lambdas), so no language extensions are required.

    The "high level" C++ projection and the associated set of language extensions do exactly the same thing as the raw ABI plus the WRL templates.  But the template solution can feel kludgey, especially to developers coming from the C# or Java world.  By extending the language to be aware of concepts like refcounting and partial classes, you end up with something much more inviting to those developers, not to mention toolable.

    Oh, and one more difference between #3 and #4... the raw ABI is all HRESULT based.  The projections (including the C++ projection) are exception based.  This often means the projection is better suited for use with other exception-based libraries (like STL).

    Hope that helps.  For more details, the various talks from //BUILD are the place to look.  Also the DirectX sample on the dev center demonstrates usage of WRL and the raw ABI (actually, it seems to mix both, but still provides an example of using WRL).  Also I just found a form post by Herb Sutter which addresses this same question.

    Brandon

  • @AndrewDover - thank you for the links. I must say that at first I was also a little disappointed with all those "DotNet-ish" syntax extensions, but after learning details and the rationale - it looks much better to me. It's like bringing c++ back into Windows Developing mainstream, which is great for c++ developers.

  • @AndrewDover - yet thanks for your answer. Reading through the posts you linked to, you can

    tell people react really bad to this "embrace and extend" strategy.

    As I understand it now: WinRT uses IInspectable is the new lowest common denominator, its vtable has 6 methods, where the first 3 are the same classic IUnknown methods and the rest are a new (mandatory) flavor of the old IDispatch interface, for type reflection. And you can party on those vtables using vanilla C++ syntax, yes!

    Typelibrary .tlb files are replaced with .winmd files, which are .NET-flavored code-less DLLs (so a *very* small part of .NET remains with us).

    At PDC 2001 the mantra was: "no more HRESULTs" (because .NET was introduced), today the mantra is "HRESULTs are back". Funny how history repeats itself.

  • Also: re. specters of FUD, I can agree to forget about "embrace and extend" but there's one more lurking I think: "not invented here".

    After IUnknown and COM was conceived, in C++ we've seen auto_ptr prosper and die, and today instead we have shared_ptr. It's great and just works.

    Using such stuff from the C++ community could benefit Microsoft, I am sure that a flavor of shared_ptr could be retrofitted for accessing the WinRT runtime. It's just a matter of will :-)

  • Okay, from the links @AndrewDover posted, it looks like you can talk to WinRT using true C++, without the extensions.  However, MS really needs to come up with another name for "C++ with MS extensions"; there have been many postings in which they refer to it as simply "C++" or "native C++".  This is setting off a lot of warning bells from people who remember prior occasions where Microsoft extended standards with the apparent intent to co-opt them.  I'm not saying that that is MS's intent here, but people have good reason to be wary.  The "C++" label should only be applied to ISO-valid C++; anything else should have a "MS-Proprietary" or similar label on it.

  • > I'm not saying that that is MS's intent here, but people have good reason to be wary.  

    > The "C++" label should only be applied to ISO-valid C++;

    > anything else should have a "MS-Proprietary" or similar label on it.

    +1.

  • My company develops mostly server-side applications so we do not need (or want) proprietary Windows extensions.

    We were planning on moving to C++11 next year.  The idea was to purchase the next Visual Studio for the developers and keep using Windows both on the dev workstations and servers.

    However, seeing that MS is not committed to standard-conforming C++, we now prefer the following option:

    Migrate the developers to Linux and GCC.  Migrate the servers to some combination of AIX and Linux.

    Work has already started.

    I guess that will also save us quite a bit on licensing costs as we expand.

    Personally, I would have loves to stay with Visual Studio but apparently this will not happen.

  • We don't really need Visual Studio as an IDE anyway with the excellent CDT plugin for Eclipse. And that application is also much better performing than VS '10.

  • For those who haven't read the Sutter presentation linked above, it looks like the reason there are so few C++11 features is that they tried very hard to get variadic template support into VC11, but it turned out to be harder than they thought, and wasn't quite ready by code freeze.  Consequently, they'd spent their developer's time on a feature that didn't quite make it.  Sutter said that they would try to deliver variadic templates sometime after VC11, but sooner than the normal development cycle would indicate; presumably, this would mean some kind of service pack.  However, he made no promises.

    Which, I suppose, is a reasonable explanation for the fairly uninspiring list above.  If it were me, I'd have held the release to deliver variadic templates, but I suspect that higher powers were demanding that the VS team deliver WinRT development capabilities ASAP.

    However, what this does not justify is MS's apparent lack of resource commitment and/or forethought toward implementing C++11.  This standard has been coming for a long time, through a very transparent process.  The variadic template spec (N2555), in particular, was approved in March of 2008.  MS had ample time (and more than ample money) to hire two or three more developers and spin them up onto the compiler team in order to be able to start work on the new features as their working papers were incorporated into the draft standard, so that they could deliver them quickly once the standard was final.  I would consider this a mistake in prioritization and/or project management; either a manager somewhere did not ask for these resources, or they did ask, and someone refused to authorize them.  That's what led to the current imbroglio.

  • Looks like my first comment didn't go through ? I retry :

    "Standard-layout and trivial types: As far as I can tell, the user-visible changes from N2342 "POD's Revisited; Resolving Core Issue 568 (Revision 5)" are the addition of is_trivial and is_standard_layout to <type_traits>. [...].  In VC11, they're powered by compiler hooks that should give accurate answers."

    Then why you don't use those improvements in the standard library ?

    In VC11 developer preview, you only go to the memmove optimization (for example for std::copy(T*, T*, T*)), in the very narrow case of T being a scalar, instead of optimizing for the general case if T satisfy std::is_trivially_copy_assignable.

  • Thomas P.: Generalizing that optimization is on my todo list. I have to prioritize new features, major optimizations, and bugfixes over minor optimizations, so I can't promise that I'll get to this in VC11.

  • 1. Will it be possible to run VC11 on Windows 7 and build apps for Windows 7 with it?

    2. For simple lambdas (i.e. no static variables in lambdas, no nested lambdas), is the implementation available in VC10 compatible with the one in VC11? In other words, will our VC10 "simple" lambdas compile fine in VC11?

    3. Are the GCC STL containers as small as these new MSVC ones?

    Thanks!

Page 7 of 11 (151 items) «56789»