Original subtitles

[Music]

hi everyone my name is erica sweet i

work on the c plus plus team and i'm

here to share what's new for c plus plus

cross platform developers and visual

studio 2022 if you're a c plus plus

developer who is building for or looking

to add support for more than one

platform or if you're developing with an

eye to open source then this talk is for

you

maybe you target both windows and linux

but your team isn't as familiar or

productive with command line tools like

gdb

maybe you maintain different workflows

or configuration files for every

combination of target platform and

development environment and you're

looking to streamline that process while

still supporting a diverse set of tools

or maybe you only build locally for

windows and you rely on your ci pipeline

to check non-windows builds

if you don't target windows at all then

stay tuned as we discuss c plus plus

cross platform dependency management and

build and debug a linux skui application

natively on windows with wsl

so i'm starting with a cmake project

open in visual studio cmic is an open

source cross-platform build system

generator that's supported natively in

visual studio and is our recommendation

for c plus plus cross-platform

development if you don't use cmake then

visual studio has remote debugging tools

for you that we'll cover in the second

half of this demo

one piece of feedback that we received

on visual studio 2019 was that it could

be difficult to reproduce cmake builds

outside a visual studio

so to address this we work closely with

the maintainers of cmake to develop a

new file called cmakepresets.json

that's supported directly by cmake and

can be used to drive cmake generation

and build both with and without our

tools

that means your team can use it from

visual studio from vs code from the

cmake gui in a ci pipeline or from the

command line on windows linux and mac

visual studio's cmake presets

integration is automatically enabled for

me because i have the

cmakepresets.json file at the root of my

open folder but if i didn't have that

file then i could enable the integration

by going to tools options cmake checking

prefer using cmg presets for configure

build and test and then closing and

reopening the folder in visual studio

cmg presets is the recommended

alternative to cmake settings and will

be the default configuration method in

future releases of visual studio 2022

so you might realize across the menu bar

that i now have three drop downs the

drop down on the left is my active

target system so because cmake is cross

platform i can build and debug this

project on my local machine

on any number of wsl distros that visual

studio will automatically pick up on or

on ssh connections and these can be

connections to servers desktop it

doesn't matter and i can target all

these systems from the same instance of

visual studio

the drop down in the middle is my active

configure preset which drives cmake

cache generation and corresponds to the

siemens configure step from the command

line

and the drop down on the right is my

active build preset which drives c make

builds and corresponds to the cmake

build step from the command line and i

can select manage build presets to open

up my cmakepresets.json file and take a

closer look

in this file i can define any number of

configure presets build presets or test

presets which encode the information

that i would normally pass to cmake from

the command line so in my configure

preset that's things like my generator

and my build directory

i've already set up my presets file so i

can go ahead and kick off cache

generation on windows

for lots more information on

cmakepresets.json

as well as its companion user level file

cmake

userpresets.json you can check out aka

dot ms slash c make presets vs

all right so it looks like cash

generation has finished but it was

unsuccessful because i'm missing a

dependency

cma cannot find glad so as a c-plus plus

developer you might be used to copying

and pasting dependencies around and

resolving any transitive dependencies by

hand or you might be used to platform

specific solutions like a system package

manager and to help mitigate this i'm

using vc package which is an open source

cross platform dependency management

tool for c and c plus so because one i

have this vc package.json file adjacent

to my root c make lists

and two i'm passing the vc package tool

chain file to cmake

then when i configure this project vc

package will automatically bring down

and build all of the dependencies that

i've listed here from source or download

them if i'm using binary caching and

install them in a subdirectory of this

project's output directory so the only

thing that i need to do to add this

missing dependency is add glad to this

list

and reconfigure the cache

none of this is visual studio specific

it all reproduced from the command line

if you're using cmake and vc package

which i'll take a closer look at in just

a few minutes for more information on vc

package you can check out aka dot ms

slash vc package

all right so it looks like steemit

generation has finished and this time it

was successful so as i scroll up in the

cmake output window you can see that the

installation of glad and its two

dependencies took

73 milliseconds

to 65 milliseconds and the entire

operation took less than five seconds

and that's because i'm using vc package

binary caching so the binaries that i'm

downloading and installing locally are

cached in github packages for other

developers on my team to pull down on

use on their local dev boxes and to use

in my ci pipeline

and before i check in these changes that

i just made to vc package.vc

package.json i'm going to quickly verify

that those changes also work on linux so

all i need to do is change my active

target system in visual studio to a wsl

distribution and reconfigure the cache

and this is a really easy way to verify

that any change that you make

works on both windows and linux locally

from visual studio using windows and wsl

all right again it looks like cmake

generation was successful so at this

point i'm ready to check in those

changes i made to vc package vc

package.json

so we added glad to our list of

dependencies

i will commit those changes and then

push them to the remote

so this project is using github actions

and i've authored a workflow file that

will automatically kick off a ci run on

both windows and linux on push so that's

getting started now and we'll come back

and take a look at it in just a few

minutes

because see my generation was successful

i can now leverage all of visual

studio's cmake features so that's things

like cmake targets view over here in the

solution explorer which is a more

cma-centric way of viewing your code

in editor documentation for cmake which

surfaces official cmake docs in the ide

and language services for cmake so i can

do things like right click and find all

references go to definition or peak

definition on cmake variables targets

and functions

as an existing visual studio customer

you might already be familiar with the

windows development experience so i'm

going to continue to focus this demo on

local development with wsl 2.

so right now my active target system is

a wsl 2 distro

and when i build this project

visual studio is actually making a copy

of my source tree in the linux file

system and building with native linux

build tools like gcc or clang and the

reason for this is that wsl 2 is a lot

faster anywhere from 3 to 20 times

faster when it's accessing source files

in the linux file system rather than the

windows file system which can lead to

significant performance gains for you

and this is all done using visual

studio's native support for wsl 2 which

is brand new in visual studio 2022 and

will be used automatically anytime that

you're targeting a wsl2 distribution

when i start debugging i'll have the

full suite of visual studio debugging

features available to me backed by gdb

and to help illustrate this i'm going to

walk through a bug that i encountered

when i was prepping for this demo

so if you take a look at the solution

explorer over to the right you can see

that this project contains four targets

including a physics library and a

samples executable

so i had samples running as a nice

visual demo

but when i went to run the project for a

second time it behaved just like that

and exit as soon as it was launched so

it was time to start debugging

the first thing that i did was look for

the program's main function or the entry

point to the program and as i was

scrolling through main i got to this

update loop that handles all of the

input and rendering and the condition

that is checked before this loop is

executed is the return value of this

window should close function which

checks the close flag of the main window

and because i'm seeing that main window

closed on me i thought this would be a

good place to set a break point and see

what was happening so i'll set a break

point

press f5 to relaunch the debugger

and now i can press f11 to step into

this window should close function

and this function is just checking if

this window should close flag has been

set

so i can run the cursor down to this

return statement and it looks like right

now the value of windows should close is

zero or false meaning this window should

not close but because i am seeing that

main window close on me i'm going to set

a new data break point that will hit if

the value of window should close changes

so i'll go over to breakpoints add a new

data break point for the address of

window

should close

what's cool here is that i don't need to

look at memory at all i can just

reference the name of the variable

directly

press ok

shift f11 to step out of this function

back into main

f5 to continue execution and sure enough

our data breakpoint was hit so the value

of window should close is now one or

true this window should close

so i wanted to take a look at the call

stack to see what was calling this

function

so i can see that the program is

polling for events

processing events and in this case that

event is a keyboard event and

specifically the escape key so this

program is behaving as if i had pressed

the escape key

to fast forward a little bit i did a bit

more debugging and found out that the

program was always remembering the last

event from the previous session

so the first thing i tried to do was

process that stale event before this

keyboard event handler was set up and

that did not work but when i set a break

point at that location to debug and take

a look at what was happening the program

did behave as expected which led me to

believe it might be some sort of timing

issue and perhaps that stale event was

coming in just after the start of the

program

so what i ended up doing was adding just

a half second sleep before processing

that stale event so i'll uncomment out

my solution

remove the break points that i had set

stop debugging

and then relaunch by pressing f5 and

this time instead of exiting immediately

we'll be able to interact with samples

and play with all of our physics demos

now what we see here is actually pretty

cool

so this is a linux application running

natively on windows with wslg the g

stands for graphics and windows 11 and

you might notice the linux space tiling

up here in the corner which indicates

that we are indeed running this in a

native linux instance

when i was debugging i had the full

visual studio experience backed by gdb

which shows that graphical expression

that you just can't really get when

you're debugging with gdb from the

command line

another thing i want to underscore is

that nothing that i've done so far locks

you into visual studio so i'm building

with cmake vc package and gcc i'm

debugging with gdb so there's nothing

visual studio specific and this is a

great option for teams who like to

maintain a diverse set of tools

and to take a closer look at that i'm

going to hop on over to that github

actions run where we reproduced our

builds using the same tools in our ci

pipeline

so here's github actions here's my most

recent run that was started six minutes

ago

it was successful on both windows and

linux and if i take a closer look at

that linux run

the thing that i really want to show you

is that i'm using the exact same cmg

presets.json file to drive cmake

generation and build that i was using

locally so here i'm passing in the name

of my configure preset and build preset

to cmake which really ensures that your

team can maintain that single source of

truth that you can use to drive builds

both locally from the ide like visual

studio from the command line or from

your ci pipeline

in the same vein vc package is

downloading and installing the exact

same binaries that i was using in visual

studio for local development when i was

targeting both windows and wsl

finally if you're not using cmake then

visual studio has remote debugging tools

that you can use to debug on both linux

and mac so brand new in visual studio

2022 is the ability to attach to a

remote process and debug it with the

lldb debugger from visual studio

this feature is supported on both linux

and mac but for the sake of the demo my

process will be running on wsl

so as i mentioned earlier with visual

studio support for wsl 2 visual studio

maintains a copy of your build sheet in

the linux file system so over in ubuntu

you can see that i'm working on wsl now

this is the ubuntu 2004 distro i've

navigated into that build directory

i'm going to start ssh

and launch samples

so this is the exact same binary that we

are building and debugging from visual

studio just a few minutes ago

back in vs you can use the same attached

workflow that you might already be

familiar with so debug attached to

process we want connection type ssh

the connection target is erica at

localhost

because i haven't added this connection

to the connection manager

i am being prompted to authenticate

and then trust the authenticity of the

connection

and once it's done connecting then

visual studio will prompt me with the

list of all the processes that are

running on that wsl distro so i want to

attach to samples

the last thing i need to do is say

whether i'll be debugging with gdb or

lldb so again support for lldb is brand

new in visual studio 2022 but i could

follow this exact same workflow with the

gdb debugger

so i will select that and then when i

hit ok visual studio will attach to that

process with the lldb debugger and when

i press pause

i will see the current line of execution

as well as my variables the call stack

and i'm ready to start debugging

one thing that i want to emphasize about

this workflow is that it doesn't matter

how you build the binary that you're

attaching to from visual studio so you

can be building with a custom build

script with make with xcode with cmake

it does not matter you can still attach

to it and debug it using the front end

of the visual studio debugger backed by

either gdb or lldb

for example the office team at microsoft

primarily uses windows and visual studio

for their local development and they're

excited to use this feature to remote

debug mac failures

previously they might sift through log

files to try and understand what's

happening or for a particularly bad

issue they might spin up a mac machine

for native debugging which is both time

consuming and a less familiar debugging

experience

for more on information on this workflow

including how to get started with the

lldb debugger you can check out aka.ms

lldb and for more information on other

build system agnostic remote debugging

workflows like debugging a linux core

dump from visual studio you can check

out our c plus plus team blog at aka dot

msl cpp blog

that pretty much wraps up all the new

features that i wanted to show you today

to quickly recap what we covered we used

cmig presets and vc package to build a

cmg project both with and without visual

studio so our local builds targeting

both windows and wsl can be reproduced

in a ci pipeline or from the command

line as we saw with our github actions

workflow

this can help your team ensure that you

maintain that single source of truth and

that you're not locked into any specific

tools

we also showed how the local visual

studio studio development experience now

applies to linux with visual studio's

native support for wsl 2.

it is just as easy to build and debug a

linux gui application locally from

visual studio as it is to build and

debug for windows

and finally no matter how you're

building your cross-platform application

visual studio offers the best debugging

experience for debugging with gdb or

lldb which can save a ton of time

compared to using those same tools from

the command line

to get in contact with our team or to

stay up to date with what's new for

cross-platform developers you can check

out our team blog which again can be

reached at aka.ms.cppblog

thanks for tuning in