@freefly Sorry but I disagree. I really enjoyed this video and found his explanation of why using ^ instead of * was a very good one. * is reserved for real pointers (which should only be used in special circumstances in "modern" C++ 11 style coding). ^ is reserved for auto ref counted handles (or garbage collected objects in the case of C++\CLI or maybe in the future of C++\CX). Great job and thanks for this video.
As someone who started with VB, then C#, and then moved to C++, I can say the Managed Extensions and C++\CLI extensions were great at bridging the learning curve gap between C# and C++. I was really writing C++ that looked almost exactly like C# at first. Then I was able to play and learn more "unsafe" C++ features one at a time and learn the advantages and disadvantages of each in isolation while still being productive.
After getting very familiar with the amazing optimizations available in C++ it was disappointing that the CLI extensions compiled to the slower managed code. So I did my best efforts to only use CLI at the boundary but in conjunction with WPF and a MVVM pattern this option ran into performance issues with huge amounts of data and it was tedious to keep all the boundary code in sync with the real code.
That is why I am very excited to see C++\CX. Since it compiles to native code many of the performance issues will now be eliminated. I am very excited to see that as I considered that a minor drawback of C++\CLI. The reason I didn't consider it a major drawback was because in most LOB apps I've worked on the amount of data on the screen at once is not a lot but it really affected scientific data visualization. The Boundary layer was slow for huge amounts of data unless extreme optimizations were done that really obscured the code and took much time. The other part of C++\CLI and still C++\CX I still consider a minor drawback is the lack of a built convention based model like the Entity Framework code first approach.
EF uses certain "strategies" to map object concepts to DB table "resources", using a similar approach I created T4 templates that used the C++ ISO standard API as the code first for auto generating the wrapper non ISO C++\CLI classes. This did require that I map basically the "resource" allocation "strategies" (implicit ownership rules) of the existing ISO API so the T4 templates could be generated off convention and this declarative "resource" strategy mapping. I'm sure this is a naïve approach and would not work in all situation's but I've hacked together several T4s that basically describe the implicit "strategies" behind a few specific open source C++ projects so I would not have to keep the boundary layer in sync by hand. So when the ISO API changes so does the C++\CLI Boundary layer automatically. I took this approach specifically in a molecular biology software project that ran both on the Mac and Windows and used several cross platform C++ open source APIs for the back end while having a WPF front end on Windows and a Cocoa front end on the Mac.
Overall I am very excited to see C++\CX and I think it will be warmly welcomed for the design goals it was intended to serve. It would be nice to see some additional features that built upon C++\CX like the EF\T4 "resource" strategy mapping approach. My templates are really hacked together but their do seem to be common strategies among C\C++ API open source projects that allow for code generation based off some common generic strategies. I'm sure a more seasoned C++ could speak more on this subject. Anyways thanks for all the hard work, VS11 is very exciting to me.
So I'm sure Anders considered having the default for async calls be await without having to type the await keyword allowing for a smaller more concise format. I know this would not work for backwards compatibility but it could be turned on with a project setting or something of the sort. Then there would be a new keyword to use if you don't want to await. I have spent only 2 second thinking of this so I'm sure there are all sorts of reason why this is a bad idea that I have not thought of yet but could so you speak on some of the decisions around the await keyword. Thanks.