CppCast - VS for Linux
Episode Date: April 21, 2016Rob and Jason are joined by Ankit Asthana to discuss new features for Visual Studio and VS Code including new support for Linux developers. Ankit Asthana is a program manager working in the Vi...sual C++ Cross-Platform space. He is knowledgeable in cross-platform technologies, compilers (dynamic and static compilation, optimizer, code generation), distributed computing and server side development. He has in the past worked for IBM and Oracle Canada as a developer building Java 7 (hotspot) and telecommunication products. Ankit back in 2008 also published a book on C++ titled C++ for Beginners to Masters which sold over a few thousand copies. News CppCast Stickers! STL Fixes in VS 2015 Update 2 Runtime Compiled C++ Windows API sets: source of most Dependency Walker glitches Ankit Asthana Ankit on LinkedIn C++ for Beginners to Masters Links /build 2016: What's New with C++ Cross-Platform for Visual Studio 2015 Update 2 /build 2016: C++ Discussion /build 2016: Cross-Platform at Microsoft: Xamarin, Cordova, Unity and C++ Panel /build 2016: Top 6 Reasons to Move Your C++ Code to Visual Studio 2015 Visual C++ Blog
Transcript
Discussion (0)
This episode of CppCast is sponsored by JetBrains, maker of excellent C++ developer tools including
CLion, ReSharper for C++, and AppCode. Start your free evaluation today at jetbrains.com
slash cppcast dash cpp. Episode 54 of CppCast with guest Ankur Dastana recorded April 20th, 2016.
In this episode, we talk about STL fixes in VS 2015 Update 2.
Then we talk to Ankit Asthana on the show again from Microsoft's Visual C++ team.
Ankit tells us all about the latest Visual Studio news, 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?
Good, Rob. How about you?
I'm doing pretty good.
I had a wedding last weekend. That was fun.
Not you. You didn't get married.
No, I've been married. I was in the wedding party, though. So, take
a lot of pictures, drink a bit.
It's good times.
So, as you've been tweeting
out, I do have the stickers for anyone
who wants to find me
at the next conference and wants
a podcast sticker yes so we printed out i think it was 200 stickers there's a square one and like a
larger banner one that has a cpp cast logo on it so if you want one for your laptop uh yeah hunt
down jason if you're going to be at C++ now.
I think there should be more than enough for all the attendees if they're interested there.
Yes.
There should be more than enough for everyone.
I'm sure we'll do the same thing
before CBBCon, print out a few more
of those, but if
you aren't going to be at either conference this year
and you really want to get a sticker for your laptop,
I'll put a link in the show notes, but you can't going to be at either conference this year and you really want to get a sticker for your laptop um i'll put a link in the show notes but you can just go to stickermule.com and search for
cpp cast and find our stickers pretty cool stuff yeah yeah uh so top of every episode i'd like to
read a piece of feedback this week sarub writes in saying hi rob and jason i recently started
listening to your podcast i'm a 32 year old and never programmed in C++, but I'm looking forward to starting this journey
and was wondering if you could suggest a name of the book that I can use to start learning C++.
And Jason, we were talking about this for a minute before we got on the air.
Obviously, like Scott Myers books are all great, but those aren't necessarily intro
level.
Yeah. I'm thinking maybe the Bjarne Stroustrup books.
Yeah, I think if you don't have any programming experience at all, he has a Programming Principles in Practice using C++.
That's an intro to programming book.
But if you do have programming experience and just no C++ experience, a tour of C++ from Bjarne Stroustrup should be a good option.
Right. And not to put our guest on the spot, but before we introduce him,
he has actually been the author of a book himself.
Ankit, do you think your book would be a good one for a beginner to C++?
Oh, well, it's been many years.
I would say no.
I would stick with the ones that you guys mentioned.
Just being honest.
Okay, that's fair.
It is an intro book, though, but it's really an intro book for someone who's learning to learn.
But some of the concepts now, I think it even covers ODBC and stuff, which might not be around anymore.
So, you know, I would stick with the ones that you mentioned.
Okay.
Well, we'd love to hear your thoughts about the show as well.
You can always reach out to us on Facebook, Twitter,
or email us at feedback at cppcast.com.
And don't forget to leave us reviews on iTunes.
So joining us today, again, is Ankit Asthana.
Ankit is a program manager working on the Visual C++ cross-platform space. He is knowledgeable in cross-platform technologies,
compilers, dynamic and static compilation,
optimizer, code generation,
distributed computing, and server-side development.
He has in the past worked for IBM and Oracle
as a developer building Java 7 and telecommunication products.
Ankit, back in 2008, also published a book on C++
titled C++ for Beginners to Masters,
which sold over a few thousand copies.
Ankit, welcome to the show.
Thank you for having me again here.
Love to chat with you guys again, Rob and Jason.
So, you know, let's get started, I guess.
Yeah, it's great to have you back.
I noticed you've been at Microsoft, IBM, and Oracle.
That's pretty much the three biggest technology companies in the world.
I think I've been lucky, to be honest, to have the opportunity to work in these three firms.
And I think the culture, you'll find surprisingly, is very different in all these three companies.
I think at IBM, I was working in Canada and Toronto, and I was really working as part of this research lab. And it was my first job out of school, and I learned a lot of stuff there.
I mean, most of the stuff there, you know, you do is you used to do this mainframe programming for Java where you're kind of like working on System Z.
So there's no debuggers or, you know, things that you just people assume exist on other platforms.
It was an interesting experience there.
Oracle is very different.
You know, making application software is a lot easier than writing compiler code.
And then Microsoft, I think I started in a program management role.
And, you know, I guess I'm still learning what that means.
But, you know, I think, you know, one thing I do enjoy is working in a strong team where you're, you know, working with people who are really, really strong in the C++ community and so on.
So that's one part I love about my job.
Cool.
Very cool.
Okay, so we had a couple articles to discuss and some of these come from
your team's blog.
This first one is
STL fixes in the
VS 2015 update 2.
This is another
very long, very detailed article
coming from STL about
all the improvements that are going into update 2 for the standard template library on Visual C++.
Is there anything to highlight in here, Ankit, that you wanted to point out?
I think, to be honest, I had a chat with STL just a couple of minutes back.
I think he said the best transfer I can give is to point people to his blog post.
There's just so much in there that, you know,
different people will find different, you know, stuff there that they would like.
But, I mean, I think as you can see, like, you know,
our focus in update two has been fixing a lot of performance fixes,
functional fixes, adding new feature support, and so on.
So I think I would just look to the blog post for that one.
I wouldn't do justice to it by mentioning anyone here.
Okay, that's fair enough.
I feel like if you really dig into this article,
it's like a case study in why you should always prefer
the standard library from your vendor
and not try to roll your own.
Because it's astounding how many little details there are in here.
Yeah, I mean, I think SGL does a great job in maintaining this list.
I have no idea how he does it and finds time for it,
but I would point people to this blog.
And it's really a case study, you're right.
Yeah, that's a really good point.
The next one, Jason, I thought this would be a good article for you,
is about runtime compiled C++.
Apparently this article was released a couple years ago, but now it was released in a Game AI Pro magazine, but now it's available for free on the web.
Yeah, it's a long article. I definitely did not read everything in here.
But it's about being able to use C++ as a scripting language, right?
Yeah, to be able to make changes to your C++
and have the changes be immediately reflected in the code.
They have a couple of demo videos that I believe I actually watched
when those videos were first released a couple of years ago,
and it's nuts.
It's amazing what you can do.
Yeah, and this technique, it says, is being used by Crytek and the Unreal Engine,
so it's being used in very high-end AAA games.
Yeah, it's been around for a few years, so I'm sure it's proven.
And I also saw the news that they had just released this article to the public.
It's amazing stuff.
Yeah, I think if I might say a few words on this one,
I think we've heard this a number of times,
especially for AAA, who have these big codebases,
that edit, build, debug is really only a part of the problem.
It's also really about edit, build, debug, and deploy.
So when you're deploying a binary over to an Xbox console
or a PlayStation console,
the bigger their app is, the more time it takes to deploy.
So these kind of techniques where you kind of like do your asset management in a different way,
it almost gives you approaches for, you know, faster editable debug deploy cycle there.
So this is really an interesting case.
I would love to see how it can apply to some other, you know, scenarios as well.
I mean, you know, this hard deploy mechanism.
But I think most of the gaming companies that I've talked to probably use this technique.
I mean, I'm not sure if they're mentioned in the article here,
but they've all mentioned similar techniques for this kind of a solution for the problem that they're facing.
And I think, like, if you look at the Android ecosystem itself, I mean, Android APKs itself,
they allow this constant OBB file, which is, again, kind of, like, suited for this kind of a scenario
where you can really package your assets, you know, separately, independent
of the APK itself, the Android application package itself, which allows you similar kind
of behavior that they're talking about how to deploy.
So I think it's a good feature for us, too.
I mean, you know, I want to look into it and see if anything we can do to make that integration,
you know, more versatile for even a non-gaming scenario.
Do you know how it compares to edit and continue kind of features?
So the thing with edit and continue, so there's a few ways you can do this.
So let's say that you basically take a piece of code and you create a DLL from it.
And then what you can do is you can basically say, you know, you can delay load the DLL on demand.
So let's say that your binary is already deployed on a particular machine and it's running and your game is running.
And the DLL is getting loaded at runtime.
So what you can do is that you can go make a change in that DLL and then just redeploy the DLL portion.
And then your game would automatically pick up the new version of the DLL and continue from there.
So that's one technique that is very useful.
The problem with edit and continue is that
essentially anything that
requires linkage, like if you're adding
a new global variable
or you're
adding a new header
or any of that kind of stuff, which basically requires
linkage, you can't really do that
in edit and continue because edit and continue is really
about small changes
whose side effects are not escaping the scope of that function, or the scope is pretty much local from
that perspective. As soon as you start making changes like the ones I mentioned, edit and continue is
going to stop working. Whereas in this case, when you're really kind of like, you know, repatching
your DLL on the fly, you can make all kinds of changes there. So I think that's one of the big
advantages you have over an approach like
ENC here, or even like patch and continue or fix and continue that,
or zero link that Apple Xcode used to have in the past.
So that's my two-minute answer.
But I think, you know,
these guys obviously would know more in the article and so on,
but that's what I would say on a high level at least.
We still have yet to get someone from the AAA game industry
we really need to work on that Jason
just so many topics I'd like to bring up
I don't have any contacts in that industry
this last article I wanted to bring up
is on Dependency Walker
which used to be a pretty useful tool
for analyzing a Windows application
and seeing what DLLs it's looking for. And if your program isn't running or is having some type of
error on startup, it could be useful to figuring out maybe what you're missing. But as this article
talks about, the tool hasn't really been useful. It hasn't been updated since 2005.
It's talking about these API sets, which are
a fairly new feature on Windows. I guess they got introduced back in
Vista. Dependency Walker just hasn't kept up with them.
Because of that, it hasn't really been too useful since that was
introduced. Ankit, I'm curious, do you guys use anything like this internally?
Anything like dependency Walker?
You know, I'm not very knowledgeable in that space,
so I don't know the answer to that question.
But yeah, I mean, I read through the article though,
because you pointed to it, but I mean,
I couldn't find much that I could probably add value to from what I can tell you, I guess.
Okay.
Yeah, it's just a shame that the tool doesn't do much anymore.
And, unfortunately, this article kind of goes into why, you know, what the problems are that dependency walker runs into these days,
but it doesn't really give you any usable workarounds or point to any alternative tools. Yeah. Well, you know, I think it's the article actually kind of caught me off guard
because I didn't realize that dependency Walker had been abandoned since 2005. Cause I've actually
used it in the last year to debug DLL loading issues on windows for an app as helping with
deployment. Yeah. I've used it recently as well.
I guess maybe I've gotten used to just kind of filtering out
all this stuff that it claims are missing dependencies.
Yeah, you just ignore that bit and focus on the DLL
that you're actually looking for.
Like, hey, why is it linking to the 64-bit version
on the 32-bit build or whatever?
Yeah.
Okay, so Ankit, we want to talk about all the new features that have been coming out of your team at Microsoft lately.
We just had the Build conference.
I was able to go last year, but I didn't make it out this year.
But there were a lot of announcements that came out and several from the Visual C++ and Visual Studio teams.
Where do you think would be a good place to start today?
Yeah, I think, like, I mean, you know,
build is kind of like the time of the year where we try to, like, you know, make maximum impact
in terms of new ideas and features
and what we're going to be working on,
get feedback from customers, yourself, and so on.
So I think at build this year,
there's a lot of stuff that we've done
with Visual C++ product, you know,
the 2015 product and the updates and what we're planning for the next version of Visual Studio.
But I think I'll go back to highlight some themes that are consistent.
So the first theme for C++ that we're really trying to aim towards is cross-platform.
So we want to – C++ at a basic level is among the only two languages that have historically been cross-platforming.
C++ is supported on the Mac, Linux.
It's supported on the Windows platform.
When you talk about the mobile technology, it's the same case there for Android, iOS.
So I think we're trying to really understand scenarios for that cross-platform C++ user
and then be able to, you know, provide him
a good solution for his development experience, whether that be Visual Studio or any other
product offering that might be in the Visual Studio family of products, like Visual Studio
Code.
I think the second theme that I think we're really big about is that, you know, we've
got a lot of feedback from, you know, the core Visual Studio perspective is really about
the, you know, how heavy Visual Studio has become for a user.
I mean, you know, I think from a Visual Studio installer perspective, if you start there, you know,
historically that's an event that people have to plan for.
It's not something, you know, it's not something, to be honest, it's not something that, you know, is a 10-minute thing.
The updates are likewise the same.
I mean, you know, we have gigs of stuff that's happening from an update perspective.
So the problem that we're trying to solve is a complex one,
which is to, you know, provide all the value that Visual Studio provides to a developer,
but then package it differently in a manner that is not only cohesive,
but also much, much faster and streamlined.
So you can really start getting development as soon as you can without waiting, you without waiting that much amount of time to get things set up and so on.
So the acquisition is one thing that we're focusing on.
So we had a demo about that.
If you try out VS 15 preview, you can try that preview experience and so on.
That's going on so far.
So I think acquisition, cross-platform,
and then really productivity is something else
that we're touching on, right?
So for productivity, I mean, we talked about edit and continue,
which is really a debugging slash diagnostic feature.
That's something that we've now reshipped,
and it's about, you know, it supports x64 platform as well,
which was not the case before.
We also had the opportunity to redo
the x86 stuff because over a period
of time, it became really buggy.
We've done other stuff there
from a productivity point of view where
we have this experimental offering for
language services that gives you
some cool refactoring features like
extract function and whatnot.
So these are some of the things that we've done.
So a lot of stuff in the cross-platform space,
a lot of stuff in the productivity space,
a lot of stuff in the improving the acquisition
and performance of our tools itself,
whether that might be the build throughput of our tools,
making our tools build faster, the linker, the compiler,
or that be the IntelliSense engine, you know,
being able to load and create the database that's required
for populating IntelliSense and so on much faster.
So that's really kind of like the top-level view.
I don't know if that gives you guys an idea or not, though.
Sure.
So I guess let's start digging into some of these in a little bit more detail.
So one of the things that came out of Build last year was VS Code,
which is a new editor that kind of competes in the same space as Sublime Text.
It's a little more stripped down.
And I guess at the time it was mostly kind of aimed at JavaScript developers.
Is that a fair assessment?
Yeah, that's right.
I mean, I think the beachhead there are the ones that they really want to go after.
I mean, this is really an experiment that we started, the Visual Studio Code effort,
and we started with that Node.js web-based developer
to see how that actually scales out for them.
If you notice the Node.js guys and JavaScript guys,
these guys are not really your traditional IDE fans.
They don't really use traditional IDs.
They use more like Chrome tools,
or a solution like VS Code we thought was the best fit for the job for them.
So that's really where we started.
But now if we take a look at Visual Studio Code, there's an article recently that we released on Visual Studio Code blog
where Visual Studio Code went 1.0.
And I think we have like close to, if you add everything together,
I think we have close to a million downloads there for the product itself.
And in this extension and this version of Visual Studio Code for C++,
like why do you care?
Earlier, Visual Studio Code only had support for, you know,
it provides text-based bundles,
which provide basic colorization for different set of languages.
But it doesn't go any more deeper than that.
So if you're talking about, you know,
being able to use VS Code from an editor point of view,
it doesn't go into being able to provide you features for code navigation like guru definition
or guru any particular symbol, final references.
It doesn't provide you any IntelliSense or code completion tricks, which are specific to the language and so on.
So that's all the stuff that we've basically done, you know,
in this extension that we're shipping.
So in this extension that we're shipping for C++,
we added support for language services.
It's not complete.
You know, we only did a basic set of,
we only enabled a very, very basic stuff here.
So what you can do is you can navigate to a symbol.
You can go to a definition.
You can go to a declaration and so on. But we don't really have any semantic analysis in it yet.
So features like IntelliSense or accurate final references, these will not work currently.
But our team is working really hard to kind of like make these features work, you know, across
the board. And the good thing about VS Code is that it doesn't matter whether you're natively
on Windows or Linux or Mac, it's just going to work out of the box for you. And the good thing about VS Code is that it doesn't matter whether you're natively on Windows or Linux or Mac,
it's just going to work out of the box for you.
And the other thing there I might also add there for VS Code
is that VS Code is really after the editable debug loop.
So while Sublime and some of the other tools that are there
are really, really, really good code editors,
what VS Code also provides you is a debugging experience.
And one thing that we noticed during our call downs
and our interview research is that, especially on the Linux platform, debugging was something that was not
at the same par that, you know, Apple provides with Xcode or Visual Studio provides, you know,
on a Windows perspective. So that's something else that this extension enables. It enables
debugging for your Linux C++ applications. You can do breakpoints. You can do multi-thread debugging.
You can do core dump debugging.
You can actually go ahead and attach to a running process and so on.
It currently builds on top of the GDB layer, GDB engine.
But essentially, that's something else that we've added support for
with this extension there.
So like with editing and debugging,
we currently have limitations in terms of distros that we support for Linux for the debugging
experience. But that's something, again, that we're working on enabling, that it works across
all Linux distros, Mac, and then Windows as well. So do you have an idea what that timeline is for
getting it working on Windows? I'm kind of curious about that. Yeah, I think the Windows one is
actually a very interesting question for us.
The fact that currently we rely on the GDB engine,
which is the debug engine that we're relying on for VS Code,
it provides us the ability to be able to debug binaries on Linux, Mac, and Windows.
But for the Windows perspective,
so when you take a look at the Windows technology,
I mean, there's a variety of compilers that you have.
So you have the C1, C2, Microsoft C++ compilers.
Then we also have the Intel compiler.
We also have MinGW and now Clang LLV on Windows as well.
When it comes to Clang LLV on Windows and GDB on Windows,
with MinGW and so on,
the thing is, while they support the
Windows object file format, which is COFF,
they don't support the
debug format for Microsoft
technology, which is PDB. They produce a
DOR file there. So what we're looking
for in Windows is really enabling support for
COFF and DOR, which is going to enable debugging
for, you know,
Clang on Windows
and GCC on Windows. And a priority for debugging has been Linux first, then Mac, Clang on Windows and GCC on Windows.
And our priority for debugging has been Linux first,
then Mac, and then Windows.
And our thought process on Windows PDB debugging
is that currently is that
because we already have Visual Studio Community,
we might, you know, focus on that as a debugging solution
for Windows PDB solutions and so on.
Interesting.
Yeah, I mean, that's a working assumption.
So, I mean, you know, I think Linux and Mac is the priority that we have.
You know, Linux first, then Mac.
And Mac, as you guys know, you know,
Clang and Librium toolchain is the default toolchain that Xcode comes with,
which means that the debug engine there is actually different.
It's LLDB.
So it's going to be GDB on Linux, number one priority for us from debugging.
LLDB, you knowB based debugging on the Mac, and then Dorf and CoF debugging for Clang LLDB on Windows and GCC on Windows as the third on the list that we have right now.
Is it safe to assume that once you have LLDB working on a Mac, you would be able to use that on Linux? I mean, I think, like, the thing that's tricky,
and I might not be an expert here,
is that Clang LLVM on Mac actually is a little bit different than Clang LLVM that you go download when you go to LLVM.org.
Yes.
And the reason that's the case is because Apple actually adds
a lot of secret sauce there in terms of tooling.
Like, for example, they have these tools called LiPo,
which allows you to create a FAT binary,
like a FAT static binary. That's
platform agnostic at that point of view.
And other tools there, they do
a lot of work in also improving the runtime
optimizations that you do on
the Clang LLDB on Mac. So the quality
of LLDB
on Mac versus the quality
of LLDB on Linux, I think there
is a difference there.
And while, you know, it should work,
LDB should work on Windows as well for Clang,
on Linux as well for the Clang tool set,
what's going to be the, you know,
the variance in experience for Mac versus Linux,
I think only time will tell.
Okay.
I don't know if that helps, but, I mean,
I mean, we're learning, too.
This is new stuff for Microsoft as well. And, you know, we're learning too. This is new stuff for Microsoft as well.
And, you know, we're new in this space.
So we're learning as well.
And, you know, the feedback that people are providing is great.
Just out of curiosity, are most Linux C++ developers using LDB or GDB?
Jason, do you have any idea?
I would say probably most are using GDB today with a shift towards LDB.
Okay.
I think some people would argue LDB gives you a better console experience
because they've put more work into that.
Yeah, I think we've heard exactly the same thing.
I think the trend is towards doing LDB and moving towards LDB,
but I think it hasn't completely happened yet.
I think if you look at the latest announcement for Android community,
they recently moved their default compiler for the Android NDK,
which is a C++ development kit, from GCC to Clang,
but it's a slow move, I think.
And for some scenarios like IoT, I don't even think Clang and LDB
is a scenario there so far.
Yeah, and it's tricky for me and my clients
because it used to be that Clang gave a clear, faster,
the builds completed faster, the compiler was faster,
and GCC produced faster executables,
and that it's always in flux as to which one you're going to choose
depending on what the needs are for your project.
I'd like to interrupt the discussion for just a moment to bring you a word from our sponsors. It's always in flux as to which one you're going to choose, depending on what the needs are for your project. CLion natively supports C and C++, including C++11 standard, libc++, and boost.
You can instantly navigate to a symbol's declaration or usages too.
And whenever you use CLion's code refactorings, you can be sure your changes are applied safely throughout the whole codebase.
Perform unit testing with ease as CLion integrates with Google Test, one of the most popular C++ testing frameworks,
and install one of the dozens of plugins like Vim Emulation Mode or Go Language Support. Download the trial version and learn
more at jb.gg slash cppcast dash cline. So Ankit, you just brought up Android, and that was the main
topic we were discussing when I had you on the show a year ago, cross-platform C++ development on Android. And I believe at that time, there was no iOS support
at all yet, but what's kind of the current state of things? I know a lot has been added, right?
Yeah, I think for, I mean, I think it goes back to the vision that we have. And I think the vision
that we have for Visual Studio and Visual Studio Code is that, you know, no matter what kind of steep up the score you're writing, whether you're
working natively on Linux, Mac, or Windows, or you're targeting, cross-compiling, remotely compiling
your code for Linux, Mac, Windows, iOS, Android, you know, Roku, or whatever the platform systems
are and OSs are, we really want you to use Visual Studio,
and we really want to make Visual Studio
the best possible solution out there.
And with that kind of goal in mind,
we've continued to invest in all these offerings there.
So the offering that you see on Android now
is much better improved because we added support for,
you know, we added support for the Gradle build system.
We also added support for lightweight Java code editing.
So Visual Studio also gives you Java IntelliSense
and Java building capabilities for Android
because that's common for you to have
with your large C++ code base in Android,
you know, in the case of, like, Facebook Moments or Dropbox
or wherever these apps are,
you still have some amount of Java code there,
whether that's, you know, for, you know,
attaching your code piece to a Twitter SDK or Facebook SDK.
So we've done a lot of work on Android and adding support for Gradle, new NDKs,
ability to be able to reference Java libraries, build Java libraries, Java code editing,
and that's just Android alone.
On the iOS front, we've done a lot of work now in order to enable further experiences where you can go ahead and now not only be able to edit, build, debug your app,
but you have other scenarios.
For example, you can take an existing Xcode project,
and you can come into Visual Studio and import that project into Visual Studio.
This is a new feature that we haven't really publicized it too much yet,
but we plan on doing that very, very soon.
And that's really a scenario that's really cool because, you know,
you're an Xcode, you don't really want to, you know, for some people,
like especially in the gaming industry who are already using, you know,
Visual Studio for targeting AAA, PS4, Xbox, Windows Desktop, and so on.
They don't want to basically, you know, maintain multiple IDs.
And for those kind of scenarios, it's really easy for you to be able to import
existing expert project into Visual Studio and get it to build.
We also have support for iOS-specific capabilities like frameworks
and dynamic libraries, which will release a pop as a part of iOS 8.
So there's a lot of feature work that we've done on the cross-platform space
to be able to build for Android and iOS.
And I think this might be a good place
to also talk about our latest offering from Visual Studio.
So while Visual Studio Code remains the solution for you
to user experience for C++
when you're natively on Linux and Mac,
we also added a story this year at Build
where you can remotely compile
and target Linux desktop IoT Raspberry from Visual Studio.
So that's something else that we added as a part of the build release that's new.
Further going into the road plan that we have for making Visual Studio the cross-platform IDE for C++.
That's really cool.
So I am curious, what is kind of the target audience
for that new feature,
being able to develop on Windows
in Visual Studio and debug
and deploy to some type of Linux environment?
Because, you know,
I'm more of a Windows Visual Studio guy,
but I know if I was tasked
to do something on Linux,
whether it be a Raspberry Pi or a Linux server,
that would be an attractive feature to me that I wouldn't have to actually go on and kind of relearn everything in Linux.
But am I kind of the target audience or are you kind of targeting all Linux developers?
I think it goes about what you're mentioning Rob here, I think like
if you look at our experience right now
what's really happened is that on Linux
it's hard to tell
what a developer is using, he could be using
Vim, he could be using Emacs, he could be
using
CodeBlocks or CodeLite or
CLion or any other product there, we don't have a
great consensus in terms of
platform IDE for C++ on Linux.
I mean, on Apple, most likely, you know, people are using Xcode
or most likely on Windows, people are using Visual Studio for C++.
That's what we hear at least today.
But essentially, on Linux, there's no consistency there.
So what we've seen is a lot of people who were targeting Linux,
especially people who were going from Windows to Linux,
they struggled, you know, in terms of being able to debug their app because while GDB is a very powerful debug who were targeting Linux, especially people who were going from Windows to Linux. They struggled in terms of being able to debug
their app. Because while GDB is a very powerful debug
engine and so on, they don't have the same kind of UI layer on top.
The presentation layer doesn't exist for them to provide them
a very usable experience there. So we've seen a lot of people
in the gaming industry, even heavy enterprises
who basically created their own solutions for cross-compiling
their app, their Linux desktop app from Windows using Visual Studio or just homegrown scripts
to be able to do that.
So that's really the target audience that we have in mind, that if you want to stick
around in Windows because you're targeting multiple platforms in Windows via Visual Studio,
that being mobile or console or HoloLens or whatever, and you want to stick around and
maintain one IDE,
then you can actually go about using a Linux experience there.
And then the IoT experience, well, IoT, you know,
layover line is still shaping up,
and it's becoming, you know, popular.
It's hot to be in the IoT portion of the code base and so on. So that's something else that this extension really enables you to do
for Raspberry Pi and so on.
It kind of feels like these two different paths
seem a little contradictory,
that you guys are providing both Visual Studio Code
for native development on Linux
with a native debugging experience
and the remote build and debugging experience
from Visual Studio.
Yeah, I think it goes back to what the strategy is
for Microsoft.
I think we need to maybe work better
on our language perspective there
and how we're messaging this.
But it goes back to, I think,
what Satya was talking about recently
at a conference saying,
any dev, any app, any OS.
So it's really about us meeting people
where they're at
and not about making stuff
where we want them to meet us at.
So, for example, we've seen use cases
where people don't want to leave Linux because that's really where they've, you know, learned,
and that's their primary development platform.
And for those people, if you go to them and we tell them that,
okay, you guys, you know, look, we have this in Visual Studio,
but hang on for a second, you have to shift OSs to Windows,
that's not very appealing to that portion of the audience.
So if you're in that bucket, you know, then you can kind of like use VS Code,
which will give you the same, not exactly the same experience,
but a similar experience for, you know, code editing and debugging.
And if you're natively on Windows and you're already a Visual Studio user,
then it gives you the advantage of being able to cross-compile
or remotely compile for Linux and so on.
So it's really like we think of these scenarios as complementary,
which allows us to meet people with what they're comfortable with,
whether that be Linux or whether that be Windows.
And I think if it's not very clear,
then we obviously need to go back and work on our messaging there
to be able to make that clear to our customers, I think.
I don't know if that helps, Jason,
for you to understand where we're coming from. And I don't know if that helps, Jason, for you
to understand where we're coming from.
I don't know if you agree or if you have a viewpoint
there. I don't
really have a viewpoint. It just seems like
that you are duplicating your effort
in some ways, so I was curious.
I see.
Again, I think it's just about
meeting where people are at.
So I think we think that the majority of the people are natively on Linux,
and there's a small portion of people also on Windows who want to cross-compile or remotely compile their code base for Linux.
So we want to help both these scenarios there. That's really our intent.
Backing up a little bit, I just had one question about the Android development scenarios you were talking about.
It's great that you added the
Java support, and I was curious,
you said there's some Java debugging
support. Do you have
the ability to debug from
the Java layer through JNI
into C++, or is it kind of
a pick-one-at-a-time
situation?
We don't currently have
the experiences that you have to pick up
front, whether you're debugging your Java, C++,
or C++. We don't yet have mixed mode debugging
enabled.
And I think
I don't think in the Android
world anybody provides that experience yet,
but that's definitely something that is
an attractive feature
set, especially for game developers and so on.
So can you officially say that's on the roadmap?
No, I cannot officially say that.
Okay.
I think, as I mentioned, that we are trying to create the best experience for multiple experiences there.
And I think we are learning as well here, I mean, you know, especially targeting
Android and iOS is a learning experience for us
because these are inherently not our
platforms. I mean, you know, there's a platform IDE,
Android Studio for Android, and there's
Xcode for iOS. So we're learning there too.
But, you know,
this feature has been up for discussion,
but we don't have any role plan yet for Mixed Mode
debugging yet. That would be pretty amazing.
I would agree.
And what about the
same situation in the
Objective-C iPhone side?
Is there debugging support for Objective-C?
We yet
don't have much support for Objective-C
but we do
have this one feature and I'll talk about it for
a second. So what also we enable with
Visual Studio now is a co-development experience with Xcode. So what you can do is that not only can
you import your existing Xcode project into Visual Studio, we also have a story where you can right
click on the solution and the project and say open in Xcode. What's that going to do is that's
going to open up your Visual Studio project back into Xcode. You can make a bunch of changes there,
and then you can basically go back to VS and say pull from Xcode, which is going to open up your Visual Studio project back into Xcode. You can make a bunch of changes there, and then you can basically go back to VS and say, pull from Xcode, which is going to take all the
changes that you made in Xcode and make that work in Visual Studio. So for scenarios like storyboarding,
where you want to go do a, you know, like UI design, or you want to really use Xcode instruments,
or if you want to debug Objective-C code, you know, you can use that feature for now. And the round-robin is something that we guarantee
in terms of operational capability
that's going to work for you
when you're working in Visual Studio
and pairing that with Xcode and so on.
Wow.
Yeah, that sounds really powerful.
So it keeps your Visual Studio solution
and your Xcode project file completely in sync?
Yeah, I think, I mean, it's still in preview,
which is why we haven't talked about
it, you know, like very extensively.
But that's what it does. What it does really is that
let's say that you went into, you created
an iOS project in Xcode, and
I don't know, I mean, it does something there.
Let's, just for simplicity's sakes,
let's say that it's some kind of an open
CV, CPath Plus app. You go back,
you know, you can use your importer to
import that project into Visual Studio.
You know, we'll provide you a great
experience with C++. Chances
are that if you're targeting iOS, you're likely to target
also Android, because, you know,
these days, mobile apps at least target those two platforms.
So we provide you a great experience for both
iOS and Android there in VS for your C++
portion. Now, if you want to go
back and make changes to your storyboarding,
or if you want to go use heap analyzer for Xcode, you can do open in Xcode,
you can add new source files, you can change a piece of code, you can
make changes to storyboarding, and then you can pull those changes back in VS and start building
and so on. So that's something that we've enabled. It's in the product right now with update 2 already.
We're working on further improving that experience and making it more robust.
But that's what we're doing. Internally, we're trying to build apps that are, you know,
Microsoft apps like Minecraft and other apps for iOS using this solution. And I think once
we're ready, we're going to really create a splash about that.
So you answered a question that I was already thinking of, at least I think you answered
it. These features are all in the current visual studio 2015 update 2
you're not talking about visual studio 15 preview that was just released last month
no everything that i've talked about here is already in the product and update 2
okay or at least should have been there so if it's not there and you guys find
you should go back and find someone here but yeah so uh on that note actually let's talk a little
bit about what's going to be changing
in the new visual studio version that jason just mentioned which is visual studio uh 15 in quotes
um and the one thing you brought up a little bit already was how the install acquisition experience
is going to be improved in that new version that's yeah. The acquisition is a main pillar for us to improve. So, I mean,
I think you'll see that, you know,
you'll see that it takes
forever to install Visual Studio, whether that's an update
or, you know, installing VS from scratch.
So I think that's one thing that we really want
to hit on from a perspective of
being able to attack.
The other thing that we're going to hit on is
really about this experience about any code,
which really is about the fact that if you take a look at the C++ land of things,
or C Sharp for that matter, you might be coming in with a different build system.
You might be coming in from a build system that is not MSBuild.
So I think, like, for those kind of scenarios today, the only, you know,
the only approach that you have for using VS for your editing and building experience is a change in religion and a change in faith.
And I think what we're saying there now is that we don't want a change in faith.
You can come with existing build technology, whether that's whatever tooling you might have, Ninja or, you know, Make or, you know, Scones or Ant or Gradle, whatever solution you're having.
And we're saying that, or CMake for that matter, and we're saying that we're going to provide you a way
to still be able to leverage the capability of Visual Studio
to be able to provide you a language service experience
with IntelliSense and so on,
a build experience for building your app,
and then also a debug experience to be able to do that.
So that's something else that we're trying to do.
We're trying to open up the technologies
and the power of Visual Studio
that lies in productivity of Visual Studio and so on to more developers who are not using the entire stack of Microsoft technology.
So I think that's something else that, you know, that we're doing.
And the last thing we're doing is really about improving the performance of Visual Studio all up.
So what does that mean?
It means everything.
It means, you know, improving the throughput of our tools. The linker in 2015, for example,
is on average about two to three times faster. The IntelliSense, when you're
loading up your project, the symbols that we go and parse
and we put in the database for being able to give you things like go to definition
or go to declaration, those kind of things we've done a lot of work on, replacing the database
with SQLite
or improving large-scale solution performance there
for our productivity feature set.
So these kind of things are what we're going to be hinting on,
performance, acquisition,
and then being applicable to a wider set of developers
for C++ and C Sharp and so on,
all the other support languages that we have.
So those are kind of the three pillars that we're going to go after.
All right, I am going to dig down into something completely
in the weeds here for a second,
but you just said that you're replacing the symbol table in Visual Studio
with one that is SQLite database.
Is that right?
Yeah, I think if you take a look at the latest blog posts that we have,
we basically done a bunch of work in improving the performance
of our language service engine.
The way it works is I load a folder with C++ code,
our tag parser goes and starts parsing these symbols
and starts loading them up in the database.
And then that drives all these code navigation features,
which then go and search in the database. Every time you say
like, oh, go find me
the usage of this particular type,
then we go to the database and we basically
say that, okay, these are all the occurs of these types.
Then our semantic analysis engine works
on top of it to figure out whether this is
a comment or this is a function name or
a constructor name or a class name,
and so on. So we've really worked on improving the
performance of our database engine there.
We moved to a SQL live-based solution there in update two.
You can see that.
That's really aimed for improving performance of IntelliSense
for large code bases and for code navigation
in large code bases and so on.
So is the schema for that database published
so that users can access it directly if they were so inclined?
I am sure it's not.
I think, like, I mean, if you look at the blogs,
I can definitely, you know, hopefully point you guys to there.
The blog post was called Neo Improved and Faster Database Engine.
And we published this blog post back in November.
And what you'll see here is that there's a video here on this chat which shows you how
it's an eight-second video, I believe, where you can really see how you can
speed up solutions, like how this improved database engine experience that we're providing
is going to speed up your solution parsing time. And you don't lose any information
or the correctness that features like
guru definition
and final references give you with these new database changes.
Okay.
So the big team is really about, you know,
VS 15 is really about improving acquisition,
performance of our tools,
and then being able to be applicable for more seniors and so on.
That's really what we're going to focus on is our best bet.
And I'm sure you probably don't have an answer for this,
but do you have any idea what the timeline is going to be
for VS 15 coming out?
I actually don't know.
We're hoping...
I actually don't know.
Usually, if you have a preview version,
then roughly six, seven months is when
the RTM product comes out
that also depends on marketing and all that kind of stuff so i wouldn't i wouldn't uh comment on
that one i guess okay so maybe late 2016 but you definitely can't give us any sort of thing i
actually don't know myself so he's not just holding out on us that's fine. So going back to Build,
you did four talks this year,
right? Now, do these four talks
that you did kind of go over all the topics we've
been bringing up today? Yeah, I think
it's actually a good point. I think one of the
things that we've seen for Visual Studio, the
first talk that we had was called
Top Six Reasons to Move to VS 2015.
And the funny part,
though, is that in the audience that we had, about 60 or 80% of them were already to VS 2015. And the funny part, though, is that in the audience that we had,
about 60 or 80% of them
were already using VS 2015.
But I can tell you that's not the case
for all our C++ users.
A lot of them are still using 2013 or 2010 and so on.
So this is really focused on,
the talk is really focused about,
you know, what are some of the new things for 2015
that should drive your attention?
And the big things there were really about, you know, what are some of the new things for 2015 that should drive your attention? And the big things there were really about, you know, build throughput.
So, you know, the link is much faster.
We have a faster code gen, which basically produces faster code.
Things like vectorization catches more patterns.
The global optimizer has been improved to, you know, add more support for different optimizations.
ARM32 optimizations have been improved and so on.
From a security perspective, we have two new features for you. We have
slash guard, which allows you to write. It does basically
what Java calls area out of bounds exception check, and it also does a check
on things like when you're trying to make an indirect virtual call,
it goes to the virtual function table
and makes sure that the offset that's being provided from your code base
is something that's within the range of that VFT table and so on.
It's really about writing more secure code.
That's a runtime checker?
It's a runtime checker, yeah.
So basically what happens is that, like, you build with this particular flag,
and what we do is we emit extra instructions.
The compiler will do that, which go and check and make sure that's happening.
So there's a bunch of zero-day issues that different products,
I can't name here on the call, have seen where buffer overflow
or area out of bounds have caused security loopholes in the product.
So this is the stuff that you can use for being able to protect your
instruction stream and so on.
And that's meant to go into deployed code, not
just in debug? No, in the deployed
code, yeah. Oh, interesting, okay.
It's going to go in whatever you're shipping,
the binary that you're shipping with.
So, like, de-virtualization,
for example, virtualization
in C++ is
a problem point because people can go and find the right
place and add an offset that's beyond the offset table in the virtual function table and so on.
Same thing for error-to-balance exception. I mean, you can go and create a pointer,
point to a memory location, and go beyond the range for that particular array and so on.
Different languages, like as I said for Java,
they actually secretly emit extra instructions,
for example, for area out of bounds and so on,
which basically help avoid these kind of security loopholes
that C++ just has inherently.
The advantage that C++ obviously gets is that it's more performant
because you're running a lesser or smaller instruction path length.
So security is something,
and there's new security features there in 2015.
From a diagnostic point of view, we have edit and continue.
We have a new memory profiler that's been shipping in 2015 as well.
From a cross-platform perspective,
we have support for targeting Android, iOS, and now Linux.
From a conformance perspective,
there's a skew of features there that we're working on.
There's new stuff on static analysis there.
So the talk really goes into and touches in detail
these kind of experiences there.
And hopefully, you know, at least one of those reasons
will be something that people really care about
and are passionate about that will help them
understand what value 2015 brings in.
So that's just the first talk.
The other three talks that we really had was basically a demo, and it's a part of the tips
and tricks talk for VS Code where we demo the extension itself.
It shows off the language service features we have on the Ubuntu Mac Linux box that we have that I kind of created for the demo.
It goes into all the C++ features that the extension provides.
And the last talk is really about, it's really a talk show with some of the Xamarin guys and Cordova guys.
It just kind of compares different technologies or languages, Xamarin, Cordova, React Native, C++ for writing a mobile app and so on.
Wow.
Okay.
Sounds like an interesting talk, kind of doing a comparison of kind of the advantages of the different strategies.
Yeah.
I mean, you know, I think like, I mean, we've seen, I mean, you know, people come from various, it really depends.
Like when you're writing a mobile app, it depends upon where you're coming from.
If you're coming from a web-first world, you know, Apache Cordova might be a great solution for you.
But if you're coming from an enterprise world and you're building an app like Alaska Airlines,
where performance of the app is maybe not so much needed,
but you just want to create a cross-platform solution, Xamarin might be a great approach.
If you're looking into writing an app, which you have a lot of CPAP plus code
that you want to reuse
or you're writing a new game,
CPAP plus might be the way for you there
because it's going to be cross-platforming.
You're guaranteed performance and so on.
So it kind of just touches a few examples,
some drawbacks,
some advantages of each of these technologies
and so on.
Okay.
Well, I will find all links for those
and put them in the show notes
if anyone wants to find more
about what we talked about today.
And Ankit, where can people find you online?
That's a great question, actually.
I think I'm still learning
on how these different channels work.
I'm young at age,
but old at heart, it seems.
So I think I'm still learning how, but all that hard it seems.
I think I'm still learning how
Twitter and all these other channels work, but I think
the best place would be
I think VC Blog,
where I try to answer most
questions and all that. You won't believe me,
but the first time when someone told me about Twitter,
I was like, okay, how much does it cost for a tweet?
And the guy said, yeah, it'd be for a while.
So if that gives you an idea.
I'm still learning how all this new social stuff works.
Okay.
Well, it's been great having you on the show today.
No, it's a pleasure again, and great job for you guys.
I mean, as I said earlier in the show,
that I do follow a lot of the other episodes there as well,
coming from different folks from the JetBrains community or the Clang community and so on.
So that's great.
Yeah, thanks for joining us.
Cool. Thank you.
Thank you.
Thanks so much for listening 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 that also.
You can email all your thoughts to feedback at cppcast.com.
I'd also appreciate if you can follow CppCast on Twitter and like CppCast on Facebook.
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.