C++0x Core Language Features In VC10: The Table

C++0x Core Language Features In VC10: The Table

Rate This
  • Comments 40

When we announced that the Visual Studio 2010 Release Candidate Is Now Available For Download, a reader, Igor, asked us to provide a table summarizing which C++0x Core Language features are implemented in VC10.  So, here it is!  It's derived from, but slightly modified from, GCC's tables.  For example, I added "Rvalue references v2".

 

C++0x Core Language Features

VC9

VC10

Rvalue references

No

v2

    Rvalue references v2

No

v2

    Rvalue references for *this

No

No

    Initialization of class objects by rvalues

Yes

Yes

static_assert

No

Yes

auto

No

Yes

    Multi-declarator auto

No

Yes

    Removing old auto

No

Yes

    Trailing return types

No

Yes

Lambdas

No

v1.0

decltype

No

Yes

Right angle brackets

Yes

Yes

Extern templates

Yes

Yes

nullptr

No

Yes

Strongly typed enums

Partial

Partial

Forward declared enums

No

No

Extended friend declarations

Partial

Partial

Local and unnamed types as template arguments

Yes

Yes

C++0x Core Language Features: Concurrency

exception_ptr

No

Yes

Thread-local storage

Partial

Partial

C++0x Core Language Features: C99

__func__

Partial

Partial

C99 preprocessor

Partial

Partial

long long

Yes

Yes

 

While I can't explain all of these features here, I can link to my posts about lambdas v1.0, auto, and static_assert, rvalue references v1, and decltype, and I can decode some of the more mysterious cells in this table.

 

The difference between what I call "rvalue references v1" and "rvalue references v2" is that v1 allowed rvalue references to bind to lvalues, while v2 forbids this.  N2844 "Fixing a Safety Problem with Rvalue References" describes the reasons for this change.  It was recently voted into the C++0x Working Paper, and there was enough time for us to implement it in VC10.  (Importantly, rvalue references v2 doesn't affect the move semantics or perfect forwarding patterns, but it does affect the implementation of std::move() and std::forward<T>(), and experts need to know about this change.)

 

The difference between what I call "lambdas v1.0" and "lambdas v1.1" is much less significant.  After lambdas were voted into the Working Paper and implemented in VC10, N2927 "New wording for C++0x Lambdas" was additionally voted into the Working Paper, clarifying subtleties like what happens with nested lambdas.  Common uses of lambdas aren't really affected, but unusual uses may be.

 

The "Partial" entries indicate that VC's support is either incomplete (as in the case of the C99 preprocessor, where variadic macros are implemented but mixed narrow/wide string literal concatenation isn't), or in a non-Standard form (as in the case of __func__, where __FUNCTION__ is implemented).

 

I don't have a similar table for the C++0x Standard Library features implemented in VC10 (preparing one based on N2870 would take a while), but slides 28 and beyond of my BoostCon 2009 presentation (attached below) contain a useful summary.

 

Stephan T. Lavavej

Visual C++ Libraries Developer

(July 13, 2010 update: reformatted table, corrected "Forward declared enums" row.)

Attachment: vc10-1 1.pptx
  • Just to add to the queue - variadic templates and template typedefs were ommited by mistake in this table or they are just NOT implemented for vc10 release????? both features are huge improvements and programming without them is plain frustrating :(

    Also, strongly typed enums seem to be only "partially" implemented ... what are the differences?

  • I would be interested in the differences, too.

    @Ema Nymton: ifyou post case links, we can vote to reopen ;)

  • @Joe: There are *many* features not on the list. I'm guessing the table only shows the features of relevance to VC10 (that is, where full or partial support exists), or as in the rvalue *this case, which are part of a larger feature supported by VC10.

    There are far more language changes in C++0x than this table shows.

    @Name changed to protect innocent: Perhaps. It depends on where you look. On StackOverflow.com, C++ questions far outnumber C questions.

    I don't know which language is most popular globally, but note that a huge amount of the C development being done is in Linux-centric projects. In the Windows world, C++ seems to be relatively more popular. And I somehow doubt Linux development is one of the main goals with VC10.

    Of course, we could sum up this argument as "the MSVC team has stated before that they're not implementing C99 due to lack of demand from customers". Whether or not C is the most widely used language worldwide, it doesn't seem to be a priority among VS customers.

  • http://wiki.apache.org/stdcxx/C++0xCompilerSupport

    This seems to be a more complete table of C++0x support in various compilers (including MSVC),

  • At what level are the new strongly typed enums and forward declaration of enums?  The table says, "partially," but I can't seem to perform even the simplest use.

  • I, too, would like to see an example of the existing support for strongly typed enums.

  • [phrosty]

    > I ran into scoping problems with the lambdas and filed a bug (537366) on it -- it seems like you already know this (dubbing the fixed implementation "1.1"), so I'm very glad to see you're on top of things!

    Correct, we're aware of this, and we're working on fixing it.

    [jalf]

    > Regarding the difference between lambdas 1.0 and 1.1, is that what causes the the problems described here: http://blackninjagames.com/?p=38 ?

    > I'm curious if the problem is an actual compiler bug or just that you've implemented an earlier and outdated specification. (Also of course, hoping it'll be fixed ASAP, in a service pack or similar)

    That's definitely a bug according to lambdas v1.1, but I'm not sure whether it was a bug according to lambdas v1.0. (One of the problems with the v1.0 specification was that it wasn't crystal clear about situations like this.)

    > A similar list of library features would be nice too, if you can find the time to make it. :)

    My BoostCon 2009 presentation should be an acceptable substitute.

    > I hope we won't have to wait 2-3 years for VC11 to see more language features added though.

    As a general rule, you shouldn't expect to see new features in service packs. We make exceptions to this rule, but they are few and far between.

    (We don't consider lambdas v1.1 to be a new feature, merely a set of bugfixes. I can't promise that it'll appear in a service pack, but we're keenly aware of the user demand for it.)

    > I know you've said that "10 is the new 6" before

    Plural "you" yes, singular "you" no. The "10 is the new 6" slogan applied to the IDE; everyone's aware that VC6's compiler and libraries were terribly nonconformant. Because I don't use the IDE (except for occasional debugging), my usual saying has been "10 is bigger than 9".

    [Alef Sin]

    > Any plans for Variadic templates (N2242)?

    Implementing variadic templates is my number one request for VC11. I can't promise that I'll get what I want, but I can promise that I'll be loudly campaigning for it.

    (Our Standard Library implementation is suffering greatly due to the absence of variadic templates, and I like to say that the Standard Library is the compiler's "first and best customer".)

    [Ramon]

    > Thanks for the table. With impatience I wait "constexpr".

    [JK]

    > yes, constexpr PLEASE. also noexcept

    We're aware of the optimization opportunities unlocked by constexpr.

    As for noexcept (a very recent feature), we're aware that solving the Dreaded Throwing Move Constructor Problem would be very nice indeed.

    [Joe]

    > There are a few features not on this list.  What are the statuses of Variadic Templates and template aliases?

    Not implemented in VC10.

    [Ema Nymton]

    > Also note that in MS lingo (Microspeak), "Yes" actually means "Partial" for some of the features.

    I've tried to be as accurate as possible. There are bugs, but there are always bugs, and we fix them when they're reported to us in time and we have the resources to fix them without destabilizing other stuff.

    [Florin Neamtu]

    > Also, strongly typed enums seem to be only "partially" implemented ... what are the differences?

    We've provided the ability to specify the underlying type of an enum.

    [Noah Roberts]

    > At what level are the new strongly typed enums and forward declaration of enums?  The table says, "partially," but I can't seem to perform even the simplest use.

    I'll ask our compiler dev about forward declared enums. He said that VC9/VC10 have some support for them, but didn't elaborate.

    Stephan T. Lavavej, Visual C++ Libraries Developer

  • @Stephan T. Lavavej:

    > I'll ask our compiler dev about forward declared enums. He said that VC9/VC10 have some support for them, but didn't elaborate.

    Don't scare me like that.  I hope that you have more than one dev working on the compiler ;)

  • <i>[Noah Roberts]

    > At what level are the new strongly typed enums and forward declaration of enums?  The table says, "partially," but I can't seem to perform even the simplest use.

    I'll ask our compiler dev about forward declared enums. He said that VC9/VC10 have some support for them, but didn't elaborate.

    </i>

    I found some information on forward declaring enums but the type section can't be used.  This fails but should work:

    enum E : short;

    This works but should fail:

    enum E;

    This works but gives a non-standard warning:

    enum E : short { test };

    This fails:

    enum E;

    E f();

    enum E : short { test };

    E f() { return test; } // different return type.

    I also may have found the strongly typed enum information.  It appears to not work at all in C++ but is available in your home-brew language C++/CLI.  Is this correct?

  • template < typename T >

    struct test { T t; };

    template < typename T1, typename T2 >

    auto operator + (test<T1> const& lh, test<T2> const& rh) -> test<decltype(lh.t + rh.t)>

    {

     test<decltype(lh.t+rh.t)> ret = { lh.t + rh.t};

     return ret;

    }

    ...

    test<int> t1 = {5};

    test<double> t2 = {6.66};

    test<double> t3 = t1 + t2; // fails.  No conversion from test<const double> to test<double>.

    ============================

    Bug or feature?  We've discussed this in comp.lang.c++ and we're all surprised.

  • @ Noah Roberts

    > I also may have found the strongly typed enum information.  It appears to not work at all in C++ but is available in your home-brew language C++/CLI.  Is this correct?

    I think it has been around in CC++/CLI for a long time.

    If you look for the enum examples, and use the C++ tab, you'll see it.

    http://msdn.microsoft.com/en-us/library/system.enum.aspx

  • Could you please add these features to C++/cli also-- I'm finding that using C++/cli to expose C++ to .Net results in alot of my code not compiling because C++/cli does not support C++0x features.

    Thanks

  • Today, I tested VC++ 10.0, it is very very cool, I think. We always use Visual C++ 6.0 to build our leading Visualization Library: E-XD++ (http://www.ucancode.net), but now, it is time to move to VC++ 10.0 I think.

    jack

  • [JK]

    > Don't scare me like that.  I hope that you have more than one dev working on the compiler ;)

    We have several compiler front-end devs, but only one of them added new features to the real compiler front-end C1XX in VC10. The rest of them were working on the EDG-powered Intellisense front-end.

    (We have many compiler back-end devs; I forgot to distinguish between the FE and BE.)

    [Noah Roberts]

    > This works but should fail:

    > enum E;

    Correct, that's an evil non-Standard (98/03/0x) extension. The "Forward declared enums" row should say "No" for VC9 and VC10. I apologize for not figuring this out before.

    It's correct for the "Strongly typed enums" row to say "Partial", as our non-Standard (98/03) extension of specifying the underlying type of an enum is now part of C++0x (there may be some differences in the details; "Partial" is exactly what it says on the box). We still have warnings that complain that it's non-Standard (which is incorrect with respect to C++0x), but the ability is there.

    > I also may have found the strongly typed enum information.

    > It appears to not work at all in C++

    The underlying type part works.

    > but is available in your home-brew language C++/CLI.  Is this correct?

    My table refers to native C++ only. C++/CLI, about which I know virtually nothing, contains a very similar (possibly identical) feature to C++0x's strongly typed enums.

    > test<double> t3 = t1 + t2; // fails.  No conversion from test<const double> to test<double>.

    > Bug or feature?  We've discussed this in comp.lang.c++ and we're all surprised.

    Bug, filed as internal bug number Dev10#887895. Given const test<int>& lh, const test<double>& rh, lh.t is const int and rh.t is const double. decltype(const int + const double) should be double, not const double, and GCC 4.4.1 agrees (both given this code, and plain decltype(ci + cd)).

    [shaz]

    > Could you please add these features to C++/cli also-- I'm finding that using

    > C++/cli to expose C++ to .Net results in alot of my code not compiling

    > because C++/cli does not support C++0x features.

    In general, you should be able to take native C++ using C++0x features and compile it with /clr. The major exception to this is nullptr - unfortunately, both C++0x and C++/CLI have nullptr, but with different semantics, and we weren't able to figure out whether they could be unified in time for VC10 (much less actually unify them). So, when compiling as native, nullptr is the "native nullptr", and when compiling as managed, nullptr is the "managed nullptr". We've provided __nullptr, which is always the "native nullptr".

    Using C++0x features with managed types may or may not work. I know that lambdas can't capture managed types (although they can be passed managed types like any other function).

    Stephan T. Lavavej, Visual C++ Libraries Developer

  • Hello VC Team,

    I recently learned about Code Document Object Model or CodeDOM classes of .NET 4.0 and I explored CppCodeProvider assembly for C++ developper interest. I was supprised that some classes are not fully implemented like CppCodeGenerator (marked obsolete) or Cpp CodeCompiler is missed so     I am not able to build a sample I took in MSDN about a simple C++/CLI syntaxe of Hello World Program to produce a correct Code DOM program graph and to build it into a assembly.

    I also recently learned in MSDN 2010 that it is possible to add a personnal BuildProvider class in <System.CodeDom> section of a web.config file of an ASP.NET Web Site Project. So It is possible to route ASP.NET Build Environnement to execute our CppCodeProvider to produce C++/CLI code as code behind of an ASP.NET Web page. Why no person of the team is focused on that possibility? Is it possible to add the keyword partial in C++/CLI syntaxe because it is required for language that support ASP.NET.

    Thanks, Excuse-me my english.

Page 2 of 3 (40 items) 123