CppCast - Build 2017

Episode Date: May 12, 2017

Rob travels to the Microsoft Build Developer's Conference to interview Kenny Kerr from the Windows team and Marian Luparu from the Visual Studio C++ team. 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. Marian Luparu is currently leading the team responsible for making Visual Studio more productive for C++ developers. News Better C++/Chicago Kenny Kerr @kennykerr Marian Luparu @mluparu Links Microsoft Build (Channel 9 Recordings) C++ at Microsoft Build 2017 Channel 9 C++ Panel Interview (STL, Kenny Kerr, Marian Luparu, Gaby dos Reis) C++/WinRT Available on GitHub 7++ reasons to move your C++ code to Visual Studio 2017 Sponsors Backtrace Hosts @robwirving @lefticus

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 slash cppcast. CppCast is also sponsored by Pacific++, the first major C++ conference in the Pacific region, providing great talks and opportunities for networking. Get your ticket now during early bird registration until June 1st. Episode 101 of CPP Cast with guests Kenny Kerr and Marion Luperu. In this episode, I travel to the Microsoft Build Developers Conference. First, I talk to Kenny Kerr about his ongoing work on C++ WinRT. Then I interview Marian Looper about new Visual Studio announcements for C++ developers.

Welcome to episode 101 of CppCast, the only podcast 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? Doing pretty good, Rob. I just scheduled my second training class, which is interesting. So when's that going to be? That is July 12th through the 14th in chicago so there will be three days three different topics c++ best practices understanding object lifetime and demystifying modern c++ i think it'll be fun yeah i'll put a link into the show notes for that

great thanks cool so i just got back from the Microsoft Build Conference. So what is the Build Conference about? Yeah, it's definitely not like a C++-focused conference. There were a couple sessions that covered C++, but it's mostly a Windows app developer and Azure developer conference. Okay. So if you're doing either of those things there's there's a lot of content aimed at you um and if you look at the keynotes they split it up where the day one keynote is mostly azure related stuff and the day two keynote was mostly windows

development related stuff so it was two days then it was a three-day conference they don't do a keynote on the third day okay but yeah i had a good time i got a chance to talk to kenny kerr in person and i also talked to marion lupru who we have not had on the show before but he is on the visual c++ team work work on Visual Studio for C++. Okay, so is he, do they compile it or front-end or? You know, he's a program manager, but I think he does a little bit of both.

Okay. But Visual Studio related, not, you know, back-end C++ stuff. Okay. Yeah. Sounds interesting. Yeah, so I got a chance to talk to both of them. So since we, you know,

I was away doing the conference and we didn't get to talk you know to a guest ourselves i thought we would put those two interviews together and do kind of a build recap episode okay yeah and we'll be gone again next week is that right yeah because you'll be at c++ now but then we already have some interview schedules for once you get back. Okay, sounds great. Okay. Okay, welcome to CppCast. We are at the Microsoft Developers Conference, Build 2017. And today I'm being joined by Kenny Kerr, two-time

guest of the show and friend of the show. Kenny, it's good to have you on. Thanks, Rob. It's great to be back. So Build's not necessarily a big C++ event. Keynote this morning, they mentioned C++ a couple times, but it's still great to have you on. It's great to be here, and you've been working on some stuff that we can talk about today over the past few months

since we last had you on talking about C++ WinRT, right? Yeah, we keep making progress. There's lots to do, but it's exciting to see it come together. And, you know, it isn't the C++ Windows conference it used to be. Sure. But Windows and C++ is still a big deal for Microsoft. Oh, yeah. And we're excited to make it a lot more accessible

and approachable to the C++ developer out there. Yeah. Just to go a little bit into the keynote this morning, I know you said you didn't make it to the keynote, but there were a couple interesting announcements for any developer, whether you're a C++ or.NET developer. They're now going to have multiple versions of Linux available on Windows, which is pretty cool.

Yeah, that's quite a change. Yeah, so the original release was Ubuntu, I believe. And then they added two more, right? They added OpenSUSE and Fedora. Shells are now available, which is pretty cool. Yeah, I don't know too much about Linux, but I imagine if you do, that's a big deal. Yeah, absolutely. And being able to build two Linux all in one box without having to have a virtual machine or a separate machine that you're SSHing. I speak to a lot of C++

developers who are increasingly saying I'm just going to use Windows to do my cross-platform development. It's just so much easier. Developers using C++ 1.0.t or other libraries, they just say it's just so much easier. I have everything here. I have all my tools here. The rich environment

that I need. And it just works, which is great. Yeah, absolutely. So let's talk a little bit about what you've been doing for the past few months since modern CPP. Since we talked about it last. After CPPCon. Right. What are some of the big changes?

I know you don't necessarily have anything ready to announce yet. Otherwise you might have been giving a session today. Yeah. But what are you working towards? We've done a tremendous amount of work on the foundational building blocks for making C++ 1RT work very naturally for the standard C++ developer.

Just tracking very well with the C++ standard, supporting things like std hash for any 1RT type. So if you want to have a std map or a std unordered map, you need to have a hash that just works things like getting all the compare functions in place string view and also things like std chrono so a lot of the windows apis will rely on things like date time or time span instead of having our own types we simply provide a natural bridge to the astute chronotypes and durations. So you can use things like two-second literals,

things like that, and it just works. So we've done a lot of work in that space just to make standard C++ feel very natural in terms of the general abstractions that you would use on Windows. But going beyond that, the focus this year has really been on our tooling story.

How do we provide the richest tooling possible for the C++ developer so that you not only can get the headers from us, but you can actually get the compiler that you can produce your own headers for your own metadata. And that will open up a lot of new scenarios for developers. What types of scenarios? Well, specifically, today we've shared the headers on GitHub, so you can, for a given

version of the Windows SDK, you can build apps targeting those APIs. But whenever a new flight comes out with new APIs, which happens pretty regularly these days, you have to wait for us to provide the updated headers. Otherwise, you cannot call those APIs very easily.

With the tooling, you'll be able to just generate them yourself on demand whenever you need them. You can also use the same tooling to produce your own components. So you want to do end-to-end authoring of a WinRT API, whether it's inboxed in the operating system or as a component for a third-party application, you can now author your own 1.0.t components with C++ 1.0.t. So the same syntax, the same semantics, the same type system, you know, no WRL, no CX. But you get the same experience, but you get to do it all in C++. And the tooling is what enables that. You know, given your own metadata, you can now on demand

generate all the necessary scaffolding, all the necessary fundamental types that you'd need to program against those types and actually implement those types yourself. If you're making your own component, could that component be used both by other C++ application developers or C Sharp.NET developers?

Could they make use of it too? That's exactly the key here. The C++ developer could always share his code with other C++ developers, but it's the ABI boundary that becomes the problem, and that's what WinRT solves. It really defines in a language

neutral way how do different languages communicate and share code and do callbacks in a way that works naturally and seamlessly across languages. And with the authoring experience by means of the tooling, you get to do that in C++. So today what typically happens in Windows is a bunch of developers in my building that author or implement WinRT APIs on a daily basis,

and they're using WRL. And it's very tedious for them because they have to program with WRL. It's a pain. It's a lot of work. There's a lot of overhead there. It's not modern C++. There's no value types. There's no move semantics.

It's just there's H results, and it's exception-free for the most part, and it's a pain. And so they can now author those components with modern C++ within the company. Yeah, I don't know where I was going with that. But yeah, it opens up a lot of scenarios both for people inside of the company, and there are a number of teams now inside of Microsoft using it, as well as developers that just want to write high-performance components and share them across languages.

They might have an existing C Sharp front end. They've invested heavily in building their app in C Sharp, but they want to do increasingly a lot of the heavy lifting in C++. And that's always been, well, if you've got the courage, you can build a C++ component and call it from a C Sharp app. And now we're saying, well, you can do it just as productively in C++ as you could have in C Sharp without sacrificing perf. Yeah, there were some really cool demonstrations in the keynote this morning. I'm not sure if you've heard of this Remix application that they were showing off.

Okay, so the demo was a bunch of videos were recorded from parents for a soccer team. And they're all uploaded to this application in the cloud. And it kind of stitched together a montage of videos. And in addition to just creating this montage, they then showed how you could drag and drop, edit 3D assets into the video. And what they actually did was a girl was kicking the soccer ball into the goal and they drag and dropped a fireball 3D asset and pinned it to the soccer ball so that when the video played the fireball just tracked

the path of the soccer ball so it looked like she was kicking a fireball into the goal, which is pretty cool. I'm guessing something like that is probably making use of C++ performance under the hood. There are a lot of teams at Microsoft that I speak to and that they it's always about is probably making use of C++ performance under the hood. Yeah, no. I mean, there are a lot of teams at Microsoft that I speak to,

and it's always about we need performance, and that's why we use C++. Nothing compares. That's just the reality. They work very hard to make C Sharp perform well, but it'll never perform well enough. Not for these kinds of scenarios, not for scenarios where you have a wireless device, a headset, a smartphone, you're running on battery and you need to reduce your overhead and increase your perf in every way you can.

And only C++ can do that today. But without fail, everyone complains about productivity. It's just too hard. Now we have the developers that have the skills, and that's great, but they also, you know, want to enjoy their work and be able to do more with less effort. Right. And that's what we provide. Yeah, so what you're talking about

with these C++ 1RT components, it sounds like it would be pretty attractive both to C++ library developers and to, you know, the.NET application developers because for to C++ library developers and to the.NET application developers because for a C++ library developer, you could then expose your library easily to.NET app developers. Right, right. It makes it very simple to do that.

There really is no simpler way to provide C++ functionality to a C Sharp developer that I can think of. It's just so seamless. Because the CLR has built-in support for WinRT, you know, point it to any WinMD, which is the metadata file that describes a component, and you can immediately begin using the implementation of that component, which may be C++, very naturally. You know, exceptions just work across ABI boundaries. Types, you know, are mapped naturally to the language that you're using.

It is really a very natural experience. And now we get to, behind the scenes, behind that ABI boundary, have the same level of productivity that you would have had on the front end, on the calling side. So is this already being used internally? It's just not quite ready for production use outside of Microsoft yet? Yeah, so as I was saying, the tooling is what we've been focusing on this year. And we've had various iterations of the tooling that we've used as a stopgap, and internal teams have been using that to generate their own metadata,

to generate their own projections of various APIs. But we wanted to provide a better experience for developers in general. And so we've re-engineered it purely in C++ using only modern C++. It's kind of funny. This is really the only language projection for 1.0.t that's written for standard C++ developers

in standard C++. Hopefully we'll be able to share the code soon for the compiler. for standard C++ developers in standard C++. And really, you know, hopefully we'll be able to share the code soon for the compiler. And you'll see that it's really all the same standard idiomatics. We'd like to, yes. I mean, being in a big company, there are more hurdles to doing that. But that's, you know, everyone on the team would like to do that.

So we're hoping to do so. And it's definitely been Microsoft's direction. That's right. We are trying to embrace open source as much as we can. It's certainly helpful. And there's no benefit to keeping secrets. And the beauty of what

we're doing, though, is nothing that we're doing in C++1.0.2 is proprietary. Nothing is really internal to Microsoft. It's all just building on what we've already released, existing APIs, existing functionality, but making it available to the modern C++ developer in a way that's not been available before.

So you can think of it as a reference implementation for WinRT, something that's sorely lacking today. Because if you're trying to figure out how it works today, documentation is sparse, and trying to figure out is hard. It's not impossible, but it's hard. So I'm hoping that'll help a lot. So another change with more tooling that we might get is hopefully the ability to write XAML applications

using modern C++. Is that something on the horizon? Right, yeah, that's a key stumbling block for a lot of people. They need XAML support before they can begin using this. Now, one of the things that XAML requires is rich metadata interop. So for things like XAML binding

and the XAML designer in general, it needs to be able to have a description of the types that a given application is going to offer up for binding or for other scenarios for navigation and so on. And just one second, I should back up a minute for listeners who aren't familiar with XAML. It's Microsoft's UI technology that's used in both UWP, WPF apps. And currently, most XAML developers are probably using C Sharp, but there's also the option of C++ CX, right? That's right.

Okay. Yeah, so XAML, I mean, I'm not a XAML developer. I don't have that background being a C++ guy. But certainly, XAML came from C Sharp. The roots of XAML are in C Sharp. But for Windows 8 and beyond, it was reengineered from the ground up in native code in C++ so that we can get better performance.

But it was always designed for the C Sharp developer, and certainly the experience we've had thus far in Visual Studio is very much geared towards C Sharp. But we're trying to change that. But the gap has been in metadata. So a C Sharp application inherently has metadata. It has reflection, has the ability to self-describe the types that you might bind to, for example. You know, if you have a button control and you want to do some binding. In C++, you don't have that inherently.

Therefore, you need some help in bridging that gap, and that's what we're working on, bridging that gap, so that, you know, given any c++ application you can do you can have it almost as natural or if not as natural experience with xaml in c++ but again this builds on the tooling that we're working on to really enable that rich connection between metadata and c++ and i know you can't give me a timeline necessarily, but do you think this tooling is going to be within the Visual Studio 2017 timeframe? I don't know.

You don't know. There are a lot of different stakeholders involved in something like this. It's a bit of a chicken and egg. Visual Studio wants to desperately include this, but they need XAML support. The XAML team would desperately like to add their support to this as well, but they need Visual Studio support.

So there's a lot of different players that need to get involved and get in line for this to really work. And the good news is that we finally have all of those stakeholders committed. Everyone wants it. Yeah, everyone wants it. So there's a lot of pressure for us to do it now, and there's a lot of people that are excited about getting it done. So we have tremendous support, and I'm hopeful that we'll have something before long.

You were talking earlier about changes in the standard library and how you need to make sure all those features are working with C++ and WinRT. Now that 2017, the ink is almost dry on it, is that going to free up some more time for you, that you will have those 2017 features in place and can kind of focus on the tooling? Right. So we did actually switch,

if this is what you mean, we switched over to C++ 17. We switched over to specifically the 2017 compiler. Not in terms of what we've released yet, but in terms of what we're focusing on now. So we're taking a deep investment, a deep bet in constexpr support.

Okay. And a number of other features which are specific to C++ 17 and only available in the newest compiler from Microsoft. So we're very much about embracing the latest and most compelling aspects of the C++ standard that are available in Visual C++. We also do support Clang. So we keep piggy, you know, jumping back and forth, you know, on our dev machines, making sure that we, it works in both.

It's sometimes quite a challenge, but that's the library developer's job to make sure that it does. But it's great. We get so much more now than we did before from just standard C++. One of the biggest problems we had, usability problems for developers, was that ultimately WinRT is based on COM and for every COM interface you need a GUID.

A GUID is just a large unique number that identifies that interface on the ABI as a contract, essentially. And the problem with WinRT is that it defines something called a generic interface. Okay. So instead of having an I vector of int that you'd query for, it'll be an I vector and it'll have a parametrized type, like a template in C++. So you can have an I vector of an int, an I vector of a string, an I vector of something

else. The challenge is every one of those specializations are a unique interface. So everyone needs its own GUID, its own unique identifier. And today, with the bits on GitHub, if you happen to instantiate one of those types for a parameter type which we hadn't previously seen in metadata, you'd get a compiler error and you'd have to manually write a bunch of code that associates the GUID, the unique identifier with that interface. And there's a complex algorithm that's baked into Windows that figures out what the GUID should be. So you can't just generate something random.

It has to be something very specific based on a hashing algorithm we have internally. And all the language projections must agree on what that algorithm is so that it'll all work. So any language can query for that specific interface with that specific set of parameter types

and it will just work. Now what we've done with C++ 17 is be able to use constexpr functions to actually implement the entire algorithm in C++ at compile time. Oh, wow. Yeah. So it's kind of a big deal

because we're effectively taking functionality that used to be only in the operating system and hoisting it and putting it in a header-only library and making it all work at compile time in C++, solving a tremendous amount of problems for the developer who wants to specifically author their own types. As soon as you start authoring your own types, going beyond simply consuming APIs,

you run into this problem. And so it's a great example of how we're embracing standard and modern C++ to really unlock solutions to problems we've never been able to solve before. That's awesome. So one other thing we talked about briefly before the show was this desktop bridge. Yeah. And that's probably something that not too many cpp cast listeners are familiar with um but maybe you can explain it better but basically if you want to make a uwp app which

is going to be an app deployed through the windows store and you have an existing application code base this desktop bridge can you know kind of containerize and and allow your app to be deployed through the store right right yeah so uh the neat thing about Desktop Bridge is it's more than just the store. Traditionally with Windows 8, there was this big divide between desktop apps and store apps. And all these new APIs, or many of the new APIs, were only available to store apps. And so the existing desktop developer was largely locked out of those APIs. There'd be great new functionality, but they couldn't call them unless they had something called an app container, which gave the application or the process an identity that those APIs required

in order to function. Now, the desktop bridge essentially provides that app identity for any desktop app, not just for store apps. And now you need to do a bit of work to sign in, you know, to buy into that. But it works, you know, absolutely works with, you know, traditional desktop applications. You can take a mainstream, any mainstream desktop application, and using this technology, essentially get that app identity for your desktop application. Now, through that, you can also enter that application into the store, but that's not required. That's not really the essential part of this.

The essential part is that you get the app identity, which means you can then enter into the universe of UWP APIs through the Windows runtime. There's a lot of APIs in there. There is. There's a tremendous amount of cool stuff in there. Things that you can't do with the old Win32. Exactly. Exactly.

So we're excited to get developers, and specifically desktop developers, developers that have existing large C++ code bases, to start using that as much as they can. And C++ WinRT is just the simplest way of doing that. The other roadblock for the desktop developers traditionally being, well, I have the C++ application, but now I have to flip the switch on CX. And CX is a bit of a virus. It has this way of spreading through your code. It's quite a pain, and people don't want to do that. Developers are fed up with language extensions, and they want to stand at C++. And so C++ 1.0.2 gives you that.

And with the desktop bridge, you get access to those things for your desktop application. So I think it's going to make a lot of developers very happy. And there's already been some progress with C++ application developers using this and some big name ones. Like I think Adobe probably has used this for Photoshop. I'm most likely. I believe they're in the store now. I'm not sure. I think so.

Yeah. There are a number of large big name apps that have come into the store thanks to this technology. So it's great to see that. And, yeah, well, thanks to Standa C++. You know, we're really behind that now at Microsoft, and we want to make that the best experience we can for those developers. So I think another topic we discussed last time on the show was async await C++, right? Yep.

Yeah, so WinRT itself has a deep async model. Right. And so C++ future, so beyond C++ 17, we're hoping to introduce something called coroutines to C++. Now, unfortunately, it didn't make it into C++17, but I think it's very close.

It's still on a TS, right? Yeah. So it's still on a student experimental sort of stage. But Visual C++ has an implementation, and the developer behind that, Gor Nishinov, has actually implemented it in Clang as well. So you could, although it's not in the main branch yet, you can actually get both Clang and Visual C++ to compile your coroutine code. And it works incredibly well.

For the C++102 project, we've invested heavily in it and supported very deeply so that you can use that model for your async programming, which is a far more natural model than Visual C++ has traditionally had with things like PPL, which is a far more natural model than Visual C++ has traditionally had with things like PPL, which is very problematic.

So, yeah, I mean, we believe in it, we've invested in it, and we're hopeful it'll be in the standard very soon. I didn't know that Gore had worked on the Clang implementation. That's pretty exciting. Yeah, that's more recent. But yeah, he's had a lot of fun there, and a lot of the experience he's had building the Clang implementation,

because he did the Visual C++ one first, he's now taken that Clang experience that he's had building on Clang and reinvesting that in Visual C++ to make our implementation even better. Nice. So it's great to see the progress they've made. And it's just one of those features that I really can't imagine living without anymore. So I'm really excited to get it into the standard as soon as we can. Are you able to already use that internally?

Because it is under the std experimental flag in the 2017 compiler. Yeah, so it's on std experimental in Visual C++, but the Visual C++ team are supporting it in production. Okay. And that's the key. So many internal customers, Windows itself, we do use coroutines because it's production. And that's the key. So many internal customers, Windows itself, we do use coroutines because it's production and Gore and the

team, they're very good at responding to bugs and fixing them and providing hot patches if we need them very quickly. So yeah, it's a really great feature and it's worth whatever growing pains you might go through in terms of using it. It's definitely worthwhile.

Okay. Is there anything else you want to talk about today? No, I think we've covered many of the points. I think, you know, we're excited to get this out as soon as we can. Yeah. And whether you're using this or something else, we're just excited to make C++ better on Windows. You know, there's a lot of talk at Microsoft,

certainly in the Visual Studio group, about cross-platform and the Mac support and Android this and that. My job is to make it great on Windows, and that's where my focus is. And, you know, as a company, we can do all of these things, and it's exciting to see it coming together. Okay, so as of now,

if you're interested in, you know, C++ 1RT or modern C++, you can still go to GitHub and download the latest version of the SDK? Yes. There's a project on GitHub. You can get the latest creators update. All the headers for the creators update SDK are there.

So you can write all the apps for that. Hopefully soon we'll have the tooling out so you can write your own components as well. Do the full authoring experience. And then beyond that, XAML support will come as soon as we possibly can. And Microsoft did announce that there will be a fall

creators update, which is what they're calling it, creators update V2, I guess. Okay. So I guess once that's out, hopefully soon after you'll have a new version of C++.RT, right? Yeah, so as soon as we release a new SDK, we will make sure that the headers are updated so you can certainly access those APIs. But ultimately, I'd like to stop releasing the headers themselves and simply have the tooling out there so you can do it yourself.

That would be a lovely end goal for us, for sure. Okay. Well, Kenny, it's been great having you on the show again. Thank you, Rob. It's been fun. 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, Bactres jumps into action,

capturing detailed dumps of application and environmental state. Bactres 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 slash cppcast. Welcome. We are here. Build 2017, day three. Final day of the Microsoft Developers Conference. And now I'm being joined by Marion Lupreux. Marion is currently leading the team responsible for making Visual Studio more productive for C++ developers. Marion, welcome to the show.

Hello. Thank you for having me. It's good to have you here. So I'm not joined by Jason here today, but usually when we introduce a guest and go over their bio, he loves asking the question, how did you get started with programming? Oh, it's been a while now.

I think I started with basic S, with the line numbers. And my math professor put me in front of the computer for the first time and said, you're done with math today. Draw me something. And I drew like a snowman with circles and arrows. And that was like I got hooked. That was my first program ever without first touching the computer.

Real programming, I think it was with uh vb6 and then uh very shortly after i got to c++ and i kind of been doing that for a while now cool and how'd you make your way into microsoft um so i joined microsoft 11 years ago okay Okay. I was living in Bucharest. I was programming. And, yeah, they had a very interesting offer to come work for Microsoft as a program manager on the C++ team. So I thought, I know C++. I love C++. Microsoft sounds cool. What's a program manager?

And then I found out that we don't do either programming or managing. But we do a lot of cool stuff with like talking with customers and for the past 11 years, basically I've been trying to make, you know, the experience of C++ developers easier inside Visual Studio. That's been a great, fun ride. Okay.

We'll start talking about, you know, making stuff better for C++ developers in Visual Studio. I talked yesterday with Kenny Kerr. He unfortunately missed the keynote. Do you want to go over some of the keynote announcements that you thought were most notable for C++ developers? Most notable. Well, so before I go into this C++ more notable one, I think the thing that's going to stick with me from the first keynote and the first day for the next few years was the Emma device. That basically brought back the possibility for Emma to actually design and go back to work.

That's impressive. And I think years from now, I'm going to remember that as something that happened that I learned about in this build conference. Beyond everything that I learned about C++ and cool things. So for those of us who didn't watch the day one keynote, this was a device that a Parkinson's person

was using. They worked with a developer from Microsoft? Yes, there's Microsoft Research and they built a device that counters the tremors in the hand. It's some type of bracelet that vibrates, and that's able to stop her hand from having tremors, and she's able to draw and write again. That's pretty cool.

We basically are able to build those kind of devices. Very inspiring. Very inspiring. And then I think the second keynote, coming back to C++ now, the thing that sticks out with me was Terry Morrison sitting on the stage, and I quote, he said,

Windows, we're going to make it the best damn dev box on the planet. So that resonates very well with me. I think at the Visual Studio, we definitely want that to be the case. So we're on the same page there. He had some very cool announcements about the new Linux subsystems that are coming to Windows beyond Ubuntu, like Fedora and OpenSUSE,

which I think this Plus Plus developer will find very useful with the support that we have built in the SciVisual Studio, as well as some of the accessibility improvements that they made, that they're announcing, which I think it also speaks back to kind of the making software that enables people. Yeah, one of the sessions I went to this morning was Amanda Silver talking about Visual Studio 2017 improvements. But before Amanda took the stage, there was a person, I think he was a software engineer on the Visual Studio team, if I'm not mistaken, but he was blind. And he showed how he uses Visual Studio using a screen reader, which reads things incomprehensibly fast.

I couldn't understand a word it was saying, but he's used to it and is able to parse it. And he showed some of the new improvements that VS 2017 added for him, like the ability to read out local variables and things like that. It was pretty cool to watch. I always wondered how someone who's blind

could use an application as dense as Visual Studio, and he was able to be very productive. And accessibility is top of mind for us at Microsoft, and it should be top of mind for all the developers out there. And I think we're making advances to make it possible every day

for people like that to be successful at what they do. And they're doing a great job once we give them the tools. Okay,'re doing a great job. Yeah, definitely. Once we give them the tools. Okay, so what were we talking about? C++ build. C++ build, yeah. Yes.

So what else? Well, Amanda showed some C++ Linux development as well. Right. I did show some of that in my talk on the first day. There's been a few announcements on that front. One of the demos that I did was very experimental bits. It's the ability to use CMake to target both Windows and Linux from inside Visual Studio. That's something that we have on our roadmap.

We don't have yet a fixed date when we're going to ship it, but we're really excited to share that direction of where we're going. So that's still just an experimental phase, because that has been talked about for a while now, right? Yeah, so well, we... The CMake support? Yeah, the CMake support inside Visual Studio is already

out there. People can use it today to target, to build Windows binaries, so we have full- full edit build debug cycle. The only added piece is from the same project as you loaded inside VS, you can also build targeting Linux. Okay. And rather than

using MSBuild to target Linux, which is the case today for our Linux integration. And that's coming soon as well. Okay. What else is new for the open folder CMake type of solution? So that's, I'm going back to Terry Meyerson and making Windows a great dev box. I think we want to make sure that any developer

that comes to the Microsoft platform or comes to Windows to develop apps on has an easier experience regardless of whether they have MS Build projects or they basically bought into the Visual Studio solutions and projects. We're basically tearing down those walls with Open Folder. Thanks for bringing it up.

It's very easy. You just point to a folder that all the source code gets scanned, you get some basic form of IntelliSense, it's very easy to configure your build, you can also debug binaries that are built for Windows, and then something we announced yesterday

actually in the Channel 9 Live talk, support for MinGW debugging, and that basically completed our end-to-end experience for MinGW developers. If they're using MinGW today and that basically completed our end-to-end experience for MinGW developers. If they're using MinGW today and they need to edit code, they can load it inside VS and there's quite a few

trivial steps that they can configure in Telesense to get a great editing experience inside Visual Studio. Then they can easily configure the build if they choose to by configuring a task with calling make or whatever the right command is to build their projects. And then they can actually debug

MeanGW generated binaries using our MI engine that we've been using in the past. And we're using it successfully for Linux debugging, for Android debugging. Now basically we're bringing it to Windows to be used for MeanGW binaries. And we're basically tying in the whole end-to-end. And again, like CMake we talked about

as being part of the open folder experience as well. Right. And you added a new target in addition to CMake, right? Yes, the new generator. New generator. We have Ninja. Okay. That was one of the top asks we got.

Of course, when we shipped first, we had MSBuild generator support inside CMake. But Ninja has different characteristics in the way it consumes the resources of the machine when it builds, and some people prefer that. So we want to make sure that we give them the possibility to use Ninja with the same benefits inside the IDE,

like the rich editing and building and debugging experience. And we wanted to make sure that we can get the right information from the CMake cache for Ninja and for MSBuild, regardless of the generator. So it took us a while to get there, but now we're there, and we're very happy to let everybody use Ninja as well. Okay. Can you give us any indication of what might be a future

generator? I think now... CMake and Ninja? Something exciting is that for the Linux demo, so building the CMake project on the Linux machine, all I had to do

to make VS work is to take an enlistment of the CMake source code from the official Kitware repository for 3.8.1. Okay. And by just building that on Linux machine and running it, that version, which is the official version of Kitware ships, was able to communicate with Visual Studio and pass on all the information. And that was using a Makefile, a Unix makefile generator. So I think we're at the point where we can have good enough implementation regardless of the generators that CMake supports. But we'll have to test that.

At this point, we're confident about the Ninja support, that the testing is great. We'll obviously relax it even further if we see that we get all the information for the different VS services that we want to service. Okay. I did go to your session, which was 7++ reasons to switch to VS 2017, right?

Yes. And I think I'm now officially allowed to say there are eight because it's past the session and the first increment. Right, right. So one of the things that you talked about that I think was new was changes in unit testing, right? Correct. So you want to go over that a little bit?

Yeah. So that's an interesting one. We've been interviewing customers, talking a lot about the support we currently have in unit testing, and one of the things we've been hearing loud and clear is support for more unit test frameworks. And that's something that

was formed really clear as a goal. We want to make sure that all the popular unit test frameworks are supported out of the box from Visual Studio. Just install it and it happens that you have unit test framework with Google tests or they're written with BoostTest. They're available right there in Test Explorer at your fingertip.

You can run them. You don't have to step away from Visual Studio and run them on the command line. You don't have to do heavy gymnastics to debug a test inside Visual Studio and so on. It should be very trivial. And when we started looking at it, we found that there are some extensions out there

that are already doing a very great job of supporting this unit test framework. So we're collaborating right now on the Google test support with Christian and Jonas, which have been developing Visual Studio extension for a while now, starting, I think it's 2013. That already integrates Google Test with the Test Explorer. What we want to do with it is improve it even further, make it part of the product, and make sure that everybody that develops using

Google Test actually benefits from this adapter that they built. Basically, raise awareness as well. And then we obviously don't want to stop there. We want to go support Google Test as one. Boost Test would be don't want to stop there. We want to go support Google. Google test is one. Boost test would be the next one that pop up in the list. And looking at the comments on our blog,

I see people asking for catch as well. Yeah. We've had the author of catch on CBBCast twice. And yeah, it's a really good framework. Yeah. And that's certainly something that we'll consider. I think it'll be very exciting to have all of them there and basically have more

people even interested in doing unit testing the more easier we make it. So that's just the first step to kind of remove the reasons and make it possible for you to do unit testing regardless of the unit test framework you already made the choice to use. I think the next steps in the unit test framework you already made the choice to use.

I think the next steps in the unit test would be to streamline even further the way you write unit tests. And that's forward-looking. Hopefully we can talk later in the year about some of the plans we have there. Staying on the subject of unit tests, I mentioned how I went to amanda silver's vs 2017 talk she was talking a lot about dot net specific scenarios in visual studio as well but there was some time spent on c++ but one feature she talked about when talking about unit testing was

this new live unit testing feature where you're able to see like, you know, this area of code is being covered by a test and this test is failing right now. And if you make changes to the code, it'll automatically like recompile your unit test and rerun it. And, you know, suddenly it goes from fail to past. Is that an experience that might come to C++ eventually? The demos are very exciting and I'm really excited about this functionality. It's only available for C Sharp right now, and we are keeping a close eye on

kind of what the reception is in the.NET community. It seems to be very good. There are obviously some challenges with C++ when it comes to building in the background, running tests in the background. So we haven't done a lot of digging. We obviously would love to have the support for C++ as well.

If there's people in the community with ideas of how we could provide a great experience like this inside of the studio, I'd love to have that conversation and start brainstorming of how we can bring that in without annoying all the customers. Background C++ builds. Wait, wait, I didn't get to type my semicolon. What are you doing? Kind of experiences.

Right. I should mention that's in the VS 2015 .3 update, which isn't out yet. You can get a preview of it now, but it's not official yet, right? The live unit testing for yeah yeah um i think we had something uh already in our in the rtm release for 2017 but again for c-sharp only right um the improvements that are coming um in this are um

related with ci and running the tests. Okay. But yeah, someone on the.NET team will do a much better job at explaining the differences between the releases. Let's go back to your talk. I think you also talked about some changes with regards to cross-platform development in Visual Studio.

Yeah. So I demoed Linux specifically. Right now we wanted to share with people the fact that the experience we shared in the past with Android and iOS, that you do code sharing across multiple projects and you have a shared project with your source code and then gets included in multiple projects that are architecture-specific, comes to Linux as well. Okay. This is where you have a shared project where all your code lives

and then your Windows project and your Linux project are kind of empty projects that just pull in all the source files from the shared one, right? Correct, yes. And they get built in every context, the same files. And that's really useful and powerful when you get to edit code and we are able to surface errors from a different context in which you're building before you even build.

That was the primary demo. Something that I didn't get to demo, I would have liked to demo, is also our support in the Linux platform for targeting the Linux app system, which is there. It works great. We have a few blog posts that Mark Goodner wrote already. the Linux subsystem, which is there. It works great. We have a few blog posts that Mark Goodner wrote already. And I think it would have dropped the point home, but there was not enough time to demo everything. So I definitely encourage everybody to go check out the blog post and see how to set it up.

So when the Linux development was first announced, you had to configure it to go SSH over to some other Linux machine. But now the subsystem for Linux is in place. You can actually just do it on local host. You can do it on local host. You still need to go to configure it. You need to type in 127.0.0.1 or local host and go through SSH. And the blog post tells how to configure SSH for the WSL environment to get it to work,

but it's like two or three steps, I think. And it gets... What Mark does is keep that blog updated as WSL iterates over, making it easier and easier to work with SSH and... Yeah, it just works. You can build Linux binaries

locally on your Windows machine without having to go remotely somewhere else and now with the announcements from the keynote you can be targeting ubuntu open source or fedora version linux awesome that's okay anything else um from your session that we haven't gone over yet that you wanted to bring up? The conformance work that we're doing. I think we're making great progress. You already had Daniel here invited when we released the final RTM release of 2017. Since then, we've been working on a lot of C++17 features.

So I think we're making great progress. Constexpr if is now in and structured bindings. And of course, we already had the NRTM, the optional, any, those kind of STL types that helps that come with C++17. We're also announced today's report for two-phase name lookup, which it's in preview,

so it's a partial implementation yet, but Stefan is feeling very good about it. Talking with the front-end team, though, they still feel like they have some ground to cover. They think they're past half of the work they need to do to make it complete. But they're confident they're going to have a two-phase name lookup by the end of the year.

Okay, so it'll be in this year's C++ or Visual Studio 2017. Yeah, and we're hoping that we're going to be able to say that we're C++14 complete by then. We're having the C99 preprocessor in as well. We'll see. We're optimistic about it. It would be a good thing to call out. And how about 2017

features? I know the ink's not quite dry yet, but do you think you're going to have C++ 2017 complete in 2017? It does have a ring to it. I would like that. I think the front-end team is really excited to try it. We're doing our best to have all the features.

We're not ready to commit to have that in, but it would certainly be nice. And again, I think I should call it out that for us, it's nice to say that we're C++14 complete or C++17 complete. We're never after that claim. Like, even when we did C++11 features, we knew we have C++98 features that are not yet done. And we still went to implement C++14 or C++17 features that we felt are much higher value. Right.

Have much deeper impact. Can actually help users write more modern code. And we're still going to continue doing that. That's why we're also investing in technical specifications. Modules. Implementations, correct. But we understand that the lack of, you know, two-phase name lookup and the preprocessor causes some frustration.

So we want to catch with that up. But I don't think we're going to have lots of customers starting using variadic macros once we implement it in the compiler. I hope not. I mean, there's existing code bases that are already using it, and that's what we do want to support and have full conformance as well for that. Well, I know we talked to lots of different library developers on the show,

and we would frequently ask, you know, what platforms does your library run on? And, you know, when we first started the show two years ago, it was somewhat common for them to say, well, we can't run on Visual Studio yet because we don't have variadic templates or something like that. So it would be really nice to see that go away, for a library developer to be able to say, yeah, GCC, Clang, and MSCC. Yeah, and I hope we're very close.

I hope people try the latest Theta 17 compiler that's going to come with 15.3, that is going to have all these updates. They will be in Preview 2, I should call it out. So the Preview 1 that is available today still has the RTM version of the compiler. So Preview 2 will have all the features that are new in C++ 17 in 2017. And hopefully we remove some more roadblocks for people.

Speaking of libraries, I wanted to mention mention vc package as well really briefly okay as as something that uh we're working on and we're we're very excited about to make life easier for windows developers um to consume c++ open source libraries so we're about we have 220 libraries already and a lot of them are contributed by the community. Okay, that's good. And we're really excited because it's a lot more simple mechanism to acquire the libraries. You don't have to worry about how to build them.

We're curious to see what the community thinks and give us more feedback of where should we take this experience further beyond that. So this was first announced just a couple months ago. Did it come out in 2015? It was announced at CVPCon, and it's a standalone tool that you just go on GitHub and install it from. It's not tied with any version of Visual Studio,

but it supports 2015 and 2017 now. One other thing I saw on the Visual C++ blog uh which i hadn't heard too much about was obviously visual studio 2017 supports modules but you're releasing uh the stl as a module right that's correct yes um so and this is just uh an experiment on top of the experiment modules. Gabi is working on coming up with a draft proposal of how the standard library should be modularized. This is just to kind of experiment with it, get people to try a much more significant modules of their own. In the past

you would have had to write your own module to kind of see how the whole module system works. Right now you can get started with STL and that's kind of the building block for all the other libraries out there as well. So hopefully other libraries will be able to experiment with modules now that they can take a dependency on the

STL modules that we kind of have inside the box. They're pretty easy to install. They're a separate checkbox in the Visual Studio installer. We'll make them by default as soon as we evolve them further. They're going to be on the box once we're more confident about the compartmentalization. Right now, they're still in an experimental

mode. One other thing that got announced this week was Visual Studio for Mac, and now it's general availability. And correct me if I'm wrong, but I believe that's based on Xamarin Studio? That's correct. Okay, so is it still just like a C Sharp and F Sharp editor, or is there going to be support for C++ in there too?

I think the support for C++ in there too? I think the support for the language is evolving there. There's a lot more languages being added to Visual Studio for Mac. There are some specific end-to-ends that that IDE tries to enable.

C++ is not one of them right now, so C++ is not supported in Visual Studio for Mac. We do have Visual Studio Code, which does support C++ is not one of them right now, so C++ is not supported in Visual Studio for Mac. We do have Visual Studio Code, which does support C++ both on Linux, Mac, and, of course, on Windows. And there's nothing that we have to announce yet for Visual Studio for Mac.

Okay, well, I think that's everything I had. Was there anything else you wanted to bring up before I let you go? Well, definitely check out my talk. It's available at Build. The recording is available on Channel 9 as well. So if you have any feedback of how we can improve the product, I'd love to hear from you. And thank you for having me on the show.

Yeah, well, I'll put a link to your talk in the show notes. And then you were also on Channel 9 yesterday, so I'll see if I can find a link to that too. That's up too as well, yeah, the show. Yeah. Well, I'll put a link to your talk in the show notes. And then you were also on channel nine yesterday. So I'll, I'll see if I can find a link to that too. That's up to as well. Yeah. The channel nine live. And,

uh, if you give me one second to give you congratulations, I think they're in order because, uh, you're, uh, right now past the 100, uh,

show. It was great to have a BRNF for the 100 show. Um, thank you. So, yeah, congratulations. I think you started a whole uh a movement

thank you i appreciate it thanks for coming on the show thank you 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.