We just shipped Visual C++2013 last month, but I announced at GoingNative in September that there would be more soon: another CTP (compiler preview) containing another batch of C++11/14 features, sometime in the fourth quarter.
I’m happy to report that today we shipped the promised CTP. Compared to the “high probability in CTP” feature set I mentioned in my GoingNative talk, one of those features I mentioned didn’t quite make it (C++14 generalized lambda capture, a.k.a. move capture and more), but to compensate, both medium-probability features made it (C++14 generic lambdas and C++11 inheriting constructors) plus, as a bonus, also alignof and alignas which we didn’t think would make it for the CTP but did. Here’s the full set of new features, pasting from the announcement:
- Implicit move special member function generation (thus also completing =default)
- Reference qualifiers on member functions (a.k.a. “& and && for *this“)
- Thread-safe function local static initialization (a.k.a. “magic statics”)
- Inheriting constructors
- alignof/alignas
- __func__
- Extended sizeof
- constexpr (except for member functions)
- noexcept (unconditional)
- C++14 decltype(auto)
- C++14 auto function return type deduction
- C++14 generic lambdas (with explicit lambda capture list)
- (Proposed for C++17) Resumable functions and await
The most-requested feature of C++14, and the one I’ve personally been anticipating the most, is generic lambdas — it is sweet to see it working right within Visual Studio 2013, as the CTP installs as a selectable toolset you can use within the shipping product to edit and build (no Intellisense or red squiggles though). Note that for this CTP, your lambda can be either generic (have an auto parameter type) or have a default capture list (e.g., [=] or [&]), but not both — of course we’ll support both together in the future as the feature makes a future release.
As far as I know, this Visual C++ CTP is the first shipping (albeit CTP quality) C++ compiler to offer generic lambdas, though I expect Clang and gcc to also make them available soon — joy for C++ developers everywhere!
Once again, thank you very much again to the great Visual C++ team for producing this CTP; even as we speak, they’re hard at work on more. Thanks again also to the other members of the ISO C++ committee for producing a great and high-quality C++11 and soon-to-be-not-draft C++14.
I hope you enjoy trying out this CTP.
Sutter’s Mill 
风云雄霸天下服务端天之炼狱一条龙大话西游服务端精灵复兴服务端
劲舞团私服开服热血江湖私服开服倚天I私服开服网页游戏私服开服天堂2私服开服
骑士开区一条龙天上碑开区一条龙美丽世界开区一条龙科洛斯开区一条龙石器时代开区一条龙
天龙八部开私服一条龙服务 http://www.e7if.com/
@Christian:
The bug you described here (defaulted move constructors don’t get generated if the class member doesn’t implement move semantics) has been fixed and the fix will be included in a future release of Visual Studio. Thanks for bringing the issue to our attention.
This CTP is a “compiler-only” CTP. As I mentioned in my past couple of Build talks, it’s intended to give a “P”review of new features but is primarily about the batch compiler. You’ll see oddities/discrepancies in the IDE, such as that Intellisense will be unchanged so the batch compiler using the CTP toolset will accept code that the IDE still gives red squigglies for.
Hi,
Is there any plan to make the debugger work properly with this CTP? I really like cool features of this CTP but its a pain trying to use the debugger. Visual Studio crashes always when deferencing a nullptr
Thanks
Additional words of the previous post:
1. Using the ‘forward’ in the previous post is only for convenient for discuss. Usually it should be a function that makes an rvalue-reference as the return value from itself.
2. When an rvalue-reference is actually a lvalue, it should be okay for all situation so far, let the coder fix any bad case he made. See the code bellow:
void ftest(C1 && val)
{
local1 & a = val; // okay
…
std::cout << val.m << std::endl;// OK. Access to the content of the 'val' directly.
std::cout << a.m << std::endl;// OK. Access to the content of the 'val' through a reference to it.
}
The commented lines are different from the 'C1 && i3 = std::forward(C1());'.
Sorry for bothering you after months your doc being posted, Sutter. May I ask several question here? Okay I just post my first question to see if it’s noticed :) (and sorry about that again…)
Is it realy necessary to Allow the lifetime of the xvalue being expanded by allowing it to initialize a local rvalue reference? I think it may be the bad code formal in most of the time, isn’t it?
See the code below:
C1 i1{ std::forward(C1()) }; //OK. xv to lv.
C1 & i2 = std::forward(C1());//Error. Forbidden to initialize a lv-ref with rv-ref.
// Here is what i mention about[1]:
C1 && i3 = std::forward(C1());//xv to named rv-ref. Allowed to compile but meaningless and cause UB.
// But this is NOT included:
C1 && i4 = C1{} // prv to named rv-ref[2]. I think it’s still fine. because the rv the i4 catched is available in the full scopes.
I think the [1] should have been rejected by the compiler.
You may ask me about that, well, if it was realy true, Would be many stuffs not work? Like, how about the ‘forward’/’move’/other bunch of things themselves? No no no, what i wrote before doesn’t include these situations:
void_or_sth_2_ret foo(C1 && val);
…
foo(C1());//OK.
foo(std::forward(C1()));// Note this. What I said DOESN’T include this situation.
foo(std::forward(i4));// Note this. What I said DOESN’T include this situation either.
foo(std::move(i1));// Note this. What I said DOESN’T include this situation either.
Here is the point:
1. Comparison to the existing C++11 compiler, the only different is when an xvalue is to initialize an rvalue-reference, checks if that rv-ref(receiver) is a function’s argument. if not, then:
2. Either one of the following solution: [Forbidden the project from being compiled] OR [Force to make a copy of the xvalue(to let it becomes to situation [2]), or report compiling error if the copy-constructor of the type has been disabled(=delete/made ‘private’/’protected’)].
The same solution can be applied to [When an xvalue is used to initialize a constant lvalue-reference].
Shortly word: An xvalue can be used to initialize an rvalue-reference without copy only when that rvalue-reference is an argument of a function.
@xmllmx: Yes, that’s a bug and we do intend to fix it. I’ll see if we can say so better on the Connect bug itself. Thanks.
Hi, Sutter, The following code cannot be compiled by VC++ 2013 CTP, but it can be corretly compiled by GCC and CLang. struct A
{
// error C2216: ‘explicit’ cannot be used with ‘virtual’
virtual explicit operator bool() const
{
return true;
}
};
struct B : A
{
// error C2216: ‘explicit’ cannot be used with ‘override’
explicit operator bool() const override
{
return false;
}
};
int main()
{
if (A())
{}
if (B())
{}
}
I have submitted a bug at connect.microsoft.com; however, the handler seemed not considering this as a bug and ignored it. I eagerly hope VC++ can become more robust.
The generic lambdas are great! They allow really cool interfaces to optimizers. For example:
auto lambda = [](auto x) { auto d0 = x[1] - x[0]*x[0]; auto d1 = 1 - x[0]; return 100 * d0*d0 + d1*d1; }; auto differentiable = make_differentiable<2>(lambda);This was not possible before,because the automatic differentiation must be able to pass different types into the lambda. This works very well.
Here is an example of using resumable/await in a C++ Windows Store app while using SQLite:
http://stackoverflow.com/questions/19309508/using-sqlite-winrt-from-a-c-windows-store-app
@Aaron: See http://isocpp.org/std/submit-a-proposal.
@JC_Yang: Until recently, the standard didn’t acknowledge the existence of threads either – hence my query. “Thanks for the standard thread support! Can we please get a little love for processes?” “…Just a teeny, tiny bit?”
I’m fairly certain I’m not the guy to submit a proposal. I just don’t know the right place to make a suggestion/request, or to add my voice to those which must certainly have already been made.
@Aaron: forget to mention Boost::Interprocess, it probably can help you atm.
@Aaron: I haven’t read the C++ standard through, but IIRC, process as a term does not exist in the standard. One C++ program as a whole running in the abstract machine described by the standard might be somehow resemble a process, but still, it’s not process.
So adding any cross-process/multi-process stuff require significant change in the standard, wording, terms…etc and many subtle details.
Yes, I’d like to see some standardized IPC library, too. but probably not in the near future afaik.
Sorry I haven’t found a better place/way to ask but…
Is there (or can there please be) a plan for standard C++ *process* synchronization? I’m thinking something like Windows’ Mutex (cross-process, create locked, released by OS on process termination), but supporting shared locking as well.
Can somebody give me an example of how await/resumable work? I cant find any example that compiles
It’s great to be able to use the C++ compiler for C++ AMP. How about using C++ AMP for the C++ compiler?
C++11. Note that in the roadmap update C++14 generalized constexpr is a separate box on the right.
But inside those free functions, is the full C++14 relaxed constexpr syntax available (i.e for-loop and switch-statement) or only the single-return C++11 subset (i.e. recursion and ternary operator)?
@tomasu82: You should be able to use constexpr on variable declarations and free functions, but not on member functions yet. That will be implemented eventually but did not make it into this CTP.
With the new constexpr support, what exactly /is/ supported? I have some code that uses constexpr on some static class methods and const static member variables. Would that be supported? And if so, is there a way I can check that it is supported? say with a macro #if VER > ??
Thanks.
Great that we have 2013 CPT already.
It would be even better if http://rise4fun.com/Vcpp will support VS 2013 RTM and CTP them too.
@HGH: Good questions, see http://channel9.msdn.com/Events/Build/2013/2-306.
Summarizing: There are two streams, release and CTP, and by default you should expect new features to show up in the CTP stream and then in the next major release, not in Updates which are more about stability improvements. We do ship other kinds of features in Updates, such as IDE features that don’t break customers, but the compiler is widely depended upon and changes there can cause source breaking changes, so we normally do not ship compiler changes in Updates. This is especially true now as the source base is undergoing high rate of change both for new features and for AST and other rejuvenation; shipping constexpr would require shipping a major compiler source diff which is fine on a major release when people are expecting to tweak their sources in adopting a new compiler, but it would likely surprise a lot of people that they have to treat an Update that way.
Re date: We have not announced a date by which we’ll be fully compliant, in part because we don’t know :), and because we think reporting actual progress regularly is probably better than promises. So we have published a roadmap and have been updating it (most recently on the linked post) to share what we know when we know it. This way, you can extrapolate speed and expectations yourself based on the rate at which we actually ship features.
Interesting but.. Will all these features and the full C++11/14 support you’ve talked about be as a VS 2013 update or they will be released as VS2014/VS2015?
Will complete support for the specifications (compiler and library support) happen in 2014 or the year after?
@Christian: In the CTP, =default should now work for move special member functions, and generate what the compiler would have generated implicitly had the implicit generation not been suppressed (for example by declaring a copy operation or a destructor). In VS2013 RTM we didn’t yet allow =default for move ctor/op= because that compiler didn’t have the compiler-generated ones yet, so there was nothing for =default to do — now that the CTP has the compiler-generated ones, this also let us finish =default for move ctor/op=.
Edited to add: Your example is a bug in our compiler, logged. Thanks for the repro! As a workaround, you can =default the move operations of class Y (but you shouldn’t have to, we’ll fix it, just giving one possible workaround in the meantime).
This demonstrated the issue. Works with e.g. GCC 4.8.0, but not CTP.
#include <vector> int main() { class Y { public: Y() {}; Y(const Y&) {}; Y& operator=(const Y&) { return *this; }; }; class X { public: Y y; X() {}; // Not copyable X(const X&) = delete; X& operator=(const X&) = delete; #if 1 // Doesn't compile X(X&&) = default; X& operator=(X&& rhs) = default; #else // Compiles X(X&& rhs) { y = std::move(rhs.y); }; X& operator=(X&& rhs) { y = std::move(rhs.y); return *this; }; #endif }; std::vector<X> cs; cs.push_back(X()); return 0; }If CTP is right, what is the best way to avoid having to explicitly maintain the move constructor/assignment functions as new members are added to the class? Having to do this explicitly seems like a potential source for bugs (easy to forget to amend the move constructor/assignment).
Hi Herb,
Could you clarify this for me: what is the behaviour of the =default move constructor/assignment operator? The CTP seems to silently not generate them if one of the class members doesn’t implement move semantics (i.e. has C(C&&) and/or C& operator=(C&&)), whereas GCC-4.8.0 appears to do this (and instead copies the members in question).
[1] says “For a move, =default means member-wise move of each element, if possible, otherwise a compile-time
error is immediately given” but I have no idea if that document is current/official. This seems to match the CTP’s behaviour, but not GCC’s. Which one is right?
I was hoping to be able to use =default move-constructors/assignment instead of writing my own (where I have to move/copy each member in turn, and remember to also add any new members added later), but since some of the types I use doesn’t implement move semantics (they are from a library) it doesn’t appear I’m able to do this using the CTP — whereas GCC handles this fine.
Thanks in advance.
[1] http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2904.pdf
wow – generic lambdas in VC++ already – yay!! What a fun time to be a C++ programmer :)
Thanks Herb (and of course to the VC++ Team)!
Is there any ETA on a SP for the RTM? It contains a bunch of reproduceble ICEs (8 that I am aware of at connect) This really hinders us moving on to 2013
@Pal: It is a separate stream, think of it as (usually) an early preview of the next major release that’s worked on in a different branch from the current release’s servicing branch. Then it’s the usual decision for each bug fix as to whether to apply it to the current release via Updates, to the next release which would appear in CTP, or both branches. HTH
Please clarify the update thing. I get it’s a separate stream, but that leaves the update policy open. If the RTM gets a service pack released fixing bugs will the relevant changes merged over to the CTP stream creating an update of that too within some reasonable time? Or we can consider it isolated from mainstream fixes?
Congratulations! It is great to see rapid progress!
Great news, Herb.
Does operator new return memory aligned in accordance to the alignas specification? The MSDN documentation for __declspec(align()) explicitly states that it doesn’t, but __declspec(align()) is not a real language feature, unlike alignas, so I’m wondering if that restriction has changed. Thanks.
@JC_Yang: Bug fixes will go into Updates as they are available. The CTP is a separate stream.
Are there any bugfixes for the VS2013 RTM compiler included in this CTP or they will be only available in the coming VS2013 supported-updates? There’re 6 bugs I know of(I’m tracking 5 of them, 1 is reported by me which is about wrong template instantiation point).
@anon: Thanks for the pointer!
@Sometime: This is a compiler-only CTP to give a preview of new compiler features, it does not include library updates. Of course, when these features hit the full product in a future release, they’ll be complete including library support (among other library updates).
@Herb: Thats excellent news and it’s nice to see a more rapid release schedule from the C++ visual studio team.
That said will there be any library updates along with the CTP, my understanding/experience is that there are a number areas that need tending to with regards to the most recent VS2013 release.
clang has had “some” generic lambdas support for a while but since a couple of weeks it seems like really robust. They are awesome, in particular when combined with boost fusion:
auto tuple = std::make_tuple(1, 2.0, "hello!"); boost::fusion::for_each(tuple, [](auto i) { std::out << i << ", "; }); // 1, 2.0, hello! :)