CppCast - Rider for Unreal Engine

Episode Date: May 28, 2020

Rob and Jason are joined by Anastasia Kazakova. They first discuss news from Herb Sutter that the November ISO meeting has been postponed and a new Visual Studio preview release. Then they talk to Anastasia Kazakova from JetBrains about Rider for Unreal Engine and other updates to CLion and ReSharper for C++ as well as information about the C++ ecosystem. News MAME Emulation Project VS 2019 16.7 Preview 1 New York ISO C++ meeting is postponed Visual Leak Detector Links Rider for Unreal Engine Blog posts with FAQ and some details on Rider for UE CLion turns 5, birthday tale from Phil Nash CLion Makefiles prototype JetBrains turned 20, main news Sponsors Use code JetBrainsForCppCast during checkout at JetBrains.com for a 25% discount

Thank you. C++, a smart extension from Visual Studio. Exclusively for CppCast, JetBrains is offering a 25% discount on yearly individual licenses on both of these C++ tools, which applies to new purchases and renewals alike. Use the coupon code JETBRAINS for CppCast during checkout at JetBrains.com to take advantage of this deal. In this episode, we discuss some Visual Studio update and ISO news. Then we talk to Anastasia Kozakova from JetBrains. Anastasia talks to us about a new IDE for Unreal++ developers by C++ developers. I'm your host, Rob Irving, joined by my co-host, Jason Turner.

Jason, how are you doing today? I'm all right, Rob. How are you doing? Doing okay. Just another day, man. As one of my friends recently put it, it's the 78th of March right now. Yeah, that's a good way to describe it. I can't believe that we're almost in June already. The past two months have felt long, but they've also kind of gone by rather quick yeah yeah time almost june tomorrow's my anniversary 20 years well happy anniversary to you and jen thank you all right well at the top of our episode i'd like to read a piece of feedback we got this email from

punkage and i probably apologize if i messed up your name but says uh hi robin jason i'm a big fan of cpp castast and C++ Weekly. I never miss out on any of your episodes. I really liked your previous episode with Martin as he gave some perspective about catch from the maintainer's perspective. Is it possible to have an episode on emulation programming with C++? I am sure it will be an interesting episode

as Jason has already worked on a bunch of them by now. Keep up the good work. Did we? Was MAME, is that an episode we did have an epilator yes yes maims uh with um mio drug yes yes um and also i don't want people to like people seem to think oh well jason's clearly done a bunch of these things. I've written like half of an emulator. Your cousin's written a couple in various languages. In various languages, yes. But I think he's only done like one NES emulator in C++, and that was using techniques 20 years ago. So that's probably not a good example either.

I've been thinking about who I might reach out to since you shared this feedback with me, Rob. We'll see. Maybe we do another recap or rerun or something like that. Well, this the main episode, I just looked it up and that was September,

2016. So that was pretty long time ago. Yeah. I think it was right before my first CppCon. Oh, yeah. Yeah, that sounds right. That might be right. Well, definitely check that episode, Pankaj.

But, yeah, maybe we will look into doing another episode on emulators. Okay. Well, we'd love to hear your thoughts about the show. You can always reach out to us on Facebook, Twitter, or email us at feedback at cpcast.com. And don't forget to leave us a review on iTunes or subscribe on YouTube. Joining us today is Anastasia Kazakova. As a C and C++ software developer, Anastasia created real-time Unix and Linux-based systems and pushed them to production for eight years.

She worked as an intern in Microsoft Research Networking Department and launched the first 4G network in Russia, being a part of the Yoda operator team. She has a passion for networking algorithms and embedded programming and believes in good tooling. With our love for C++, she is now the product marketing manager on the JetBrains C++ tools and.NET marketing teams. Besides, Anastasia runs a C++ user group in St. Petersburg, Russia. Anastasia, welcome back to the show. Yeah, it's great to be back. What is this? I don't think I've ever heard anything about this, you working on the

first 4g network in russia yeah that was before jet brains i was working in yota they are the 4g operators in russia actually the first 4g operator in russia and i joined them exactly the time they were driving the forge in russia and we were building the whole network and I was doing the software which helps with all these concussions in the networks like users policy setting the proper channels to them and the proper policy based on various factors so we did a software system which actually triggers all the stuff so it was fun like we were really launching the first 4G network in Russia and there were so many funny stories around that when we were playing and cheating a little bit to show some demos. That was fun.

And, you know, that was a real-time system. So when you have to sometimes come to work at night to fix something crashing somewhere in the other part of the country, which, you know, is quite big, I mean, like 12 time zones. And if something crashes there during the day, you might be having a night here in St. Petersburg. But no one cares. You have to fix it. Wow.

But at least the people would like to get access to the internet, so it better come and fix. So I remember I was coming to the office and debugging some Gdb cores falling at nights fun time like you know developer fun time now i'm curious and i'm is it the same in russia like i would expect in most countries in the rural areas people rely on 4g or whatever for their uh internet access i think now yes like when started, there was just a very beginning of the 4G in Russia. Like we were the pioneers there.

So, but right now, yeah. Like I'm using 4G everywhere. I'm relying on it quite often. So yeah, I think now it's the time for 4G and 5G coming. So that time that was the very beginning. It was very interesting. Right. Yeah, I bet.

Cool. Okay. Well, An bet. Cool. Okay. Well, Anastasia, we've got a couple news articles to discuss. Feel free to comment on these, and we'll start talking more about the latest from JetBrains, okay? Sure. All right. So this first article I have is the Visual Studio 2019 16.7 preview.

And this linked article is going over everything in the new visual studio version so you know changes to xaml and wpf and dot net um there were a couple things specific to c++ and that's that they added uh debugging support for cmake projects on remote servers with gdb server and they also added address sanitizer support, which we talked about a couple of times. This is adding the support for x64, which is great because they only had x86 before, which I would imagine not many people are still using.

Yeah. And if you're like me, you're sitting here reading this and you're going like, I did not realize that it was like C sharp and XAML and C++ mixed together. I'm just like, man, that's some weird looking C++ mixed together. I'm just like, man, that's some weird-looking C++. Who has this iComparable?

It's like my brain was not working. Yeah, there's a lot of other stuff going on there which might not be relevant to many of our listeners, but some good stuff. Yeah, but I would say it's still a very impressive list. I mean, like, lots of changes, like, interesting at least to everyone. Like, I was reading for it not only from the C++ perspective,

since I'm also working with the.NET team right now. I was reading for it very carefully, I would say, in terms of.NET as well. But C++ parts, like, only two of them, but I think they both are quite significant. I mean, like, the remote experience nowadays is, like, essential for many people. So having an ability to debug on remotely

with the GDB server or whatever, you organize that is very important. And sanitizers, I mean, like Windows users are always suffering from like missing any kind of memory leaks detector or something like that. Like, because the most, like, the biggest tooling here is for Linux and for Mac, I guess, like Valgrind or address sanitizers from Google.

But the Windows are usually staying in the corner, lonely. Yeah, there's Dr. Memory that's supposed to work on Windows, but I've never actually gotten it to work, so I don't have anything to say about it. Yeah, exactly. I did a talk at CppCon where i was discussing the various profilers and sanitizers and when i mentioned the doctor memory and asked who is using it like i mean everyone knew about it but there were not so many people actually using it i don't know going on there yeah one of the other um non-ceple

changes that's listed here which i guess is kind of a general visual studio improvement is uh this playlist for tests which i thought was kind of a neat idea so if you want to just run certain unit tests based on you know the code you're actively working on you could create a playlist so it only runs those tests kind of a neat idea i could see that being potentially useful. Although I must admit at this point, because I use ReSharper, C++ and Visual Studio, I don't know what testing features come from Visual Studio and which ones come from ReSharper. I think we still have to check if we work nicely with the playlists. Yeah, that's probably a good idea yeah okay uh next thing we have is an article from

herb sutter's blog and this is a you know pretty big announcement we already know that the varna meeting that was supposed to be in what that's supposed to be four days four days yeah um that's been postponed and they are now officially postponing the november meeting which was supposed to take place in New York. And it sounds like this was not necessarily the C++ committee's decision on its own, but that the larger ISO body said no one can have any meetings. Is that right? For the rest of this year?

I think so. I think it was mentioned that U.S. national bodies agreed not to admit in person. Okay, right. So yeah, no more in-person ISO C++ meetings for the rest of this year. There is one planned for February. Hopefully that one will be able to be held in Kona. And as we talked about last week, they are trying to do a lot with their online meetings, and hopefully they can continue to make good progress that way. Yeah i just want to say from the slightly uh cynical side of me

why are we calling these meetings postponed they're canceled right that's a good question yeah or moved online but right anyhow i mean i doubt we're going to have twice as many ISO meetings in 2021 if things open up. Yeah. Like every other month they're going to be flying to another country? Yeah, I don't think so. They already do that anyhow between conferences and meetings. Yeah, that's a good point. Maybe if you do twice more work at one, you can count it as two.

Right. Or have twice as many people there and count it as two meetings, maybe. Yeah, maybe. Well, I'm still planning to go to Kona, whether or not there's a standards meeting there in February. I'm just saying that. Hopefully everything's somewhat back to normal by then. Hopefully. Yeah. Hopefully.

Okay. And then this last article is Visual Leak Detector, which as you'll see from this article, it hasn't been updated in a couple years. But it was built against or last tested against Visual C++ 2015. But I've actually been using it a little bit myself the past few days, and it seems to work fine with my project using Visual Studio 2019, and it's pretty handy for finding memory leaks

with Visual C++, I think. Well, since you're the one who's using it right now, Rob, why don't you give us an overview of what it's like to use this tool? You're basically just including a header, and you need to modify your include and library paths to include the lib file that comes with the tool. So it's like one of these things that hooks into Mellick or something,

so it knows what was... Yeah, I believe so. And then you basically just run your app. Your app will run a bit slower and then shut it down and you get a huge or maybe hopefully not huge log in your output window telling you all leaks including you know source and file and line number of where it detected that the object was allocated that wasn't leaked.

So pretty handy. So you've had success with it this last week or so? Yeah. Cool. Okay. So Anastasia, you have a couple new things to announce, right? Do you want to start off by telling us about Rider for Unreal Engine? Yeah, sure.

We just recently launched an early preview for the thing we call Rider for Unreal Engine? Yeah, sure. We just recently launched an early preview for the thing we call Rider for Unreal Engine. So let's start with a joke. We like doing tools for C++. We have a couple in the family, so we just decided to do another one. But jokes aside, seriously, Rider for Unreal Engine is a standalone IDE

for creating your games with Unreal Engine, an fantastic and very popular engine in the game dev world. And it brings the native C++ support, and it also integrates with Unreal Editor and brings a few features specifically for Unreal Engine developers. So there is a very short link you can use. You can go to jb.gg slash Unreal, and it will redirect you to the preview. So the preview means that the version is free for now. You have just

to sign in. There is a kind of long form, but we'd like just to know more about how you're going to use the tool and what kind of game development you do. So if you sign in, you'll immediately get a license from us, and you'll get a link to the build and you can start immediately with the tool. So for now, it's Windows only. So we plan to expand to other platforms. So we plan to be cross-platform with this. And I hope that before the first release,

we'll go to Mac and Linux, hopefully this year. So for now, it's Windows only. It now works with just a solution file. so you can open the simple solution you usually use in Visual Studio just in Rider and start with it immediately. Actually in the future we plan to support native project model, Uproject, so you don't have to even generate solution in Unreal Engine project model there. So if you go to this page like I've shared,

you can see actually the overview video, which is kind of 15 minutes, but it's a nice overview of the capabilities of the tool for now. So those who did the, or those who do the Unreal Engine development with Visual Studio and ReSharper C++ actually will find a lot of known features

because the features for Unreal Engine are actually coming from ReSharper C++ actually will find a lot of known features because the features for Unreal Engine are actually coming from a sharper C++ language engine. There is a lot of nice features for particular support for Unreal Engine like reflection macros because the Unreal Engine they're using the reflection based on macros

approach because the C++ still doesn't have a proper reflection mechanism like building. They're using the macros and these macros are actually a nightmare because before you go to Unreal Header tool and build them actually and generate the whole stuff, your idea will know

nothing about what's going on there. It will be simple text and quite often the thing I was actually disappointed with was when we started with the tool I was trying to go through some tutorials on Unreal Engine development. And I often see Visual Studio with a red code there. And when I see official tutorial from AVA Games with a red code in the IDE, like my heart breaks, I just can't see this.

And that mostly was because of the reflection there, because there's just a pure tax for the ID unless it starts doing something deeper with it, unless it starts to parse it somehow, like run the Unreal header or two, or parse it in its own manner. So we do this parsing on our side. So we parse the macros.

We understand these reflection specifiers. So we provide the completion code documentation for them. We know that this comes out of this reflection mechanism, actually. And there is this thing like remote procedure calls we also support and lots of integration that we're actually doing. So that was like a long path to the tool, but I'm really happy with what we actually showed as a public preview. And we are collaborating with the Epic Games team.

So they actually tried the tool before the public announcement. And even the Fortnite team sent us some good reviews and very good and useful feedback, actually, on what they would like to improve there. So we're really grateful to the Epic team for the collaboration, for their help. Because there's not much happening about the detailed documentation and how to integrate with the Unreal Editor, but they were really helpful, and they were helping us with some pull requests. So actually, the writer for Unreal Engine is a default. You can use it as a default editor,

starting from 4.25 Unreal Engine version. So before that, you have to install a plugin separately, which is now in the marketplace. But with 4.25, you can just start using it right away from the Unreal Editor. So it's very simple and very straightforward. So yeah, that was like a good path. Very cool. Well, I think you may have answered a couple of my first questions about just,

you know, I'm not a game developer, never touched Unreal Engine, but I was kind of curious as to why, you know, I'm not a game developer, never, never touched Unreal Engine, but I was kind of curious as to why, you know, a custom IDE might be necessary as opposed to just using, you know, Visual Studio or CLion. But it sounds like these custom reflection macros is the main reason. There is actually a kind of like long story, because like most of the people in the game dev, they're truly using the pure Visual Studio, I suppose, because the game dev is somehow occupied by the Windows ecosystem a lot. So most of the people there are on the Windows platform. And naturally, they're using Visual Studio as a default editor, which often integrates as a default editor into the engines. I mean, the Unity and Unreal Engine,

they all go with Visual Studio as a default. But as I tell you, the experience when you're using the Visual Studio might not be nice if you're not doing the general C++ parts, which are fine, but if you go to more specific Unreal Engine code, then you can do actually a lot, and you can do much better there,

I mean, in terms of the language support and the smart editor support, so all the things we try to do. And also, we would like to integrate deeper with the Unreal Editor and Visual Studio while it helps to install some things and it has some kind of integration, but it's not that deep.

So for example, in Writer for Unreal, we finally managed to have the blueprints on board. This is a binary format, actually, which stores a lot of information. And if you, for example, have some class in your C++ and you inherit this class in the blueprints, you know nothing about it

in the regular C++ editor. But in Writer for Unreal, you will see the derived classes in your blueprints and you can click and navigate to the blueprints. And also for properties, you said in your C++ code,

if you, for example, update the value in the Unreal Editor and save, the value will be updated in a special hint in the writer form real. So you will see these values in the actual editor. This is really, really helpful. And it was actually a challenging task because that's a binary format without any proper documentation, I guess. But it's interesting to us. We like this kind of things in JetBrains.

We like dealing with code in this way because we realize that there is a lot of work happening in the blueprints. The games are usually going with both blueprints and C++, and it's nice if we can help people to see what's going on in their blueprints while they're just doing their C++ editing. And I would say that people are using the Visual Studio. Quite often they're using Visual Studio with Visual Assist. They also do kind of nice work for Unreal Engine specifically. So they have some very similar features in terms of reflection support.

They don't do any kind of deep integration with Unreal Editor itself because it's just an extension for Visual Studio. You can guess, probably don't need it in Visual Studio. So we wanted actually to go forward with that. So yeah, and if we come to our tools, I mean, C-Line, like that's a very popular question after we actually launched Rider for Unreal, like why we're not doing this in C-Line

because you can guess like we do C-Line as our general purpose cross-platform C and C++ IDE, and we're targeting it as our main offer for C++ developers, and it still is. But when we come to game dev, we don't want to overload CLion with all the specifics from the game dev,

because the target audience for CLion is a lot of general cross-platform projects, it's finances, it's embedded development we're now digging deeper and like artificial intelligence, native development not only with C++ but with Rust and more. So bringing game dev there would be challenging and maybe will'll overload the tool a lot. And from the other side, we already have Rider, which you might know as a C-sharp IDE. If you've ever heard of, like, you do some C-sharp development

or heard something about it, Rider is a cross-platform C-sharp IDE. And quite a big part of its audience is Unity. And, like, Unity developers, they're coming from various game dev studios. And guess what what when we started talking to them we realized that many of them are actually doing both

Unreal Engine and Unity they're switching between the engines between the projects they're doing both and it's natural to them so not that they're focused around one engine in particular and they told us that it would be nice if they don't have to switch the IDE like working with the Unity project or working with us that it would be nice if they don't have to switch the ID.

Working with the Unity project or working with the Unreal project would be nice to have the same ID just to short the learning curve because otherwise you'll have to learn two tools. And we decided that since we've already done a lot in terms of the integration with Unity and providing

high quality Unity support and integrations there, why not just to do the same for Unreal Engine? And the only thing we needed there was actually to bring the C++ support into Rider. That's also simple because Rider is like a child of two parents, IntelliJ IDEA and ReSharper. It's IntelliJ IDEA UI and front-end, and back-end is coming from ReSharper so for the Rider so-called Rider protocol so we just plugged in the ReSharper C++ support into Rider and we got everything ready so that was kind of easy and it also actually eliminated lots of performance

problems because you know Visual Studio when we run ReSharper C++ Visual Studio, we're running into the 32-bit process of the Visual Studio. So we're still not out of process there. There is some work around it. But still, the 32-bit process for C++ is definitely not enough, especially if we're talking about a real engine, a huge engine with a huge C++ code base. So Writer actually eliminates this problem a lot

because it's a separate tool. It's like separate processes. We do everything on our own. We can control a lot of things there, how we index the things and whatever we do there. So we did a couple of performance optimizations there, like postponing the indexing for the Unreal Engine itself so that you can actually start coding your game immediately.

Just open and start it, and we'll index the engine in the background, and you can control if you would like to additionally index some plugins, whatever. So all these performance optimizations are actually working nicely, and we already got lots of feedback from our early previewers that they feel the performance difference comparing to Visual Studio, for example. I meant your Visual Studio or Visual Studio with C Sharp or C++. So that was like one of the goals. So I know virtually nothing about this game development world for modern game dev, but I thought

Unity, you could develop an either C++ or C Sharp for Unity. Is that... Unity, you could develop in either C++ or C Sharp for Unity. Is that? Unity, while you develop for Unity, you mostly do the C Sharp scripting. Unity itself is written in C++, but I don't think many people there actually contribute to Unity or doing something around it. They mostly just do the C Sharp scripting.

Moreover, when you talk to Unity game developers, they're usually not naming themselves as the C Sharp scripting. Moreover, when you talk to Unity game developers, they're usually not naming themselves as the C Sharp developers. They're usually saying that they're Unity scripting developers. So that's a completely different world for them. That's funny, actually. But yeah, so mostly it's C Sharp.

There are some scripting languages in addition to that, but it's C Sharp mostly. Unreal Engine, you do the development in C++ and also like these blueprints things and i guess there are some possibilities for like python and some other scripting languages but that that's not that popular okay i was just wondering if the the uh unity developers would also see some benefit from from this writer getting unreal support in some way because the c++ integration but it sounds like you're probably not i think they will because many of them are

not just unity developers many unity developers in the game studios are also on real engine right because like today you're doing a project on unity the next day you're doing the project like in a real engine that's quite often i mean like for sure there are studios who are focused around one engine but quite many little studios are focused around many so there's something else you said and i'm i'm pretty curious about this from the c lion and c++ development perspective you said that you're using the resharper c++ plugin in Rider for your Unreal support. Is that what you said? Okay. Yeah, like we use it as a language engine.

So we use it as a backend via the Rider protocol to provide a C++ support in Rider. That's true. I think something that we've talked about in years past when we've had you on the show is that ReSharper and CLion have different code bases so they don't have quite the same exact features. Are we going to see any of this flowing back over into CLion or the other way

now that you're like, oh, sure, it was easy. We just used the ReSharper C++ engine in IntelliJ. That's what you said. Good question, actually. It was not that easy because the writer itself was actually not ready for that because we're already using ReSharper as a backend for the main writer. So in that sense, using ReSharper C++ was kind of easy task. But we're also using actually C-Line there, I would say,

because when you do the development, you obviously need a debugger. And if you're in Visual Studio, you probably understand that you have a debugger from Visual Studio. But it's a proprietary software. You can't use it in Rider. It's prohibited. So we checked a couple of options there and did some prototypes and finally end up with the LDB-based debugger for Visual Studio C++. This is actually the same debugger we're currently also using in C-Line for Microsoft Toolchain. And it's also a debugger in Rider for Unreal Engine to debug your Unreal Engine games.

And the back end is an LDB base. So it's our own fork based on LDB. And the front end is actually coming from C-Line because we already have an integration with the LDB in C-Line. So we just cut this piece from CLine and put it into Rider. Actually, this usually makes us private reviewers

a little bit surprised when we're trying to explain them where to report the issues. Because some goes to ReSharper C++, some goes to Rider, and some actually goes to CLine, but still. So we're reusing the C-Line parts in Rider right now in terms of the debugger,

where we're reusing the debugger back in C-Line for Visual Studio C++ toolchain, and actually we do some internal experiments for using ReSharper C++ language engine via the same protocol in C-Line. And you know that in C-Line there is not only

our own Java-based, Kotlin-based language engine, but also there is a Clang-D-based language engine now. So also working for some kind of a protocol. So it's also our own fork, or the Clang-D, and we try to move as many features in the editor as possible right now to this Clang-D-based language engine. So it's capable of a lot of things right now. And so we'll see how it goes, so which works better.

So maybe we'll still need to compare how it works. I mean, ReSharper C++ vs. Clang-D-based engine, maybe we'll keep both. Maybe we'll do some enhancement in that sense. So in the future, we might get the same Unreal Engine language features supporting CLion as well. No one is limiting us from that. Technically, it's possible.

Just if we decide that that makes sense in terms of the targeting of the tool and overloading the tool with some extra functionality. But for now, we see Rider as an ultimate game dev IDE, and CLion is just the main c++ offer so and if there are benefits in turning plug-in the resharper c++ engine into c-line will definitely do that if not then then won't so that's the story okay is the c++ support in rider like completely limited to just the unreal engine development because I know I work on a mixed C Sharp and C++ project

I use Visual Studio and go between both languages often but there's some developers on my team who really only work on the C Sharp and they actually prefer Rider and I'm wondering if they could use Rider for both if they wanted to. Actually they can so the

story is that we didn't cut anything from the language engine for C++ when we plugged it into Rider. So generally, the same language features will be available. So you can just open your solution file and do some general C++ development in Rider. And that's the proper thing to try right now because you can open the solution in CLI and CLI doesn't support solution project model, Microsoft project model. But you have to realize that right now

we're focused on Rider for game dev. So we're not prioritizing the issues coming from the general C++ support. And especially in terms of the debugger because the debugger is like a big piece of it and you can guess that it's a hard work to implement a proper debugger nearly from scratch even though it's based on ldb so we handled like the unreal engine stuff there more or less nicely for the preview but there is a lot of

things that which have to be focused before it's actually usable for the journal c++ things especially the and like native visualizers for the standard library++ things, especially the native visualizers for the standard library. All these things are currently missing there. So in general, yeah, you can use it as a general C++ tool and it will work for you nicely, I guess. But there might be some issues.

So just feel free to report them. Nice. I've just been curious, like listening to you talk about how the game developers use these things. And I'm thinking in your role at JetBrains, you have at least dabbled in probably pretty much anything

that C++ developers do. Is that fair? So I'm guessing you've actually pulled up the game dev engines and have worked with them and seen what these things look like. So you know how to use all the tools at the very least. I don't know. I'm just curious, like, your experience and breadth of experience is probably wider than most people, for sure. Just as maybe not the depth necessarily on these topics, but the breadth for sure. Just curious, like if there's anything

that stands out to you, surprises you as C++ developers or something you've learned recently that you found interesting. I actually learned a lot around the game development in terms of C++ because when we started the tool,

we didn't have that many actual game developers in the team. Then we hired a few who actually helped us with many, many aspects of the game dev and after that i actually like reverted a little bit myself back and turned to some cpp con talks from the game developers from game developer companies trying to understand what they are actually doing with the c++ because before that i was not that interested in that i was mostly skipping these kind of talks. But after that, I actually spent a lot of time there digging into how do they use the language,

so how they overcome, how they deal with the reflection, because it was surprising to see that Unreal Engine, the Ruby and Popular Engine, are actually basing their reflection mechanism on macros. I was like, what the hell are you doing? Why? But I found out that there are not so many options, you know, like because some people are using Python generation,

some other things there, but you need to have reflection somehow. And like macros was probably the easiest working solution for them. And because of that, for sure, you have like lots of issues. Like there are these things called remote protocol calls, RPCs, are remote procedure calls. And in Unreal Engine, you just put some kind of reflection macro before it to show that it's actually RPC. And there are some characteristics you put as a reflection specifier,

like you put something with validation. And after that, you get a function generated with this suffix with validation. And after that, you get a function generated with this suffix with validation. And your code navigation in the editor actually have to understand that this is the same function. You have to navigate there. And the usual C++ editor doesn't know anything about it. It doesn't know that this function with this name is actually connected with this function

with the same name with some other suffix. And you have to put it to the like language engine that yeah if you see this reflection specifier this piece of text here you have to understand that you have to navigate to this function you have to refactor it properly so when you rename the original function you have to rename all this with validation functions as well so So it was so interesting to dig into this to see how it works, how the whole system is organized around that, and how they overcome actually all these issues we still have in the language, I mean, the recent reflection mechanism. Also, it was very interesting to see how they work with the memory.

I mean, like that the array is probably the best structure for all the game developers with the memory. I mean, like, that the array is probably the best structure for all the game developers in the world. I mean, like, they're usually tuning these structures on their own. I read a lot about ESTL. I mean, like, how they work with their own STL there because they can't use the regular STL libraries. So it was very interesting. I mean, when I jumped into it, I was surprised a lot, and

I learned how they try to actually optimize the language, which is already good for low latency tasks, even better for the game development. And all this, like, working with memory and reflection stuff was very, very interesting. So I think I learned a lot, and

I'm still learning a lot about them. What C++ standard did you find that the people who were responding to you are using? Most of them were saying something about C++ 11 and 14, but recently when we did the ecosystem research, we found out that C++ 17 is very popular, especially in game dev. And I guess when the reflection comes to the language, they will be upgrading as well. But the story there is complicated.

They can't just upgrade because they like the language. They have to wait for the SDK providers, for those who do the consoles, those who do the hardware and provide the SDK for them, for Xbox, for PS4, for Switch, just to update the SDKs as well well to use the new standard so it's not that easy switch for a newer language just because they want so they still have to integrate a lot of stuff into their code so and that's actually another complicated side of the whole

game dev development because that's not only about your game or even your game and their game engine it's also about a huge piece of software from those who provide the hardware right well since you just mentioned mentioned the uh ecosystem survey uh is that going to be coming out soon are there any interesting uh highlights in that new one uh yeah i can sure share a few so we're actually gonna publish it i guess somewhere in the beginning of june so uh we do it i guess since 2017 so building and some kind of an ecosystem research across all the languages and technologies uh we we do support uh since 2017 in order to understand how the ecosystem looks like because we work in this ecosystem, we are a part of this ecosystem,

we would like to understand what the things are going on there. So there is a very interesting story regarding this ecosystem research because we put lots of effort into it. We have a big team behind it and we try to limit the bias a lot. We do translate the survey into six languages and have lots of weighting and special promise in order to limit the bias from the English-speaking countries, from like United States,

who usually fill in these kind of surveys when they are in English. So we do validate the results, for example, for C++ against the Foundation survey. And it's very similar, but we see this bias coming from, for example, English-speaking people or the audience specific to C++ foundation because it's very professional there. I mean, there is a bias to those who do C++ for more than six or ten years for the foundation survey. So this year, I guess we collected 19,000 responses in the whole for the foundation survey. So this year, I guess we collected 19,000 responses in the whole for the whole ecosystem. And it's about 2K comment to C++.

So it's very similar to what C++ foundation got this year. So I already compared some numbers with them. And it's like 42% of the C++ audience are professionals and 40% are students. And there are these like, you probably know that the biggest top areas for C++ are embedded games and financial development. And we see these areas with the percents

in the ecosystem survey, in the research, in the data we got. And we even sliced by these areas for the final results. So to see some differences between the areas. So this all will be available in some kind of infographics quite soon. So we're already preparing the final landing pages and the raw data will be coming also a little bit later after the infographics will be released so that you can actually do your own slices and check the data so the interesting facts i found this year is that we regularly asked about the c++ standards and we see like uh 12 percent of the respondents answering that they're using c++ 20 already which is great great, I think. And like 41% comes to C++17,

which is also great. So I really like how the figures are changing like across the years. So for sure, we sliced this for embedded finances and games. And as I said, I was surprised because I actually saw 51% for C++17 in games area.

So it's really a lot. So it's bigger than in comparison, for example, to financial area or embedded for sure is like on C++11 and C++14 mostly. They're kind of behind in that sense. We also asked people if they plan to move to another C++ standard in the next year. And while half of the respondents, they replied that they do not plan to move, but the other half, they are planning to move. And when you're coming closer to C++ 17,

there are more people who would like to upgrade definitely to C++ 20. So it's actually good to see that many people are finally going to upgrade themselves during US standard. It's actually a good move. For sure, we do ask about the tooling. Like we're very much interested in how we're doing in terms of the tooling in the ecosystem. So there are data for like top IDs, editors. So there is like Visual Studio CLan and Visual Studio Code in the top three and we also slice this as well for embedded financial

development and games and for sure in games, obviously as I said, it's mostly the Windows stories and Visual Studio tools are very popular there, so Visual Studio is like the top popular editor with the highest percent compared to other areas. And we hope to see Rider for Unreal Engine in this list one day. We also asked about the unit testing framework.

It was actually glad to share some good news with Phil because the cache actually acquires like 14% due to our data on the second place after the Google test. And it's great because it's actually growing, I would say. It's very popular right now in the community. And it's good to see it's that high, actually. So there is also some information about the dependency managers. So we see that half of the respondents,

they don't use anything specific to manage their dependencies, and like 23% they rely on system package managers, but the others, they are trying to use some other options like NuGet or VC package or Conan. VC package and Conan are growing, and that's kind of obvious thing we were expecting, but it's still interesting to see the kind of transformation. Like the top for the project models, it stayed and changed for many years already.

It's CMake, Visual Studio Project, and Makefiles in that order. CMake actually went to the first place a couple of years ago and stays there for maybe two or three years already in a row. And again, we sliced all these questions by embedded financial and game development areas. So in the final infographics, you can actually check these slices as well. So yeah, an interesting fact that I actually noticed there,

and that's not the first year I'm noticing it, that when we asked about which tools for like guidelines or code quality you regularly use most of the people i i mean like right now it's something around 36 they say that they are using the tool provided by their id i mean nothing specifically but just the tool from their IDE, which means that we have to be responsible for what the people are using as a tooling vendor because whatever we provide, they will be using.

Otherwise, they won't use these kind of tools at all. So we're kind of responsible for the cloud quality in the ecosystem. So yeah, that's just the general overview. So we hope to release the infographics in a couple of weeks, probably. I'm not sure about the final day. It's still, because we're localizing the results.

So we're still in the, I guess, the localization step. So after it gets localized, we'll publish it and it will be available. And sometime after, we're going to publish the raw data as well. So everyone actually, it's free to're going to publish the raw data as well so everyone actually it's free to everyone so grab the raw data and do their own slice so yeah that's

very cool well are there any major features of C-Lion or ReSharper that are worth going over because it's been a while since we had you on yeah actually you know this year is actually big for us in terms of the company and C++ tools

because the company turned 20 and C-Line and ReSharper C++ turned five this year. So this April we were celebrating. Actually, we did record a very nice video for C-Line celebration. Phil Nash is actually telling some kind of a story there. And he also actually did the music for the video. So it's not only the voiceover, it's also Phil's music there.

So just go and see the video. It's really nice. I really like it. And we also did some kind of interviews with the team for Wish Arpacy++. So just trying to find out how they feel about the five years in production. And if we talk about what's going on there in terms of the features, in terms of directions for the tools, so if we take the resharp for C++, so as you know, we do the engine on our own, I mean, the language engine, so we're very much focused on C++ 20 right now, trying

to provide as much support for the language as we can. Like, I mean, something not just in the, like, parsing and highlighting the things, but trying to create some interesting code analysis checks. And, of course, the game dev, which is the major part of the ReSharper C++ right now. So for their improvements for Unreal Engine support, we just published some very initial support for HLSL.

This is the shader language, so some kind of C++-based shaders. So we did provide the HLSL support in ReSharper C++ 2020.1, and we plan to improve it further, and we plan to work on some Unity shader support as well. So this will probably come into the main writer as well and the third direction for a sharp principles plus is definitely

performance so it's still there no magic so we still have to do a lot in terms of performance there uh if we talk about the c line there are kind of more paths there so we did a lot for remote work which is kind of like, you know, trending these days, we all stay at home, we all work somehow remotely. So all the remote modes are very popular in C-Line. And we do a lot to improve the performance to general quality, add some new possibilities there and new options there. Also, we kind of started with Embedded in CLion. So we did a few things to support STM42.

We supported the platformer frameworks. So we added some compiler support for IR, for CUDA dialect, currently discussing the possibilities to add CUDA and IR debuggers to CLion to see if we can integrate them.

So there are a lot of stuff happening there in the embedded area. I think we're lacking the team members to implement all the ideas a lot. Because, you know, the area is huge and I really feel a very big passion for it because I'm myself an embedded developer and I really like what's going on there. All these peripheral views and playing with boards, all this stuff, it's really impressive. So, like, simply speaking, you can just take C-Line right now

and debug on some regular chip, like Arduino, for example, and debug on it and, like, upload some code there, like, do some interesting stuff on this board. So, also, we started the prototype for Makefiles, code there, do some interesting stuff on this board. Also, we started the prototype for Makefiles, I think a kind of top-voted feature for Ceylon for many years, but it's

a little bit harder than we heard because the Makefiles are very diverse. I mean, there are lots of things we can do with the Makefiles. So we implemented some kind of a prototype. We shared a blog post and suggested everyone to jump in for the private preview i got quite many emails i would say from people who would like to try our prototype on their own projects and they did and like half of

the experiments went okay half of them actually failed because they were using some uh like tools which are actually spoiling the compiler output and were actually reading the compiler output to understand what's going on in the project. So we're actually running some comments to understand what's going on there. So makefiles is actually one of the biggest directions for us. And also all this stuff around the Clang-D based engine.

As I said, we ported a lot of things to the ClangD. So we had the code completion running in the ClangD-only mode right now, and we're moving various code analysis checks. We just moved the data flow analysis to ClangD, and some navigation partially works for the ClangD as well. So lots of things there. And we even did some very nice experiment.

We collaborated with the offer of the concepts in Clang and we actually merged with the SARS branch before the CBPCon last year. And we pushed that to the public build of C-Line so that everyone could actually try some features built on top of the ClangD like the support from concept coming from

SAR and our own implementation of some specific features for the concepts in C-Line. So when SAR actually demoed this at CppCon so he did some nice demo of the C-Line's feature in the end of his concept talk. This was kind of experiment because the concepts at this time

were not in the Clang master. So we just merged the private branch, like not the private, but the very specific branch of concepts from SAR into our main language engine. So this is the things we can actually do. So we liked the experiments. There were some complications and some tricks there, but we like how it actually went.

So yeah, we're doing a lot of things in terms of language support here, like as you've heard, experimenting with 3Sharp C++ as well. Not sure how it goes further, but at least we'll have some experiments here as well. So yeah, these are the probably main directions for CLang right now. But we have so many things happening right now around us in the company. I'm sometimes surprised because we published this report for the company turned 20. And if you just scroll through it, you can notice so many things happening. We launched the public preview for space, which is an integrated team environment we do.

We launched our own typeface for developers called Monospace. We launched a bunch of educational initiatives and we started several new offices. So there are so many things happening in JetBrains these days. Wow. Yeah, you have offices in many countries and cities right now, don't you? Yeah, like it's, I guess, three offices in Russia, Novosibirsk, Moscow, and St. Petersburg.

The St. Petersburg one is a new one, so we just moved to a bigger office a year ago. Munich office, which is also planned to move to a new building quite soon, I guess, after all these stories with the coronavirus finishes finally. We also opened a new office in Amsterdam, which is a new office for us. And yeah, like our headquarter is still in Prague in Czech Republic. And yeah, like a couple of offices, mostly for the sales team,

but also some developers are in United States and Boston, and sales are in New Jersey and like somewhere in San Francisco, I guess. So, yeah, I guess quite many offices. I haven't been to all of them yet. Okay. Well, it's been great having you on the show again, Anastasia. Anything else you wanted to plug or anything before we let you go? No, I just would like to say thank you

for having me back. It was fun. I like it. It's actually great to share so many news around our tools. I like talking about our tools, but also I like to dig into some new things like Game Dev, and it was a great thing to share some news we have for Game Dev

and Unreal Engine stuff. Awesome. Thanks. Yeah, thanks. Thanks so much for listening in as we chat about C++. We'd love to hear what you think of the podcast. Please let us know if we're discussing the stuff you're interested in, or if you have a suggestion for a topic, we'd love to hear

about that too. You can email all your thoughts to feedback at cppcast.com. We'd also appreciate if you can like CppCast on Facebook and follow CppCast on Twitter. You can also follow me at Rob W. Irving and Jason at Lefticus on Twitter. We'd also like to thank all our patrons who help support the show through Patreon. If you'd like to support us on Patreon, you can do so at patreon.com slash cppcast. 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 was provided by podcastthemes.com.