CppCast - Compiler Explorer Revisited

Episode Date: February 23, 2024

Patrick Quist joins Phil and Timur. Patrick chats with us about their work on the Compiler Explorer team and how they got into it. We explore some useful features that may not be as widely known, and take a peek under the hood at how it all runs. News "C++ Package Managers: The Ultimate Roundup" - blog post by Christopher McArthur "Demystifying Lakos Rule via Visualization and How It Could Relate to Constexpr" blog post by Miro Palmu "A Year of C++ Improvements in Visual Studio, VS Code, and vcpkg" - blog post by Sy Brand NVidia interview question - Reddit thread Links History of Delphi Compiler Explorer Also Compiler Explorer Compiler Explorer Public Dashboard (live stats)

Episode 377 of CppCast with guest Patrick Quist, recorded 16th of February 2024. This episode is sponsored by Sona, the home of clean code. In this episode, we talk about package managers, the LACOS rule, and about an interesting C++ interview question. Then, we are joined by Patrick Quist. Patrick talks to us about how Compiler Explorer works under the hood. Welcome to episode 377 of CppCast, the first podcast for C++ developers by C++ developers.

I'm your host, Timo Dummler, joined by my co-host, Phil Nash. Phil, how are you doing today? I'm all right, Timo. How are you doing? Yeah, I'm not too bad, thanks. There's some kind of, talking about the weather again, some kind of snowstorm coming up here in Finland, but right now it still looks fine, so let's see how it goes. But I'm in the tide, so I should be fine. How are you? Snowstorm in Finland, you say? Right. How are you doing?

Yeah, well, actually, I don't want to bore our listeners, but I'm still a bit under the weather myself. But I think my voice is a bit better this week, just a bit of coughing and sneezing. So hopefully that will get better soon. Do you have any travel plans, any exciting travel plans in the near future? Not for a while, actually.

I've managed to keep the start of this year fairly free. I think my first travel will be ACCU. I'll be there. Yeah, she'll see you there. Amazing. Yeah, that's going to be fun. Hope to see a few other of our listeners there as well. Yes, yes.

It should be fun. Yeah. Yeah, so I'm actually leaving soon to london i'm gonna fly there in a couple weeks so i hopefully see you there and from there i'm flying to um tokyo actually um so for the committee meeting for the cso's committee meeting and we decided to kind of make it a family holiday and just go there together and like arrive like two weeks earlier and kind of just enjoy japan for a little bit all right enjoy thank you thank you thank you um so let's see how it's going to go with like recording the next couple episodes

because i'm going to be on the road basically for um all of march yeah um but we'll figure it out right yeah we'll fix it in post uh all right so at the top of every episode we'd like to read a piece of feedback this time um instead of reading a piece of feedback i'm gonna uh pass over to phil who has like a little bit of meta feedback i guess yeah well we didn't have any feedback specifically about the last show but i was looking back and i noticed that on reddit because every show is posted on on reddit uh that the previous episode uh about reflection with uh david vandervoort uh that's had the the highest number of comments on reddit certainly since we took over the show i think we had to go back a couple of years uh to to see any

bigger discussion so it was a little bit outsized which is interesting i'm not quite sure why that took off quite so much we usually have like a handful of comments there so keep the feedback coming but if there's no feedback that's not necessarily a bad thing either all right so we'd like to hear thoughts about the show you can always reach out to us on x master on linkedin or email us at feedback at cppcast.com joining us today is patrick quist patrick is a dutch software developer who primarily has worked with Delphi, but dabbles in C++ and other languages, and works as a developer and admin for Compiler Explorer.

Patrick, welcome to the show. Hello, thanks. I'm glad to be here. Now, we're talking mostly about C++ here, but your bio does mention that you mostly work with Delphi, which I hadn't actually realized was still in active development. I actually checked the Wikipedia page and there's been some quite big releases over even recent years. So are you still actively working with Delphi? I am. I am. Yes. I, well, I've worked since school, I guess, since my internships with Delphi, and I'm enjoying it a lot.

And I'm especially glad that it's been improving language-wise and getting more language features instead of just libraries and other things. Yeah, I know back in the day it was very popular, at least until.NET came along doing a lot of the same sort of thing. Yeah. So is it still a good environment

to work in? Well, the IDE is always complicated, but because it really centers around that concept that the IDE solves a lot of problems for you, but also causes a lot of headaches. Sounds familiar. But yeah, the language is still fine. Good to hear.

All right, Patrick. So we'll get more into your work in just a few minutes. But first, we have a couple of news articles to talk about. So feel free to comment on any of these. This time, there wasn't actually quite as much going on in the world of C++ from what I could tell as there is other times. However, there were a few blog posts that caught my attention. The first one was by Christopher MacArthur called C++ Package Managers, the Ultimate Roundup, which I thought was an intriguing title. There was a Reddit post about this blog post,

which had another title for it, which says, how deep is dependency hell? I thought that was a good title as well. But anyway, so it is a blog post about all the different package managers that are around. And I certainly learned something there because I was only aware about the two ones, VC Package and Conan, which this blog post does discuss in some detail. But it also mentions so many lesser known ones like XRepo, SPAC, Hunter, Buckaroo, CPM. I've never heard about any of these.

I don't know if Patrick, Phil, if you've ever heard about any of these. I've heard of some of them, but no familiarity with how they work. And so it says, well, kind of there's a relationship between package managers and build systems. So there's also a roundup of build systems. It talks about Mison and Bazel and Build2 and Scones and TpBuild and Pixie and Mamba and Gradle and Conda and NixOS and all kinds of things that I've never heard about.

So I thought that was very, very interesting, kind of to broaden my horizon a little bit of what are the tools out there floating around in dependency hell. It also mentions CMake's fetch content as like a kind of package manager kind of thing um so yeah i thought it was kind of very interesting overview which kind of certainly um eye-opening in a sense of there's actually a lot more tools out there that people are using actually than than i knew so that i thought that was quite interesting. But how to choose one? That's the question, I think.

Well, funnily enough, the very end of the post says, ultimately, the best way to choose a C++ Backup Manager is to try out a few different options and see which one you like the best, which sounds sensible advice. But I think when you put that in the context of most projects don't use any sort of package management, then just going to something is likely to be a big step up so do encourage people to try something right so we had another

blog post um that i thought was interesting by miro palmu called uh demystifying the lakers rule via visualization and how could it relate to constexpr? So I thought that was really cool. Like the LACOS rule obviously is a design guideline for library APIs that's been around for a while. But I was like, how can you visualize that? That's not interesting. And what does it have to do with constexpr? That sounds even more interesting.

And so it's an interesting take on the topic. And when you say obviously in there, but I don't think we've talked about the Lacoste rule in depth for a while. Do you want to give a very quick sketch of what it is? So the idea is that if you have a function that you know is not going to throw an exception, a lot of people put no except on that. But it turns out that if that function has a narrow contract, and by that we mean the function has a precondition.

And if you violate the precondition, you hit UB. Things like vector operator square bracket, it's UB to call it out of bounds with an index out of bounds. Or vector front, it's UB to call that an empty vector. Like it doesn't check that you're doing the right thing. It just crashes if you do. So things like that, if you have a function like that, you don't put no except on it, even if it never throws an exception.

And the reason for that is that you want to, I mean, one of the reasons for that is that you want to be able to test, if you have an assert in there that actually then checks the precondition in debug mode, for example, you want to be able to write a test that that assert is actually being hit.

And then you have that bounce check in there. And the only kind of scalable, portable way of doing this that I know of is to throw an exception. So you want to say that, you know, this thing doesn't throw an exception when you call it correctly, but it might throw an exception if you call it the wrong way,

because it's UB, ADC could happen, right? Including throw an exception. So that's a wrong way, because it's UB. Anything could happen, right? Including throwing an exception. So that's a good way of testing it or maybe recovering from an error in systems where you can't just terminate. And so by just sprinting no accept all over your code, you're kind of just completely disabling that approach. And so, yeah, the guideline,

the Lagos rule says don't do that. Don't put no accept on functions that might have free conditions. Now I have my own thoughts on this line the lagos rule says don't do that don't put no except on functions that you know might might have free conditions now i have my own thoughts on this that maybe we'll dig into another time don't want to derail us right now but i think it's important that you say that was the only scalable solution that you know of to is to use exceptions because you're pretty much quoted as saying as much in the post as a reference to your cpbcon talk last year oh am i quoted in there i haven't actually

read the whole thing i kind of skimmed it i thought that was interesting but i didn't actually read read the entire thing so that's interesting so they say in there and there that i'm wrong about everything and no right so so no the blog post is kind of cool because like it visualizes this idea of having a wide contract where you accept all the input and having a narrow contract where there's certain input which is just not valid for your function. And they kind of visualize it with Venn diagrams and stuff like that. And I thought it was a very nice way of explaining it, which I've never seen before. I did read it, but I didn't understand anything about it but when you did just explained it i i got a lot more and that was the the start of the post actually started with

well a lot of people explained this with an example but i want to explain it in a pretty abstract way uh but i'm apparently one of those people that learns by example and gets a lot more out of that. Right. So the other bit on that blog post was that it somehow relates to constexpr, which I have never kind of considered that.

With constexpr, you can kind of also see as a contract, right? So you can call this thing. It is either valid or not valid to call this like at compile time or not at compile time. And it's kind of similar. It's not quite the same thing, but yeah, I thought that was interesting.

Yeah. Okay. And so the last blog post that I want to mention is a huge blog post by Cybrand. Oh, yeah. Who is a developer advocate at Microsoft and is usually covering all the C++ tools that Microsoft does,

like Visual Studio, VS Code, VC Package. And this blog post is called A Year of C++ Improvements in Visual Studio, VS Code, and VC Package. And so I stumbled upon it because he wrote on Twitter, I wrote a massive blog post containing many of the things

the C++ team at Microsoft worked on last year. And so, yeah, I had a look at that, and it's really a lot of stuff. They have done some quite amazing work over the last year. There were some areas that they were focusing on, things like ARM64 support, like Unreal Engine support, code safety, cross-platform development, but there's just a lot more. And we kind of covered bits and pieces of it,

I think, over the last year, but it was kind of nice to see, okay, this is all the stuff that they have done for developers, kind of, or for C++ developers, but specifically like over the last year. And it's kind of very impressive how far they've gone. Yeah, you weren't exaggerating when you said it was a huge blog post. So of the biggest of this type i've i've seen and having worked on similar posts

myself and i think you have as well tima um i know just how much work goes into that just just putting the blog post together let alone the actual work done on the features themselves over the year so yeah very impressive yeah i thought that blog post always took me forever you know when i was doing this developer advocate thing i think it has to do with the fact that english is just not my first language so even though my english is okay but like just writing in english just takes like you know three times as much time as as you know writing in my native language um so not just you all right so so now great blog post if you're into microsoft's developer tools you should check it out um so you're up to date on what their tools

can do for you yeah and so the last the very last thing that i want to mention in the news section is uh a thing on reddit that i stumbled upon and it's's something that I think is, we don't cover this type of thing very often here, but I think when I do see it, I find it quite interesting. So somebody was interviewing for a senior position at NVIDIA and got rejected basically.

But then they said, here was this one question that I couldn't answer. And that might have something to do with the fact that I failed the interview. And so the question that they couldn't answer. And, you know, that might have something to do with the fact that, you know, I failed the interview. And so, so the question that they couldn't answer, that they posted on Reddit was what can be done to remove binary code bloat that occurs when you have too many differently typed instantiations of a template function. And then, and then the, the person was like, where do you even learn this stuff? Like, like? And then obviously there was a long discussion on Reddit. Yeah, I thought that was quite interesting.

I think most of the comments converged on the solution of factoring out the parts that are not dependent on template parameters into base classes or external functions, which is pretty much what I would do as well. But I liked the way one person summarized all of that, which is, well, did you try not using templates where you don't need them? So with this kind of thing, obviously, when you read the answer, you're like, oh, this

is obvious. That's what everybody should be doing. That's what I'm doing in my code, of course, because I'm writing good code, right? But I'm not sure I would have answered that question when asked that in an interview setting correctly. So it's kind of... Yeah, me neither. Yeah, I'm not sure I would have answered that question when asked that in an interview setting correctly so it's kind of yeah me neither yeah i i'm not sure i would have i would have done that so yeah that's that's kind of interesting to see these types of things being discussed and now you can pass an interview for nvidia

i'm sure that's all it takes i'm sure that's not all it takes. I'm sure that's not all it takes. And I'm also sure that they've seen this Reddit blog post by now because it generated quite a few replies. We'll see if that code size goes down. Right, right. So this covers the news items for this episode. And so our main topic for today is actually continuing our series of tools-related episodes,

which we started a while ago and then kind of for a while didn't have any episodes. I think it's an evergreen topic to come back to from time to time anyway. So we had one on Conan. We had one on Sea Lion. I think we had a couple more. And then so today we're going to talk about compiler explorer and our friend matt who's been here on the show um a few times is obviously a great person to talk to but we thought hey um you know actually matt is not the only person working on compiler

explorer so it would be really cool to like hear about how it works and where it is now and like how it's being maintained and what you can do with it kind of from somebody else's perspective and so we invited patrick on the show today and thank you again so much for joining us today we're very very excited to have you here uh yeah i'm glad to be here i am happy to talk about anything you want to talk about concerning a binary explorer thank you so i i don't think our paths have really crossed in the past, but I think over the years, I always saw like your tweets in my kind of Twitter feed,

and there was quite a lot of good stuff in there. All my random tweets, you know. I just want to thank you again for that. So I did appreciate that. I was like, oh, maybe this is like this person, like they write a lot of interesting stuff with us. Maybe our paths will cross one day. And so now they have.

So that's kind of cool. Yeah. Well, I think we, well, I did see you at CPC last year, I think. But you didn't see me, I guess. I think I wasn't there for very long. I think it was kind of a bit of a hectic conference. I had to like come late and leave early and didn't have much time to talk to anybody which was a bit of a bit of a shame this is how it goes sometimes

well before we get started we should probably just clarify what compiler explorer is because i know 99 of our listeners are familiar with it but maybe there's there's always one or two that have been living under a rock and and don't know or maybe you don't know that compiler explorer is the official name for what you probably think of as just godbolt so the the website you go to where you can just put c++ code in see what it compiles down to and that's that's the basic idea and the original premise was that you could you could see the generated code and tie that back up to the top level code and the the original c++ and experiment and see what optimizations occur and that sort of thing and verify your your assumptions it's

grown to be a lot more than that as we're going to probably talk about a bit more during this show but that's still a primary use case i think so yeah if you've ever used godbolt.org or compilerexplorer.com uh that's that's what we're talking about right so it started out i think as a kind of a pet project of matt godbolt so godbolt is actually a person and a verb yes and a verb i guess you can you can godbolt something right okay so um but i found out recently that matt is actually not the only person working on Compile Explorer or no longer the only person working on Compile Explorer. So Patrick, how did you get involved in Compile Explorer and what do you do there?

Well, it's maybe a long story, maybe a short story. I can shorten it. No, we have time. Don't worry. Well, I've always been interested in uh in c++ really i've never really been um been a fan of c or other languages pascal i did some yeah a lot of java in the in school but but also c++ and c++ just somehow yeah was really interesting to me and even though i've uh i started working in uh with with mostly delph, I did follow this sort of the scene, and especially with the internet coming up, and it was easier to follow what's going on in that industry.

And then I saw at one point, of course, a CPP YouTube video. And there's a surprising a lot of sort of certain websites that they were using. And then I also saw Matt talk about it in one of his earlier videos. And then I got really interested, like, maybe I can see if we can get Delphi or Pascal into that website. And that was basically my first pull request and it's uh really because they they were really inviting and uh friendly about my pull request even though it was a lot of codes probably bad codes but uh it improved over the time and um yeah it got merged and then i started to do more stuff. And now we're here. I wonder if your large pull request worked in your favor.

You know that old story that if you have a code review, the three lines of code, you can spend hours just discussing it and pulling it apart. Yeah. You give like three pages of code and someone will say, yeah, that's fine. Yeah, yeah, maybe, maybe, yes. No, but I did get some feedback and I did, of course, improve. But it was said in a nice way that I can actually do something about it. And there wasn't really a complicated discussion, but, well, this is not how we work and you should solve it some other way or something.

They were really glad to get any improvement at all. And I think that's really how we work nowadays still. Great. So other people can get involved as well. Yeah, exactly. So is it like an open source project and that people do in their that people work on in their free time or is is there like a team around it now like how many people work on this well first of all it's very open source like everything well almost everything is open source

even our infrastructure is in a repository as code using Terraform. And we publish that information to AWS where our online instances and services are running. And then the website, of course, itself, you can just run it locally on your PC as well, instead of having to use the website. Which is very useful. Yeah. Sorry, what? I can run Compile Explorer locally?

Yes. You can just clone the repository and run make. And what happens then? By default, it uses your system compilers. So if you're running Ubuntu and you have GDC installed the normal way, like via a package, then it will just use that. Wow, that is kind of mind-blowing. I had no idea you could do that yes you did no i didn't i really didn't that's really cool i think that's the thing with compiler explorer everyone's familiar with but most people don't know all of the little things you can do with it or

some of these facts like it's open source and you can run it on your own machine so that's one of the reasons that we want to surface all these in in this episode do you have any idea just just random question do you have any idea like how compile explorer is funded like because i guess it takes a lot of money to like run these aws instances and i guess people who work on it kind of do it every time, but at least the service probably costs a lot of money. So how does that work? Is that like... It does cost a lot of money, especially the amount of people that use it.

We have to scale up quite a bit. And we're using quite a lot of uh storage and uh compute so i think well it's half half um we have sponsors so matt spends a lot of his time uh trying to get uh sponsors interested not too many at a time but at least a decent amount. And then there is a Patreon in which people can donate. And if you do contribute to that Patreon, you'll get a, I think it's a weekly newsletter from Matt, just talking about what he's been working on that week or what the team's been working on.

Yeah. Which is really insightful, including things like, you know, how much it costs to run all these servers and how they're doing. He's really transparent about it. So I do recommend signing up for the Patreon, helping out and getting some useful information. Yeah, I mean, I'm very curious, for example, probably there's data about how many people

use Compiler Explorer per day or something. That would be a really interesting number. I think, well, there's like a public stats page that we have at stats.compiler-explorer.com. All right. And it displays, at least for a week, it displays the compilations. And currently, it's at 3 million for C++ for this week. 3 million compilations or people? Well, compilations.

I'm not sure if we really know the people that are using it. Okay, okay. I actually opened this website now. And yes, there's a lot of stats here. And yes, there's 3.3 million uh c++ compilations um in the last week 600 000 c compilations 180 000 rust compilations yeah there's people using what is zig there's cuda there's pas 10,000 compilations per week. There's D, there's ADA. Wow. And there's

Carbon. Yeah, there's quite a lot of stuff going on there. That is quite fascinating. We have a lot of languages. Yeah, yeah, yeah. We get new languages. I think we get a new language every month. Not just because

that's interesting, but because people like creating languages and just why not publish it to Compliant Explorer? 63 languages, apparently. Yeah. 2,666 compilers. I just pulled that from one of Matt's Patreon posts. But about two-thirds of it is actually C++.

That's also interesting. That's like by far the most dominant language. Yeah. Right, right, right, right. Well, that's interesting. So another thing that a lot of people don't know about Compiler Explorer is that it's not just the compilers. There's also extra libraries that you can bring in and other tools

you can run against the code. And I'm not just saying this because I've got horses in both those races. There's a Sonar plugin that you can run and you can also compile against Catch too. But there's plenty more libraries and tools there as well, which is really useful just to be able to drop in and try these things out without any setup at all against the whole range of compilers. Is that something that you've worked on at all? I did. I did. Basically, the first, well, the fifth PR that I made was about tools.

Right. And adding them to both after the effect of the compilation or on your code. So there's, I think the first two tools were, let's see. Oh yeah. The first two tools were pahole, which is a really weird name. Pahole.

I'm going to ask you in a minute what that is. We're going to cure it. So that's LLVM-MCA. So LLVM-MCA I heard about. It kind of tells you, roughly speaking, how long an instruction takes to execute or something like that, right? But what's P-A-Hole? I have never heard about that it's an intriguing name yeah it's um it's

a tool to that um investigates your binary that you produce either an executable or um or just uh from the from the from your code that inspects like classes and structures or in other languages, records or whatever data structure you have and see if the alignments are okay or acceptable in your case, but it will show like if there's gaps in between certain data types and if it's perhaps better to reorder them uh for better alignments and caching and yeah yeah because for example if you're doing like low latency stuff i guess you want your objects to be aligned on like cache lines and things like that right so i guess that helps with finding problems with things like that right that's very interesting i should i should check this out learning so much today this is great but over the time of course yeah there

there's now a lot of lots more um a lot more tools is it tricky getting all the tools to work with so many different compilers because obviously not all of them are going to work together how do you handle that sort of compatibility issue that's a good question i think at the start we really tried hard to anticipate that and so you as a tool it's always code so you always have to write code in the in the website and then it calls the the tool and um in that code class that you have to create, you get all the compilation information. So even the compiler arguments that are passed to the compiler itself. So that if you're using a tool like Clang Cray or Clang Tidy, that tool also can get those compiler arguments. Makes sense. But of course, yeah, some tools don't really work with certain languages

or certain binaries or certain compilers. So, well, then we have to exclude them from being able to use them. Because I really don't want to get in a situation where people are complaining like, well, it doesn't work here. There's a weird error or something. So we really try to test them. And if it doesn't work, we just disable them in that case sounds reasonable nice you

mentioned clang query there that's really useful if you happen to be working on static analysis tools don't ask me how i know there's also a really good case for running a version locally because uh at sonar we have our own instance that has some of our own rules into, or some of our own matches in Clang query. So we can see them actually working as part of the output, but probably not so interesting to most people. No, but there are also tools. Well, yeah, that's true. That's true. But it's really useful for compiler writers as well. And that's also really a type of user that uses the website a lot, I think. Not just because of the bug reports that they get with the compiler explorer links but also because it's

well useful to compare all the different compiler versions to what it's what it was and what it's now and how did the compiler interpret that code and you can do with it with client id for example right well talking about static analysis since i brought it up there it's probably a good time to to do our sponsor break because this week we are once again sponsored by sonar the home of clean code and sonar lint is a free plugin for your ide helps you to find and fix bugs and security issues for the moment you start writing code but you can also add sonar cube or sonarCloud to extend your CI-CD pipeline and enable your whole team to deliver clean code consistently and efficiently on every check-in or pull

request. SonarCloud is completely free for open source projects and integrates with all of the cloud DevOps platforms. And it's one tool that's not actually in that list that we don't normally talk about because it's basically written exclusively for Compiler Explorer. it's just another packaging for our analyzers so when you use the sonar tool there it's like a something between sonar lint and what runs as part of sonar cube or sonar cloud so an interesting little behind the scenes tidbit there so back to the the episode all right thank you phil so we do this thing sometimes where like in the second half of the episode,

we kind of dive a bit deeper. So let's do that. So I was actually this morning listening to the first episode of CWCast where Compile Explorer was discussed. It was actually called GCC Explorer back then. That was eight years ago where Matt was on the show. It was one of the really early episodes with Rob and Jason, like episode 40 something.

And so that was really fascinating because at the time, it was kind of very new. And Matt was saying, oh, yeah, I kind of just put this thing together. And so he described how how this works um he was saying yeah i basically have an instance on amazon like aws i guess which at the time was just one one computer and he was saying okay so i have just like one instance and then i kind of just have these Docker containers running there with like all the compilers. And then I have this little bit of JavaScript, which is like, does all the coloring and stuff

and, and, and like, kind of like I do this and this and this, and there's a bit of caching server side and, and that's pretty much it. So I was wondering whether that is still what it is or how does it work nowadays like what has what has changed in the last eight years well compared to that a lot um like it's it's it's really grown um a lot not just in uh well definitely instances so if if it was just one instance then it's we yeah because we're serving a lot of compilations

and the website is quite popular I guess and I think a lot of people use it in their not just definitely in their work time and for their jobs or to see what's going on.

And we're, well, currently we're running 11 instances. This is European time. So America hasn't really waken up yet, I think. Well, almost. And it can grow to maybe 16 or something. And in really quiet days, it's still six instances at a time. And that's just Linux instances for our normal GCCs and Clang. We also now have two GPU instances where you can run CUDA codes that can run on the actual GPU.

And we have to run two because they're really expensive. And a lot of people are using those GPU instances for very different reasons than that we use them. And they're always in use. So we have to have some kind of consistent performance that if one crashes, then it takes a while for another instance to spawn. So we try to keep

two alive, which is not cheap. But now we've solved NVIDIA's code bloat problem. Hopefully that'll be a bit cheaper. Right. If only, yeah. I wonder if you have these really powerful GPUs running running there which basically anybody could run any code on do you get things like somebody mining bitcoins on there or something like i don't know if that's still a thing or like like

doing something that they're not supposed to do um maybe maybe they're trying. I don't know. But just as the normal Linux instances, we have a sandbox running on the GPU instances as well. And that limits both CPU cores that you can use and memory and time that you can spend on it. So I doubt they get much use of that out of that right that leads me to another question and maybe you can't answer this at least fully and that's okay but i presume you have certain sort of safeguards in there to prevent abuse of the resources like you know the bitcoin mining or um just locking up lots of instances

for for no reason maybe even like denial of service attack do you have any any things in place for that you don't necessarily go into details well aside of the normal aws we i think we have some aw AWS safeguards. But other than that, it's basically just running a lot of instances and sandboxing. Right. That's really the most important part, perhaps. Not just because we don't want people to abuse the resources, but also we don't want people to access someone else's codes if they don't want to share that that makes sense i don't want to be giving people ideas but

i'm sure they'll come up with them on their own anyway oh and and um yeah, since I think last year, we're also running a Windows instance. We used to have Microsoft itself, um, run, uh, Microsoft compilers. Uh, we still do of course. Um, but we wanted to have another alternative and, um, now we do have it. And we also have sandboxing for that so yeah that's just about the instances yeah if i remember rightly that was one of the limitations because as well as compiling the component you can you can run it now as well but i think until recently you couldn't do that with uh visual c++ but you can do that now am i right in thinking well what does it depend

uh well microsoft had to disable execution for well we we had a small period where execution was on but we decided to um not do that anymore and we now our own windows instance i think we've tried hard to mitigate any issue that can come from execution and uh therefore we have enabled that execution but it's only uh we only have ming how do you pronounce that in english min gw min gw yes okay uh compilers yeah right interesting so it's still still a limitation but for for good reasons yeah but maybe in the future we can have more compilers on that yeah there's also no apple clang as far as i can tell so there's no i guess because you need to need the actual hardware for that which yeah that's also no apple clang as far as i can tell so there's no i guess because you need to need the actual hardware for that which yeah that's uh really big we are well no we definitely

have um questions and about that but we really can't well pick you it but we're not good at it. Fair enough. Fair enough. So this is actually kind of more of a comment, but I just noticed when I was listening to the episode from eight years ago, Matt was saying, kind of going more on the client side now rather than server side, Matt was saying that, yeah, so there was this JavaScript stuff

and then there was this like um thing which is like the code editor which he just like basically took kind of an off-the-shelf thing for the code you know he was like yeah this is great it has like all the features has like way more features than we need like it even has like things like vim bindings and but like who who in their right mind would ever want to want to do that and now i see there was actually a button here toggle vim key binding so clearly that has been added so so yeah he was like who would ever want this like on pilot explorer so i guess it's uh things have changed quite a lot on the kind of client side as well yeah we yeah i'm not sure

there's been a lot of work on the client side and especially the website itself. It started out as just some pages in JavaScript, but now we've transitioned to TypeScript, mostly. Not entirely, but mostly. And it's a lot of code. codes yeah it's just like thinking about it like how much i actually rely on compiler explorer uh in my daily work like whenever you like send a code snippet to anybody and say like hey look this is doing something weird or whatever like the default way to do this is to like send them a godbolt thing right yeah and um so i'm just looking at my like toolbar you know like the the kind of most important books marks you have like at the top of your browser and number one is like my calendar

which tells me where i need to be when and number two is godbolt like compile explorer is like number two then number three is like uh eel.is which is like the standard and like number four is like my to-do thingy so yeah basically uh compile explorer is like right there at the top um and i don't think i could really do what i do without it these days it's just like if you want to know like oh this weird every now that i'm kind of involved in like standardization and like if you're developing a new new language feature which i'm kind of involved in like standardization and like, if you're developing a new, new language feature, which I'm kind of actually actually working on, like,

you know, what do you do? You call Matt and you tell him, Hey, we have this like hacked version of Clang that supports our experimental feature. Can you just put that on compiler Explorer? And then he does.

And then all you do is just like send each other, like got bold snippets. I shouldn't say that because I think matt always says that you know you should say compiler explorer instead of like his name so i'm gonna say it properly uh so you're gonna send each other compiler explorer links um basically and and just that's the thing you use to figure out if something works or doesn't or compiles or you know what it does and yeah so so yeah it's became such an essential tool, I think, probably for many people.

Yeah, I don't have a bookmark for it. So I only have to type CO, it automatically completes to Compiler Explorer. Right. So are there any other really useful features baked into Compiler Explorer today that most people probably are not even aware of? Maybe you're not the best person to ask this because you're too close to it but maybe you've got an idea in mind um yeah

i'm always trying to think of um better ways on how to improve the website i'm not always succeeding, I think. There's a lot packed in. Yeah, yeah, yeah. No, what I especially think is nice is the IDE mode that we have since a couple of years, I think, where you can not just have small code snippets, but also embed or send along additional files. And not just that, also just write a build script in CMake and have that tested and working your, building your executable and testing that and is that this um tree thing that you can add yeah i've actually tried that yet so where's that how do i do that that that sounds really cool the add button next to the logo the bottom option is tree ide mode wow this is so cool i've never seen this before so there's even there's an even easier way since

a year um someone has added uh it's called a site templates button if you click that you can just choose a template so like c c make and get a nice layout for that an example project yeah and i i i can save my own right so for example if i want to know like it does this compile on like these four compilers i can just like save a template that has exactly that layout right Yeah. Yeah. That's really cool. And if you have, um, if you want to save it, save your projects, you can also do that. So if there's a, yeah, if you click on projects and then say, if you can download this as a zip and you can also load it as zip, so if you also have a GitHub repository, you can download the ZIP from there and then upload it to Compiler Explorer. Of course, there are limitations to that. We have a limited

amount of file extensions that you can use. And if we don't know a file extension, we filter that out. So it's not loaded. And if the zip is really large, like if you're loading boost into your client, it's all using libraries, then usually it doesn't work because we don't allow internet on our instances. Right. But you have like a kind of repository of like certain like commonly used libraries that you can include? Yeah, yeah. We get very generous pull requests and bug reports about any libraries. And in the first few years, we only really added just the headers of the,

of those libraries. But nowadays we have a complete infrastructure for building libraries to link against and execute. Nice. And there, yeah, it keeps growing the list. Is there anywhere I can see this list?

Like, well, if you have a compiler you can um click on the little book and then it's well libraries there we go yes okay yeah i okay it's like yeah it's like there's like over 100 libraries here like pretty much all the standard ones there's qt there is um uh yeah there's a lot of stuff um there's all like the testing frameworks there's boost yeah this is very impressive yeah yeah this is really cool and really the the most used library is, well, I should say we don't really have stats on this yet. But we do have stats on if you're linking or executing with a library, then FMT is by far the most used library that there is. FMT. But that's now in the standard, isn't it? Well, well well well some of it no comments

in a way uh stood format may have generated more interest in fmt because now people think what else can we do yeah okay no there's like a few areas of C++ that I kind of early decided that it's so complicated that it's not even worth trying to understand how this works. And one of those areas is anything that has to do with strings and characters. I just don't understand it, basically. It's funny that we have this like Unicode study group on the committee and they have meetings and they have papers and they have like emails related to that that land in my inbox.

And I have no idea what's going on there. I kind of gave up on that topic. I think you have to choose your battles. Yeah. Yeah, I think the three biggest areas of complexity in any programming language, really, but particularly C++, are strings, initialization, and for loops. So I try to avoid all of those.

Yeah, you might be right. I mean, the for loop, the range-based for loop was broken until SuperSus23. So you have a point there. Okay, so Patrick, are you aware of any features in Combat Explorer that are not there yet, but that you're kind of working on that are going to come out soon that you can talk about? We won't tell Matt that you're spitting all the secrets i think we have endless lists of plans but not enough time or interest to do all of them and there's a lot of well it's

i think what we're at a stage now where every interesting feature is a lot of work. And we also have the normal code reviews and merging pull requests and testing and other bugs. And so every... Well, we didn't really talk about it, but we do sort of have a team of people, but everyone is working on in their free time, of course, and we don't really expect them to fully be dedicated on on anything really but every member has taken a place in in sort of uh in the projects of all sorts like some people are really invested in getting cross compilers

to be supported so they're really uh good at using CTNG, I think it's called, in generating cross-compilers with GCC. So we've added quite a bit of those. And some people are more interested in the TypeScript area and improving the code for bug fixing. And I try to, if I'm not really merging pull requests and testing takes a lot of time, especially with a web project like this, where we have a lot of dependencies and every dependency has security updates like every week but Matt

is kindly taking that upon himself to improve that every week and therefore I'm trying to focus on when I do have inspiration to work on Compiler Explorer to focus on when I do have inspiration to work on Compiler Explorer, to focus on really

setting aside some time and spending that time on complicated issues to improve infrastructure or things that take a lot of concentrating time makes sense i think it's worth emphasizing that the whole the whole project is run by volunteers yeah just in their own time even the core team no one's getting paid for this and even all the sponsorship money and patreons it's just going to the infrastructure as far as i know so i think everyone in our community really has a has a big debt to you all so thank you for everything you're doing i think we're glad to do this i i think we uh you know it's still interesting to do yeah that doesn't mean we can't be appreciative so um a final question then for today uh by usual final question is there anything else in the world

of c++ or beyond so i know you're interested in other areas that you find particularly exciting or interesting at the moment i'm still waiting for a good module solution join the queue yeah well everybody's been saying that now all three compilers, the major compilers support it and even CMake supports it. And in theory, it all works now, right? So what's the problem? What's the problem? What's everybody complaining about? Yes.

Next. No one knows. Maybe we do need another modules episode soon yeah i mean we did we did one with uh dania right uh half a year ago or something but but yeah it seems like there's quite a few holes there when you actually want to use this stuff right yeah i think when we're even comparing it to the work we had to do in terms of libraries and getting them to work, modules is going to be a lot of flags in the compiler that normal perhaps to, uh, um, achieve good linking and executing, um, across when, when the library is using a lot of, of their own flags and you're using different flags in normal codes, but with modules, it looks like it's going to be complicated. I bet it might be the first time I've ever heard the words easy and ABI together.

Yes. Yeah, I'm hopeful. It's going to happen. Just a matter of time. Who was it saying recently that the C++23's modularized standard library will really help adoption? Was it Rainer in the last episode? Yeah, I think so, yeah. I've always said modules will be a C++23 feature.

21, 23, maybe. Well, let's see about that all right so um i think we are kind of near the end uh for today but uh patrick thank you again so much for coming to the show and talking to us about compiler explorer i certainly learned a lot me too and um yeah is there anything else you want to tell us um for example where people can reach you if they want to get in touch? Or anything else you want to kind of say, promote, share? Well, you can read it in the show notes, I guess. But I think the most importantly, I want to maybe tell that send us progress, send us issues and what you want to improve about CompileX

or what's bugging you about the website and how can we help with that? Even if it's really a tidy thing that you're bothered by, or if you want to get your favorite library into compiler explorer, try to take 10 minutes and see if you can get it to work. You don't even, even if you don't have time to test it and run it locally, you can basically just send a support request through GitHub and just edit the files that are needed. You basically have two files in our infrastructure repository

and our main Compiler Explorer repository. It should be easy, but if it's not, we can write more documentation, I guess. Try to spend 10 minutes on that and see if you can make it work and send us a pull request. And if you can test it,

we will test it and merge it. Great recommendation. Thank you. And thank you for coming on the show today, telling us all about Compiler Explorer and all the stuff we didn't know. Thanks for having me. 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 guest or topic, we'd love to hear about that too. You can email all your thoughts to feedback at cppcast.com. We'd also appreciate it if you can follow CppCast on Twitter or Mastodon. You can also follow me and Phil individually on Twitter or Mastodon. All those links, as well as the show notes, can be found on the podcast website at cppcast.com. The theme music for this episode was provided by podcastthemes.com.