CppCast - C++/WinRT

Episode Date: October 12, 2016

Rob and Jason are joined by Kenny Kerr from Microsoft to discuss the C++/WinRT library, previously known as ModernCpp, a standard C++ projection for the Windows Runtime. Kenny Kerr is an engineer on the Windows team at Microsoft, an MSDN Magazine contributing editor, Pluralsight author, and creator of moderncpp.com (C++/WinRT). He writes at kennykerr.ca and you can find him on Twitter at @kennykerr. News VOTE! Support debugging of C++ code with IntelliTrace All CppCon 2016 Videos Are Up! Visual Studio "15" Preview 5 Now Available Compiler Tools Layout in Visual Studio "15" C++ 14/17 Features and STL Fixes in VS "15" Preview 5 Bring your C++ codebase to Visual Studio with "Open Folder" C++ compiler diagnostics improvements in VS "15" Preview 5 C++ IntelliSense Improvements - Predictive IntelliSense & Filtering CMake support in Visual Studio Visual C++ Compiler Version Faster C++ solution load with VS "15" C++ Core Check code analysis is included with VS "15" Kenny Kerr @kennykerr Kenny Kerr's Blog Links C++/WinRT Available on GitHub cppwinrt repository on GitHub CppCon 2016: Kenny Kerr & James McNellis "Embracing Standard C++ for the Windows Runtime" CppCon 2016: Kenny Kerr & James McNellis "Putting Coroutines to Work with the Windows Runtime" Sponsor Backtrace

This episode of CppCast is sponsored by Backtrace, the turnkey debugging platform that helps you spend less time debugging and more time building. Get to the root cause quickly with detailed information at your fingertips. Start your free trial at backtrace.io.cppcast. And by Meeting C++, the leading European C++ event for everyone in the programming community. Meeting C++ offers five tracks with seven sessions and two great keynotes. This year, the conference is on the 18th and 19th of November in Berlin. Episode 74 of CppCast with guest Kenny Kerr, recorded October 12th, 2016. In this episode, we discuss several C++ features in the new VS 15 release preview.

Then we talk to Kenny Kerr from the Microsoft Windows team. Kenny tells us about the C++ WinRT projection for C++ developers by C++ developers. I'm your host, Rob Irving, joined by my co-host, Jason Turner. Jason, how are you doing today? Good, Rob. How about you? I'm doing pretty good. We did have a big storm here over the weekend, but I didn't really get too affected by it. Lost some power at the office, but the house was fine.

My parents and a lot of my family are actually right on the coast of Florida, right where the hurricane was projected to make landfall. But it fortunately did not actually make landfall, so everyone's house is fine as far as I can tell. I'm in you know central north carolina so most of central north carolina was fine unless you're close to a river in which case they got a decent amount of flooding but i wound up being okay okay so at the top of every episode i'd like to read a piece of feedback uh this week i got an email from chris and he wrote, your readers might be interested in this item. Microsoft is investigating the possibility of adding IntelliTrace debugging support for C++, which is currently implemented for C Sharp, VB, and F Sharp. IntelliTrace is

historical debugging, which allows you to gather debugging data over time and rewind or fast forwards these points in time. And he points to a survey to fill out if anyone's interested in getting this functionality for Visual C++. So I'm going to put this link in the show notes. It's a link to UserVoice, which is a website that Microsoft and other companies can use to gather feedback from their users. And you can actually just upvote this issue to market as something you're interested in, in being added to the product.

So I'm going to see, maybe we can get some social engineering going on here, Jason, and encourage everyone to go vote for this and get IntelliTrace added for, for C++. You know, it's, it's potentially extremely significant because this is basically reverse debugging, if I understand correctly.

It looks, as far as I can tell, is the same type of functionality you get from RR or UndoDB. Except in Visual Studio. Except in Visual Studio, yeah. So yeah, I'll put that link in the show notes. I definitely encourage everyone to go vote it up. I think at the time, right now it's at 406 votes, so let's see how high we can get that up. Well, I need to vote also then.

Yeah. And we'd love to hear your thoughts about the show as well. You can always reach out to us on Facebook, Twitter, or email. You can email us at feedback at cppcast.com, and don't forget to leave us reviews on iTunes as well. Joining us today again is Kenny Kerr. Kenny is an engineer on the Windows team at Microsoft, an MSDN magazine contributing editor,

Pluralsight author, and creator of ModernCPP.com, which is now C++ WinRT. He writes at KennyKerr.ca, and you can find him on Twitter at Kenny Kerr. Kenny, welcome to the show. Thanks for having me back, guys. It was a good episode last time. Glad to have you again. Yeah, and it was great meeting you in person over in Washington. That's right.

Yeah, it's good to finally see you both. I was quite envious of all the cool talks you guys gave, especially the Commodore stuff. That was very neat. Thanks. I'm glad you liked it. That was a great talk. So we're going to have a couple news items to run through, Kenny. Feel free to jump in

on any of these. We're definitely going to want your feedback on some of them. And then we'll start talking about C++ and WinRT. Sounds good? Okay. So the first one, speaking of CppCon, is that all CppCon 2016 videos are now available. So this

is pretty impressive, right right jason they got everything up in only two weeks yeah 111 presentations 31 lightning talks there's a bunch of fun stats on the cpp con article 40 what 36 terabytes of storage yeah i think it's about 150 hours of video yeah it's very impressive and right now it's all up on YouTube, and it says that they're mailing over hard drives to Channel 9 so they can get it all posted there as well. You know, I've heard this quote

before. It's something like, never underestimate the bandwidth of a minivan filled with hard drives, basically. It's amazing that in this day and age, it's still faster to just mail the hard drives than it is to upload it. Yeah. Wow.

Okay, so next up, Visual Studio 15 Preview 5 is now available. And as Microsoft seems to do when they release a new update is they post about a dozen or so blog entries covering some of the new features. So I think we have 10 articles here. We're hoping we could run through some of these with you, Kenny. Is that okay? Sure, sounds good. Okay, so the first one is just kind of an overview of some of the different topics we're going to talk about.

But the preview is now available, and you can get a link in here to go download the installer for Visual Studio 15. The next thing we wanted to highlight is compiler tools layout being changed in Visual Studio 15. And I guess this is going to be very important to anyone who works on automated build systems, automated build scripts, because the path to the compiler binaries may have changed for you, right? Yeah, I don't think it'll affect me personally, even though I do do automated build things and do worry about these in some cases. Because if, I don't know, if you're smart and use CMake or something

to find the executable for you, maybe it won't be a problem. Yeah, hopefully just CMake will update and take care of that for you. Yeah, most of the environments will just do it automatically. And Visual Studio ships with build setup scripts that you use those. It'll just work. Okay. Yeah, so it's really if you just had some custom stuff going on that you might need to worry about these, I guess. So in other words, the CMake team needs to be worried about this. Yeah.

And they do go into some of the reasons why they're making this change. Basically, being able to roll out new versions of VC++ and including all these different compilers, like being able to compile for Android or iOS now, just means there's a lot more targets, and the old layout just wasn't working for all that. Right. Yeah, so I'm not on the Visual C++ team, so take this with a pinch of salt,

but historically I've just found that Visual Studio has gotten more and more complicated. So anything they can do to try and simplify the whole package is good news for me. Absolutely. Okay, this next one is an update from STL about the C++ 14 and 17 features and STL fixes in VS 15. And there's not too much there.

I guess the one big one is Extended Constexpr. Right, Jason? Well, there's also uh they're jumping ahead of some of the other compilers with optional and variant from c++17 yeah but yeah it looks like their constexpr support's getting better for sure and they're also saying that although it's not in this preview build, the release candidate should have support for C++ 17's any string view apply and make from tuple. Right. I think there's a video on make from tuple or a video mentioning it from the conference. I'm not sure. I think Estiel may have done a video on that, right? I think he did, but then I was wondering if I got something confused.

Is there anything you wanted to call out in this one, Kenny? Well, the constexpr stuff is interesting for me because certainly it's catch-up in terms of Clang support. It's been there for a while. But the work that I'm involved with constexpr

is a very big deal. And we have a very important feature that this enables for us. So I'm excited to see that finally coming to Visual C++. The library stuff is great. I think they're a lot further ahead in that space. So it's just good to see that they keep banging away at it. Yeah, they seem to be doing a great job of moving forward on the library stuff. But yeah, constexpr if

is is not in the preview i just noticed that unfortunately yeah okay uh next one is uh bring your c++ code base to visual studio with open folder so basically this is allowing you to use visual studio without having visual Studio project and solution files. Being able to just open up in your source code repository and be able to work without creating Visual Studio solutions. And I guess this kind of goes with another feature that they're going to be adding, which is CMake support, right? Yeah, that's one coming up, but I want to make a quick comment on this because this has basically been my main argument

for not using Visual Studio. I mean, I do use Visual Studio and I do encourage people to use the correct compiler for the right platform, but for the past 20 years, if you just wanted to test a little snippet of code to see what the compiler would do with it, in Linux or in mac os you can use gcc from the command line do it in 10 seconds right with visual studio you had to create a project you had to see what kind of project it was you had to add a file

to it you had to write you know do your thing do the build if we can now easily open a folder that could be huge yeah so i think that's where they're going right now. I don't think they build within Visual Studio yet, but that's certainly the direction they're going, and it's exciting to see, because not everyone likes to fuss around with MS Build and all the project settings. Particularly if you just want to know

what a copy constructor is doing or something. That's right. Yeah, that is the one caveat you just mentioned, Kenny, is that you can't currently build from just opening a folder, although you can debug, which I think is a bit odd, that you would have to go over to the

command line to build, but you could still use the Visual Studio debugger. Yeah. But hopefully being able to build might come by the actual release. Right. We can only imagine that that's part of the plan.

Yeah, I don't think it says in here whether or not it's going to be there, but we can hope. Fingers crossed. Yeah. Fingers crossed. Okay. The next one is C++ compiler diagnostic improvements in VS 15 preview. And the main thing here is that you can now in addition to getting the line number of an error you can get the column

and this is one of those things that i was surprised wasn't already there uh i guess just yeah client has had it for so long i'm gonna have to change some uh error parsing code that i have. Yeah, and they do actually point that out, that they're going to keep not having the column as the default setting for anyone who's doing something like error parsing on the error strings.

But there will be an option to get the column number or to get a line with a caret pointing you to exactly where the error is, which is nice. Yeah. Okay, next one, C++ IntelliSense improvements. So what are they changing here?

Oh, it's basically IntelliSense should be getting smarter based on what it thinks you're trying to bring up with IntelliSense. Is that right? I don't know. I missed this one. I think it's giving you more contextual information, so rather than just dumping every conceivable option, they give you stuff that's probably going to be more relevant first. Right.

It looks like they're also adding UI so that if you want to narrow down the results to just methods or just namespaces or pure functions or something like that, you can easily narrow that down. Sounds good. Yeah. Okay. Next one we already mentioned is CMake support coming to Visual Studio. Now, the interesting thing here is that they're putting this article out with all these other VS 15 updates,

but I don't think you can actually go and test this yet in the vs 15 preview um i think it's it looks like it's going to make it to the final release but as of now they're just pointing you to a video from cpp con where they they showed a demo of this in action but i guess it's just not quite ready to uh to release even in the preview it can only only be a good thing, I think, once it does get there. Absolutely. I have successfully used CMake with Visual Studio for seven years, but sometimes CMake goes to update the project and Visual Studio gets confused or vice versa,

and then you have to shut down Visual Studio, whatever. Nice to see it come into official support. Yeah, and one thing else. Go ahead, Kenny. Sorry, I was just going to say, I think the idea is that this would replace MSBuild. So if you don't want to use MSBuild, you do CMake. It's not a round-trip thing

where it actually generates an MSBuild from CMake or vice versa. I get that impression. So it's effectively native support for CMake. It's not just a wrapper around MSBuild or the other way around, which I think is the right way to go here. Wow. Yeah, that's cool. They also call out here that this was at least somewhat inspired or based on the CMake server prototype, which we talked about with Stephen Kelly a couple months ago.

Right. That's cool. That's nice that they're working directly with the CMake team. They also mentioned here how the Visual C++ team has been contributing to CMake in order to improve their generation of Visual Studio C++ projects. It's always great to see Microsoft working directly with the open source communities. It is, yeah. Okay, next one.

Not too much going on here. Some of Visual C++ compiler versions. The MSC ver pound define that you might want to check for when using a specific C++ feature. What exactly are they changing here? I think it's just more granular versions. So you can do more granular checking of what capabilities are available

within your library. Right, so if you know that extended constexpr support was just added with this preview release, you can specifically with this preview release, you can specifically target this preview release, I guess, right? Right. Okay. Next one,

faster C++ solution load of VS 15. Just as the title suggests, it looks like they've been dramatically increasing performance of a C++ solution's load time. With the first load, you're getting about

half the amount of time taken to load the solution. And with subsequent loads of a solution, it should be significantly, significantly faster, like a 10x improvement, it looks like. Is this a feature you have to enable also that's not enabled? I thought

I saw that somewhere. Maybe not. But I did notice when this was first announced in the preview that there were comments on Twitter or Reddit or somewhere where people were saying, yes, it's a huge performance improvement for large projects. Yeah. And one thing that they point out is they have this graph here where they're showing what exactly is taking time during a solution load. And it looks like it's the parsing and resolving includes.

Actually, it's taking a bit longer now, but the performance improvements in all the other areas was so significant that you're still getting about a double improvement but they they're going to be working on improving the parsing resolving includes to uh get it even faster for the final release so this chart says loading chromium in visual studio which has 4600 projects used to take 1300 seconds to load yeah that. That's a long time. That is a long time. Yeah. Yeah. And even your,

your sub, your subsequent loads would take almost 800 seconds, which is about 12 minutes, right? 13 minutes. And now that's down to two minutes. So it's a pretty significant improvement. Yes,

it is. Okay. And the last one, the C++ core check code analysis is now included with VS 15. We've talked about this before, obviously, the C++ core guidelines. Previously, you had to go and fetch a package from NuGet in order to use the C++ core guidelines. And going forward with VS 15, it's just going to be included and you can just use it straight out of the box in VS 15, which is great because I'm sure there are a lot of people who maybe haven't even heard about the core guidelines

or don't know they need to go and get it from NuGet and now they'll be able to just discover it within Visual Studio. I'm always a fan of making the tools easier to access. Yeah, absolutely. I thought it was available on GitHub as well. I don't know if that's still the case, but it used to be. That's where the actual guidelines code is, right? But not Microsoft's implementation.

That could be wrong. I know that the recommended method was to use NuGet to install it. Okay. Well, Kenny, we had you on before, about a year and a half ago, I think, actually, talking about the modern C++ library. And since then, as we already mentioned, you have joined Microsoft. Do you want to tell us a little bit about the transition there? Yeah. So a lot of folks know me from my plural site courses and my articles in Amnesty and Magazine, where I focused on C++ for Windows, and most of that was based on Win32. And that was a lot of fun to teach because, well, you could

laugh at some of the craziness, but it was a powerful API, and I enjoyed teaching developers how to make the most of it. But then came WinRT or the Windows Runtime as the successor to Win32. And while Microsoft had done a great job of integrating the Windows Runtime into C Sharp and the CLR, there was nothing for the standard C++ developer who wasn't satisfied with the non-standard CX extensions. And it turns out that many developers weren't satisfied. So what I had come up with for Modern C++ resonated with a lot of developers both in and outside of Microsoft so I had a choice to make

continue to bang away at it in my spare time or join Microsoft to finish the job with their help and support and that's what I did and now I work on the team that actually owns the Windows runtime COM and all the rest actually next week will be my one year anniversary at Microsoft

and it's been a very busy year pushing modern C++ and the Windows runtime as far as we possibly can. A lot of engineering has gone into the project over the last year, not only because of the work my team has done, but also thanks in large part to a great effort by the Visual C++ team in supporting the project. This library has really pushed the limits of the compiler in many ways, and they've stepped up to fix and improve it. So the compiler team is clearly very passionate about standard C++, and with a renewed focus on ISO C++, as we've talked about, we have a shared interest in improving the C++ compiler.

So I'm curious, did they reach out to you to come on and start doing this full-time, or did you reach towards them? Well, what happened was that I just started talking about it online. So I got the moderncpp.com domain. I put some videos up with some tutorials and examples. And a friend of mine on the graphics team started showing that around to some folks inside of Microsoft, and then they invited me to come out to Redmond to give them some demos and talk with them. And those discussions led eventually to an offer to join the team. Oh, that's cool. Yeah.

Yeah. So for listeners who maybe didn't listen to the previous episode or haven't heard of C++ and WinRT, do you want to give us an overview of what it is? Sure. So the modern C++ project is now called C++ WinRT. And as I mentioned, it is a Windows runtime language projection for any standard C++ compiler. So even though the Windows runtime is based on COM, it wasn't designed to be used directly as you might a COM API. Rather, a developer would use what we call a language projection, which is a way to project the Windows runtime into your favorite language. The Windows runtime is the technology

behind the modern Windows API called the Universal Windows Platform. And that just means that the same API can be used across all Windows devices. So whether it's Xbox, phone, tablets, HoloLens, PCs, or anything else that runs Windows, perhaps an embedded microcontroller. C++ 1RT, then, is a header-only library that allows you to both author and consume Windows runtime APIs using any standards-compliant C++ compiler. It projects a classy type system into C++ that faithfully captures the intent of the API designer. It's the language projection for the systems programmer,

but it gives you the productivity rivaling that of C Sharp without compromising performance or the control and power that the C++ developer is accustomed to having. But at the end of the day, it's just a header-only standard C++ library that you can hash include into your project. That's all there is to it. So this has become an officially supported method of using the Windows

runtime from C++ and from Microsoft's perspective? That's right. So we're not yet feature complete, but that's the intent. We will be supporting this going forward as well. So I guess if our listeners wanted to try using modern CBP

library today, how would they go about doing that yeah we're actually releasing a public preview this week so you'll be able to go to github microsoft's github account and download it there'll be a link on modern cpp.com for where exactly that is but it'll be available on github for you to begin trying and playing around with. On that note, when you're creating a Visual Studio project for targeting the UWP, creating a UWP app or

library, I think C++ CX is probably a project template for you. Is there going to be a project template for C++ WinRT? Is that going to be built into Visual Studio by any chance? Yes, that's the plan. Eventually, it'll be

on par. It'll all be just baked into Visual Studio. But the focus over the last year or two has really been on the base library, the essential abstractions, the compile-time abstractions that make it all possible. But for mainstream app developers, they typically want things like XAML designer support,

where Visual Studio generates markup and bindings and generates code and so on. And that requires integration with the XAML compiler. And it's something we're still working on. But yes, the goal is to support Windows app development in such a way that it's every bit as convenient and comprehensive as C Sharp and CX is today. That'd be nice.

Yeah. So we talked a little bit about how C++ and WinRT is definitely preferable over C++CX as it's just standard C++. Aside from the syntax, though, are there any advantages to using

C++ and WinRT over C++CX? Yeah, so to be sure, the CX syntax is not natural. It doesn't feel like modern C++. But more than that, performance isn't great. Interop is a pain, and it certainly doesn't work well with standard types like std strings or stl containers. Now, if it had been perfect, it might not have been so bad, but it certainly isn't. And without any visibility into the abstractions, without any control over memory management, exception handling, and so on.

It makes it very difficult. It just provides a very hard experience, especially for the C++ developers who are accustomed to being in control. This is supposed to be the system's programming language, and we just don't have that control over our own code. Now, C++ 1.0.t gives you better performance, in some cases dramatically better performance, and we give you control over things like memory management and exception error handling,

things that are critical to many developers that expect to be able to get the most out of their C++ projects. It feels and behaves like a standard C++ library because that's what it is. You can use your favorite C++ compiler, crank up all the optimizations it may offer for standard C++, and performance only improves. But more than that, the Visual C++ compiler team is committed to improving standard C++ support. So we hear a lot about the new conformance work, but that's mostly front-end stuff. And so behind the scenes, they've been doing some incredible back-end work for optimizing code, and the focus has shifted to optimizing modern C++ idioms and coding patterns.

And this also pushes C++ WinRT beyond CX even more because the library is designed to maximize the benefit from those optimizations. So it's very complementary. That's interesting to me that you just pointed out that the compiler team has been working on optimizing modern C++ standards and idioms. Just out of curiosity, do you have any examples as to what that would look like to our listeners? What kinds of things are being more better optimized, if you will? Well, a simple example is a function that returns a type with a non-trivial destructor. So today the C++ compiler will not inline that function. It just cannot. And that seems like a very trivial thing, but if you have a library that has thousands of

very small functions that return types with non-trivial destructors, you end up with code that is very non-inlined. And that ends up impacting performance dramatically. So little things like that, just helping library developers not have to design their libraries to work around the lack of optimizations in the compiler is a great boon for us library developers because we can design our libraries the way we'd want them to be designed and used rather than based on the limitations of the compiler. So, for example, something as simple as a unique pointer today, it wouldn't be able to be inlined

because it has a non-trivial destructor, but that's something that they are working on. That's right. That's right. So if you had a function that returns a stood unique pointer, that function would not be inlined. And there are a number of other examples around exception handling as well. But, yeah, all of those scenarios are a major focus now for the backend team. Interesting. Yeah. And I'm always interested to see all those code snippets you put on Twitter where you're comparing the code gen for things like what Clang might do with a unique pointer.

That's, you know, the heap elision example I think you had recently. Yeah, that one, yeah. That's always fun to see. So, yeah, it's good to see the back-end guys think about that a lot more now. I guess to fill in our listeners, it is possible on Clang with optimizations turned on that even dynamic memory allocations might be optimized away by the compiler. Yeah. Yeah, so the compiler. Yeah.

Yeah, so the compiler guys call that heap elision, and you'll hear Gore Nishinov talk a lot about that as well. He's able to do that for coroutines, which is pretty fantastic. Cool. I wanted to interrupt this discussion for just a moment to bring you a word from our sponsors. Backtrace is a debugging platform that improves software quality, reliability, and support by bringing deep introspection and automation

throughout the software error lifecycle. Spend less time debugging and reduce your mean time to resolution by using the first and only platform to combine symbolic debugging, error aggregation, and state analysis. At the time of error, Backtrace jumps into action, capturing detailed dumps of application and environmental state. Backtrace then performs automated analysis on process memory and executable code to classify errors and highlight important signals such as heap corruption, malware, and much more.

This data is aggregated and archived in a centralized object store, providing your team a single system to investigate errors across your environments. Join industry leaders like Fastly, Message Systems, and AppNexus that use Backtrace to modernize their debugging infrastructure. It's free to try, minutes to set up, fully featured with no commitment necessary. Check them out at backtrace.io.cppcast. So going back to C++ WinRT for a minute, I do have some experience with C++ CX,

and one question I had is I think the guidelines with C++ WinRT for a minute. I do have some experience with C++ CX, and one question I had is, I think the guidelines with C++ CX were kind of to minimize the amount of C++ CX you're using, like keep it to just the boundaries, and then switch over to standard C++. So if you were having a library that took a string, you would have to convert it from the C++ CX string to a standard string,

and then go ahead and do something with it. Is that going to be much different with C++ WinRT? Yes. So the idea that you would use C++ CX just on the boundary was never really a practical or reasonable suggestion. And so it would basically infest your whole project. But the problem was that because the types were so fundamentally different and there wasn't a good interrupt story, you ended up with a lot of, you know, conversion or interrupt code all over your application.

So what C++10T does is it attempts to provide a very natural experience using, you know, STL standard types with a projection. So if you have an API that expects a collection of strings, and that'll be a COM interface, and it'll be an I vector of eight strings, for example, you can naturally pass that astute vector of strings, and it works just fine. If you have an API that returns a string across the ABI,

you can just assign that to astuted-wide string and it just works. You don't have to inject a bunch of extra code to do conversions and so on. So you get a very natural and succinct programming model because you can use the familiar natural types that you're accustomed to using and we make sure that you get the best possible performance. That's fantastic. That is. And it plays nicely with Unicode and such. I mean, that's kind of a sticking point in C++ in general is how to deal with Unicode.

But if you're automatically inverting the wide character strings... Yeah, so Windows has historically been Unicode, you know, 16-bit Unicode. And so WinRT continues to go down that route. So we don't change anything about that other than everything is Unicode. And so WinRT continues to go down that route. So we don't change anything about that other than everything is Unicode. And you can use std-wide strings naturally wherever a string is required.

Now, the Windows runtime has its own string type, and it's an immutable reference-counted string type called an HString. And so what we don't do is we don't automatically convert every h-string into a std-wide string. But we give you an h-string which acts and feels like a std-string, and then we provide a natural conversion to standard strings, so you get a very natural and seamless programming model. But we avoid the conversion whenever possible so that you don't have to do that extra allocation. So I've got to ask, because I've never actually used U16 string, which was added in C++11,

and it's a 16-bit wide character string. So why the choice between stdw string versus U16 string, or do you support both? Everything is prototyped with stdwwide string just because that's the historical type. WHR is the historical type that Windows has used and also WinRT uses as well. So nothing has really changed there. Windows, this is one of the really difficult

things for C++ developers and I don't know that we have a, as a community we don't necessarily have a good answer for. On Windows it's always traditionally been WHR. And on Unix, I think it's, you know, UTF-8 char strings as the sort of predominant thing that most people use for Unicode. And, you know, so writing a library

that works cross-platform is always difficult because, you know, which one do you use and how do you sort of deal with that transparently without injecting a bunch of conversion code in one or other platform. So that's a challenge. And that's not something we're trying to address here specifically. Sure.

So you're a part of the Windows team. Is C++ WinRT being used much internally at Microsoft? Yes, a number of teams have started to work on projects that rely on C++102 to varying degrees, often incorporating it into existing code bases where they might be existing in WRAL or CX code. We have a good interop story, so that helps. But as we flesh out some of the outstanding features,

such as the XAML designer support in particular, we should see greater adoption. But yes, there are developers actively using it already, and we have been doing so for some time. And it's been great to get that feedback early on as we work on it, but I'm very excited to have the public preview this week because now I can get some feedback from the C++ community. And that'll be, I hope, to be a great source of feedback for us,

and I'm very excited to see what developers come up with. I can see our listeners being interested in trying it. Yeah. Yeah, please do. So C++ CLI, just changing topics a little bit, might still see a lot more use, I'd imagine, than C++ CX or WRL. Do you know if there's any possible way

that something like C++ WinRT could be made to replace or offer an alternative to C++ CLI? Well, I think it's certainly possible, but there are no plans to do so. So C Sharp is really the most natural way to talk to.NET. And I don't love C++ CLI, but I have no plans to extend this concept to cover managed code. And the reason C++ WinRT works so well is because it's COM under the hood, and COM and C++ really play well together. If you want to mix native and managed code, I suggest you look at C++ WinRT, because it provides a very simple way to expose native code in a way that C Sharp can easily consume

it, thanks to the CLR support for the Windows runtime. So a lot of people use C++ CLI because they have native code and they want to make it accessible to C Sharp. WinRT does that, but it does it better. It provides a better abstraction for doing so, and it gives you better performance. If you need to run on older Windows platforms, that wouldn't be an option, right? That's right. This is Windows 8 and up.

Yeah. Yeah. Well, at this point, Windows 8's an old platform, right? I'd say so, yeah. I work on a project that still has Target Windows 7, so I know it wouldn't be an option for me. I actually have one box

still running Windows 7 in the house. I like Windows 7. What frustrates me a little bit is the Visual C++ team, they still support Windows 7 in the house. I like Windows 7. What frustrates me a little bit is the Visual C++ team, they still support Windows XP. Really? Yeah, which means they have to make various trade-offs in terms of what they can use and can't use inside of the

standard libraries, which is a bit of a drag. That's surprising. I'm sorry. I mean, XP's been deprecated for over a year now, right? Yeah, Windows doesn't support it, but C++ still does. It was maybe two years ago I had to deal with making sure I could still support XP with a project I was working on. And it was, I think, I'd been end of life once already and then extended or something at that point. Okay. Yeah, it's been a few years since I've even looked at it.

Yeah. ended or something at that point. Okay. Yeah, it's been a few years since I've even looked at it. So you did this C++ WinRT talk at CppCon with James McNellis, and then the two of you kind of did a follow-up talk where you went into using coroutines for the Windows runtime. Do you want to tell us a little bit about that? Yes. So our coroutine talks

explored what we've done to support the Windows runtime's deep investment in async or concurrency in such a way that it's natural to the modern C++ developer. Frankly, concurrency in C++ is hard. From thread pools, callbacks, and stack ripping to newer ideas like tasks or futures and continuations, it's not fun. At least I don't find it fun at all. So Gore, James, and I gave these three talks at CppCon on coroutines, and that final talk was all about how we integrated coroutines into C++ WinRT. At the heart of the coroutine feature is this idea of a coroutine type,

so the return type of the coroutine. You need some type that provides a coroutine trait specialization through which the compiler can find the promised type to allocate as part of the coroutine frame. Now that sounds hard, and it is, but that's what the C++ WinRT library does for you, and using it is very simple. Typically that coroutine type is astute future, but that turns out to be less than ideal. So we showed how we built coroutine types out of the pre-existing WinRT async interfaces. So you can simply use any of the four async interfaces as the return type of your coroutine. So that's a coroutine that's actually a com object with all of the overhead that implies.

But despite all of that, we were able to optimize the implementation to the point where it outperformed std future by a huge margin. Now, of course, std future is going to get better eventually. But combined with WinRT, you get a portable coroutine type that you can even pass to other languages. Perhaps you're writing an OS component that wants to provide results asynchronously to an app written in C Sharp. You can now do that very simply and efficiently with standard C++.

Or what will be standard C++, I hope. So it was a great example of what you can do with C++ coroutines, you know, going beyond Hello World. And this is a library that you can use to write seriously scalable code. It integrates with the Windows Threadpool in a very seamless way, and in many ways illustrates that C++ is ready for coroutines. And this is also what we're planning to use in the operating system itself. So we're pretty serious about this. I was just going to ask that. So even though coroutines aren't finalized,

you guys are pretty seriously starting to think about them and get invested in them at Microsoft. Yes, yes, we are. Yeah, so the C++ team has been careful not to pick up features that have not been standardized. But in some areas, they still want to try and innovate and push the standard forward. But everything is about

standards adoption. As the standards committee decides it needs to be tweaked one way or the other, we will follow the course even though we're doing a lot of the pioneering here. This work you're talking about with coroutines, it's going to be part of the C++ 1RT release later this week?

That's right. That's right. Awesome. Yes, it's all built in. So you don't have to worry about all the grungy implementation. But because it's just a header-only library, you can certainly have a look and see how it all works. And so it provides a good reference implementation

if you want to see how to do some, you know, very serious optimizations around coroutines. So Clang CodeGen is becoming a first-class citizen in Visual Studio, and one of Gore's talks was about Clang coroutines, I believe. So does that mean with WinRT, can we use the Clang coroutines WinRT toolchain? Is that possible? Eventually, yes. Eventually, possible? Eventually, yes. Eventually, okay. Eventually, yes.

So the Coroutine work, I believe, I'm not too expert on this, but I believe is part of the Clang backend. So it's about how they do the cogen. And what we have in Visual Studio today is the Clang frontend. So you can replace the Visual C++ front end with a Clang front end and use the same Visual C++ back end today. Okay, I got you. But eventually what we'll have is the ability to also target the Clang back end

and get the Clang's coroutine facilities powering this whole thing in the background. It's pretty amazing. Yeah, it is. It's really fun to watch them. It's very exciting. Of course, having a lot of fun with this. I'm sure. Jason, do you have any other questions? No, but just a quick comment that you should go and watch Kenny's video

on embracing standard C++ for the Windows runtime. It is a very compelling story for why this project was needed. Thank you. Yeah, the code examples you go through with C++ CX and also with its WRL, right? Yes. Were pretty good examples of why this was needed. Yeah, no, it really helps.

That's really why I started all this. I wanted to make it fun again, to write software for Windows with C++ and it was getting increasingly unfun. And so this is why I started this journey and I really think it does make it a lot better. Okay, well thank you so much for your time today, Kenny. I really think it does make it a lot better. Yeah. Okay. Well, thank you so much for your time today, Kenny.

And once the library goes live, definitely let us know so we can include it in the show notes. Yeah. So just visit moderncpp.com and you'll be able to get the link to download that. Thanks for having me, guys. Thanks. Thanks for coming on. Thanks so much for listening in as we chat about C++. I'd love to hear what you think of the podcast.

Please let me know if we're discussing the stuff you're interested in. Or if you have a suggestion for a topic, I'd love to hear about that too. You can email all your thoughts to feedback at cppcast.com. I'd also appreciate if you like CppCast on Facebook and follow CppCast on Twitter. You can also follow me at Rob W. Irving and Jason at Leftkiss on Twitter. And of course, you can find all that info and the show notes on the podcast website at cppcast.com. Theme music for this episode is provided by podcastthemes.com.