Switching thread contexts with a `co_await` looks a little scary to me. Not because its new and different, but because it looks fragile. In production code that doesn't fit on a single slide, it seems dangerously easy to miss things and move some code that now executes on the wrong thread.
So, is it possible to dispatch code to another thread with a more contained scope like a lambda? Something like...
// several lines of code that *must* run on the UI thread...
Well, I doubt I will find a satisfactory way to organize my C++ code because I have to code in both .h and .cpp files. I like the way my C# code is organized with each class in a .cs file and those files are in folders organized along namespace lines.
The cpp/h files issue was my biggest gripe when moving to a project in C++ at work. I've since gotten over it, and use an extension to Visual Studio which makes it incredibly easy to work with the two files. That said, header files themselves are a great way to glean the interface of an object (granted, modern IDE's do this for Java/C# with "outline" views anyway); so they're not all bad. As @STL has alluded to, the standards body is making headway toward modules which will ideally rid most of the headaches of dealing with header files. Headers aren't great, but they're certainly not a reason enough to ignore C++, IMO.
I like being able to return Tuples from C# methods and adding extension methods.
As STL pointed out, tuples are well supported in C++(11). As for extension methods, C++ isn't locked into the OOP paradigm like C#/Java, so it has something close (albeit syntactically distinct): non-member functions.
So, you can build non-member functions that act on an object, effectively "extending" it's behavioral methods. Bjarne actually suggests preferring non-members for any function that doesn't maintain the "invariance" of an object . This is a bit of a programmer mindset issue, however, that I don't think will see a whole lot of adoption. One solution would be to borrow D's "Uniform Function Call Syntax" .
it still makes a lot of sense to me that the native language used by MSFT should be as similar to C# as possible
I disagree. C# and C++ are different languages for different purposes. If anything, it would be a better approach for MSFT to make a more concerted effort toward a native-only compilation option for C# built for WinRT.
This is an advanced topic, but not so advanced that it should be ignored. After all, this move semantics stuff is also a part of C++11.....
I completely agree. I know personally a handful of developers who are using C++11 features, yet don't fully understand rvalue references yet, and especially not the concept of "universal references". They're still taking advantage of STL's move-supported containers, they're moving unique_ptrs around, etc. So although important, the material in this video isn't required learning in order to make use of C++11 (though it most certainly wouldn't hurt).
See, I thought we simply needed a language to write efficient native code. Kind of like C with modern programming constructs like namespaces, classes, interfaces, extension methods, tuples, lambdas, collections, ... To write large apps I will use C#. For energy efficient, quick starting standalone apps give me a native language with a familiar syntax.
I think Charles may have gotten a little carried away. Watch Bjarne's presentation from Going Native 2012, "C++11 Style". He shows how strong abstractions can be built using C++11 that are clean and modern. Universal references, move semantics, etc don't generally come into play until you're ready to nitpick and really push the performance of your code. A fully conforming compiler will generate move constructor/assignment operator for you, so if your class is trivially movable, it will be. Watching this video, which in my opinion applies more to a library developer (or someone who wishes to more fully understand a library), then stating that the language is too complicated seems silly to me.
You can watch a video on how the internals of a combustion motor work, but it still takes just two (or three) pedals and a steering wheel to drive. Not everyone needs to build a motor to commute to work.