CppCast - Tease Your C++ Brain

Episode Date: November 19, 2024

Anders Knatten joins Phil and Timur. Anders reminds us about cppquiz.org and tells to us about his new book, C++ Brain Teasers, how that relates to the site and why it's has good practical applicability. News New report by the US Cybersecurity and Infrastructure Security Agency (CISA) C++ Safe Buffers - a new Clang20 feature CppFront version 0.8 is out “Safe and efficient C++ interoperability via non-escapable types and lifetimes” - from the Swift Forums Links C++ Brain Teasers - Anders' new book C++ Quiz C++ Quiz repo and getting involved Submit your own C++ Quiz questions Modulo One - Anders' band IncludeOS - Episode #63 of CppCast

Episode 394 of CppCast with guest Anders Knutten, recorded 8th of November 2024. In this episode, we talk about the latest CISA report on software safety, C++ safe buffers in Clang 20, and about C++ Swift Interop. Then we are joined by Anders Knotten. Anders talks to us about cppquiz.org and about his new book, C++ Brain Teasers. Welcome to episode 394 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? I'm all right. Yeah, there's a lot going on. Next week, I am going to Bristol, UK for the Audio Developer Conference, then to Berlin for Meeting C++, and then to Poland for the committee meeting.

So busy preparing for all that right now. Also, we got snow here in Finland now, so winter has officially started. Yeah, what about you, Phil? What's new on your side um i can't remember if i mentioned it last time but i've sort of started a new role part-time developer advocate at undo or maybe familiar to many people who listen to the show oh those are the people with the time travel debugger right that's right yeah yeah so we'll probably have somebody from undo one again soon we've been talking about that for a while uh actually got some really interesting stuff going

on at the moment and seeing it from the other side sort of makes me excited to want to start talking about it but so we'll put that off for now let somebody else do that talking so you're going to be doing that in parallel with your conference organizing stuff and your workshops and exactly and that's why it's part-time so i'm just doing a few days a month while i continue to be independent the rest of the time all right well i'm looking forward to uh things you come up with in that new role yes yeah me too all right so we'd like to hear your thoughts about the show uh you can always reach out to us on x mastodon linkedin or email us at feedback at cppcast.com. Joining us today is Anders Knatten. Anders started programming in Turbo Pascal in 1995

and has been programming professionally in various languages since 2001. He is the author of the book C++ Brain Teasers and the websites cppquiz.org and blog.knatten.org. Anders has worked with everything from websites to CPU design, but his main focus these days is C++, which he also likes to speak about at conferences around the world. While not geeking out with computers, Anders likes to go to industrial music festivals

and produce his own music as Modulo One. Anders, welcome to the show. Thank you very much. So Modulo One, obviously a bit of a programming pun there, but that's a band is it or yeah it's a yeah it's kind of a two-person band right doing all sorts of like industrial related music i would say interesting although presumably although two person when you apply modulo one there's only one left yeah that's uh left as an exercise to the audience so is it more

like purely electronic industrial or is it more like industrial metal or like no it's an electronic one so like yeah ebm future pop dark electro industrial techno kind of stuff cool well that sounds great um i'd like to listen to that stuff yeah. It's basically just me trying to make whatever I like listening to. That's good. All right. So Anders, we'll get back to you in a few minutes. But first, we have a couple of news articles to talk about. So feel free to comment on any of these.

Okay. So the first news item today is a new report by the U.S. Cyber Security and Infrastructure Security Agency, also known as CISA, about software security. It actually came out, I think, three or four weeks ago, but what made me aware of it was another article on the internet on the Newstack, which linked to that. And then I looked at the original report. So it is the strongest stance yet from the US government

to call to abandon C and C++ or move from C and C++ to memory-safe languages like Rust. Yeah, kind of their calls are getting louder and stronger as time goes by. And so now they're basically saying that, you know, anyone who is like still writing in memory-unsafe languages or writing memory-unsafe code basically, unsafe code basically is negligent. I think I can interpret it as that. I can quote from the original report.

It says, the development of new product lines for use and service of critical infrastructure in a memory unsafe language, as such a C or C++, where there are readily available alternative memory safe languages that could be used is dangerous and significantly elevates risk to national security, national economic security, and national public health and safety. For existing products that are written in memory-unsafe languages, not having a published memory safety roadmap by January 1st, 2026, which is just over a year from now, is dangerous and significantly elevates risk to national security, et cetera, et cetera. So the clock is ticking.

They're saying basically either move away from C and C++ within a year or make your C and C++ somehow magically memory safe within a year or risk being labeled as negligent. That is a pretty strong stance there. So what do you think about that? I don't know if I'm looking at your notes here. I don't know if this is paraphrased or copied verbatim, but it says move away from C slash C++. That would be quite easy because that doesn't exist.

So maybe that's the way out. So the quote in the notes is from the original report. So it says, for example, C or C++. So it's talking about memory unsafe languages in general. Right. The way I read the intro here, at least, on the webpage is more if you're doing Greenfield stuff,

then maybe don't do C++, which is fine, I guess. And if you are doing C++, have a roadmap. And their roadmap doesn't have to be like, take all of Sean Baxter's work now. It could be like, set up sanitizers and fuzzers or whatever so yeah it's all a bit vague like yeah i think that the other article that we're gonna put

a link to that in the notes as well says like maybe interprets it quite strictly they say like you're basically negligent if you're not doing this and you're gonna get sued or whatever and maybe that's not the only possible interpretation maybe that's not what the report actually says i have to admit i didn't read the whole thing i kind of just skimmed it i only read the intro as well so yeah yeah well they don't seem to be like introducing any hard regulation yet but i don't know maybe they do and i didn't see it in the report but yeah but each one seems to be getting stronger and stronger so maybe it's a rather true luxury although um i don't want to talk too much about this but uh mostly for the benefit of people coming back and listening to

this in the future as we record this this week there has been a change in the government in the u.s so we're not going to talk about that. But I do wonder whether that may have some impact down the line. Maybe they'll take their eye off this. I don't know. Probably not. So the actual report came out in October 16th. So that was like three and a half weeks ago. So that was before the US election that happened this week.

Yeah, it would take a while for that to have any impact, if any. But you never know. Right. So we're not going to talk about politics on the show. Definitely not. I'm sure we all have our thoughts on that, but let's leave them for later. Continuing on the topic of software safety, Clang 20 comes with a new feature, C++ Safe Buffers.

So, yeah, that is meant to harden your C++ code against buffer overflows, which is one of the main sources of security vulnerabilities in C++ today. It's kind of a multi-pronged approach. It says, well, there's a bunch of prerequisites, so you have to use a libc++ that was compiled with a hardening on. So there's a bunch of hardening modes.

So you need to use at least the fast mode, libc++ that was compiled with a hardening on. So there's a bunch of hardening modes. So you need to use at least the fast mode, which enables the kind of buffer overflow hardening for like containers and like vectors and span and stuff. And you also need to compile a library built with this flag libcpp-abi-bounded-iterators, which I think kind of makes, it hardens iterators somehow. Haven't looked in detail into how that works,

but yeah, it's another build mode or flag or something you can do now. And then when you do that, you can enable this new warning, minus W unsafe buffer usage. And that's going to fire whenever you perform any unsafe buffer operations on a raw pointer, which includes any kind of array indexing with square bracket, like indexing into any

kind of like raw array that you got from a pointer, any form of pointer arithmetic, any bounce unsafe C functions like memcpy, et cetera, any unsafe smart pointer operations like indexing into a unique pointer or, I guess, get the rule pointer out or something like that, because they can't be made safe because of how the language works. So on all of those, you now get a compiler warning, which you can turn into an error if you want to be really hardcore about this. And in order to avoid that, what you need to do is you need to encapsulate any raw buffer usage, anything where you access data through a raw pointer that is like an array underneath.

You have to encapsulate that into like a safe container or a safe view such as vector or span with the hardened mode on. Otherwise, the compiler is going to park it here. So that's the new feature. That sounds interesting. There's probably going to be a lot of code that's not going to compile when you turn that on. But another useful tool. And I think this is a good demonstration of this sort of many-pronged attack

on the whole safety issue. As we mentioned last time, there's the two primary approaches. Do we fix up the language or do we introduce things that are going to make existing usage of the language safer? And that's not just the committee's responsibility, but tools can also give us useful tools like this to help. And it's one of a steady stream of such tools that are coming out. So it's worth keeping on top of what your compiler can do to help you.

So I actually think this is kind of a bit similar, like what Rust does, but like safe and unsafe blocks, but obviously just for buffer overflow and not for any of the other kinds of UB. But I guess if you have a class that uses a raw buffer underneath, like you have your own container or your own smart pointer or whatever, some people do things like that. I guess you can just stare at that code long enough

to convince yourself that it's fine and then basically disable the error just on that one. But then use that everywhere yeah and yeah you're supposed to i think you're supposed to really use the standard library containers and views in the hardened mode and not roll your own i guess that's kind of a part of the point that they're trying to make here yeah no matter what approach we take there's always going to be a point where we have to distrust something. It's like this part,

we're just going to say this is fine. And this becomes the axioms that we can build everything else on. Right. So while, you know, the US government keeps warning us about using C and C++ and C and C++ tool vendors are coming up with new, new tools to make it safer.

There's also other languages around C++ or that want to make it safer or replace it with something safer or just, you know, interrupt with it or provide a safe alternative. So there's a lot of that also going on. two things, CppFront, which is Herb's pet project, which is kind of this new kind of wrapper around C++, kind of new successor language slash a kind of like new syntax on top of C++ that compiles to C++ or transpiles to C++. So that's now out in a version 0.8. So it's still very much pre-version 0, use at your own risk, but it now is available with a new license, which is Apache 2.0 with LLVM exception, which for the first time allows commercial use. So Herb is saying that's now stable enough for that.

It's still at your own risk, but like it's kind of now, you know, you could contemplate actually using it in some kind of real project. So that's interesting. kind of now, you know, you could contemplate actually using it in some kind of real project. Yeah. So that's interesting. There's also a bunch of new features, like regularized function syntax. He has decltype now. He has this hashable meta function. There's lots of other stuff. I'm not going to list all of that.

You can read it yourself. But yeah, development on that is ongoing. Yeah, and I think that's the interesting point, that this is being actively developed still. Yeah, and there's a bunch of contributors as well. So it's not just Herb. There's a bunch of people actively submitting pull requests and driving this forward. I think it's still very much like a hobby effort at this point still. I don't think there's anybody backing it with money at this point.

At least I'm not aware of it. But let's see. Let's see how it goes. It's certainly an interesting project. And then our final news item is something that you just dug out, Phil, isn't it? So do you want to talk about that one? Yeah. So actually, just to be transparent on this, I only saw this sort of 10 minutes before

we started recording. So I haven't read it in depth, but I thought it was, it sort of fit in with what we've just been talking about so well. We couldn't really not mention it and this is um the the swift c++ interoperability which we we mentioned before particularly when doug regger was on that's something that is still an ongoing effort and they have added some new features to that and there's a there's an article on the the swift forums which will put a link to safe and efficient c++ interoperability via non-escapable types and lifetimes so this this fits right into what we've been talking about

with uh you know lifetime management but from the perspective of interoperability with with swift and just a couple of choice quotes from the article so i haven't read it in depth but i think this gives you a flavor but right at the start it says safely interacting with unsafe code is challenging i don't think anybody's going to disagree it's an understatement i would say yeah but um but a bit later goes on to say we propose using annotations to express lifetime information for c++ apis and one of those is a Clang attribute, Clang lifetime bound. There may be some others, as I say, I haven't read it fully, but actually these are things that you can use today.

And it talks about how you can use these annotations to mark up your code so that you can use it safely from Swift. And the interesting bit is this non-escapable stuff. And so I haven't read the article in depth, but I know from my own knowledge of Swift is this non-escapable stuff. And so I haven't read the article in depth, but I know from my own knowledge of Swift that a non-escapable type is one where if you have a Lambda or Clojure in Swift, but we know in C++, we have the problem of that the lifetime of the Lambda can outlive the data that it has references to. And you can get these dangling references you have to be very careful of.

Well, in Swift, they solved that problem by having this non, or escapable or escaping attribute to say this closure escapes the scope that it was created in. So there may be lifetime issues. And then the language can actually work on that for you and introduces them overhead with copying.

But it only does that work when it needs to, you put this this annotation in obviously we don't have that in c++ so that's that's where these uh these annotations are coming in to sort of give you back that ability to to say when the lifetime of a lambda or a closure actually escapes the scope that it was created in and why you may need to address these lifetime issues. So I thought that was quite interesting and definitely a nod towards using Swift as potentially a safer successor language for C++ and interoperating with it. That's interesting.

But yeah, it strikes me that all of these attempts at somehow introducing memory safety kind of fall into three camps, right? So there's only like a limited amount of approaches possible, it seems. So the first one seems to be just track all the like memory at runtime, like address sanitizer, or you can do it in hardware now with something like Sherry, right?

Like tag pointers. So either do that or change the object model to like track track that stuff statically at compile time to not allow you to have you know things that escape a certain scope or mutable shared state or anything like that like the basically the rust borrow checker or something very similar to that right that's like second approach and the third approach seems to be these um lifetime annotations where you kind of take code and just annotate it with you know this outlives that or you know this must be uh like non-zero here or whatever and then and then again let the compiler figure it out yeah i think

everything i see is like kind of a repetition of one of these three approaches which is just interesting so this seems to be like the annotation approach. Yes. Well, let's see which one wins. Right. Okay. So I think we talked enough about safety. Let's talk about unsafety.

Yeah. Let's move on to our main guest for today, Anders. Hello again. Thank you very much for being on the show with us today. Yeah. Hello, and thanks for inviting me. So last time you were on the show, this is not the. Thank you very much for being on the show with us today. Yeah, hello everyone. Thanks for inviting me. So last time you were on the show, this is not the first time you're here. Last time you were on the show, it was back in 2018 when Rob and Jason were still running it. And you talked about your cppquiz.org suite of CPP quizzes. So we can talk about that again today, but also you have a

new book out, right? It's called C++ Brain Teasers. Yeah. Is that somehow related to cppquiz.org and how did that happen? Can you give us a bit of context here? Yeah, so I wasn't really planning on writing that book, but the pragmatic programmers, they have this series on C brain teasers and Rust and Python and all these brain teasers, and they were looking for someone to do the c++ book in that series and then it was francis bontempo who had just published a book i

think with pregprog and then she just introduced me to the publisher and then yeah we decided to write this book so that's how it came about and it is related to the cpp which i don't think it would have happened if i didn't have that site. But yeah, it's not just a printed form of the website. It's different to that, but it's kind of based on the thing I'm doing there as well. So all of the brain teasers in there, are they new or are some of them based on what you have on cppquiz.org? A few of them are based on the website, but most of them are new. And all the explanations are new and much longer.

Because it's like a 120 pages or so long book with only 25 questions in it. So it's not just a quiz book. The main thing is that you have this question to get people to wonder about a certain thing. And then you have some pages explaining how exactly does this language actually work here and why is it like this and uh trying to trick people into learning something yeah yeah are you able off the top of your head to sort of sketch out an example i know that's hard on an audio podcast but is there anything you can like give a flavor of sort of questions you might have in there yeah i can i can take i have the book in front of me like this one that's easy to explain without actually showing the code so this is one of the easier ones like the second

one so we have like uh you have two overloads of a function called serialize one takes a void pointer and one takes a string ref so the ref, and then you call it with a string literal. Is that string ref? You mean string view or? No, a reference to a... Oh, a ref. Reference to language reference.

Yeah, a reference to std string and the other one is a void pointer. And when you call it with a string literal, it prefers the void pointer overload instead of the string one. And so this is... A lot of people who have been writing c++ for a while understands that that's the case but then you have a few pages talking about okay how actually does overload resolution work and like what about why do we have all this or not why but at least explaining all this weak typing kind of things with oh it's very eager to do all implicit conversions and stuff like that and uh yeah so it's an excuse to talk about those things and then um yeah in some places it's like an undefined or an initialized

variable on the stack and it like reuses the one from the last time you call that function and then it explains like on my particular system this is how the stack works and this is why you see that behavior but actually people that doesn't require that and like yeah so it's all sorts of like excuses to talk about try to like understand more about how the language works so it's very little about how does this library work or stuff like that it's more about understanding the fundamental things which is just what i happen to find interesting yeah this sounds like uh these are not just like dark corners of the language like um nobody would ever know this anyway but this is it's fun we've had that sometimes um i know because i've done some of your quizzes but this sounds much more practical this is like stuff we probably

should know but they're sort of on the cusp of the border of what people actually know in practice yeah yeah i'm trying to try to keep it practical. So these have been selected to be, like you should learn something that's actually useful to know. And I have, I try to always have like, so this is a bad thing and you would avoid it by this particular warning or this sanitizer,

or like here are some tools you can use to avoid these things. And I'm trying to, because cppquiz.org is full of like weird stuff because I have opened up for submissions. And when do you submit a question to a cppquiz.org is full of like weird stuff because i have opened up for submissions and when do you submit a question to a cppquiz site it's when you just discover something super weird like this is so strange i have to submit it to cppquiz so there's too many weird questions i think on the website so i'm trying to i've tried hard to not make the book be like that as well. So you just mentioned that people can submit suggestions to the quiz.

How does that work? How can we get involved? How does that work? So if you just go to the site, on the right-hand margin, there's a submit your own question kind of thing. It's something I did because I wanted to save time to write these questions myself but then people start submitting all this weird stuff that i don't know and it's not just a question

and answer thing it's like there's always an explanation with the reference to the standard saying like okay here are the relevant sections explaining exactly why this is the case why the answer is correct um so then i end up with all that work trying to understand these things that i've never heard about because someone submitted it so i'm not really saving time but i'm at least uh poked into getting new content out at least right right so how did how did you get the idea to start this in the first place like uh it was at the acu conference in 2012 or 13 or something then uh oliver maridol was having one of his pub quizzes and yeah then i was in the bar and i got a bit drunk and i figured someone has to make a website with this kind of stuff and then i went to my room and started like drunk coding some stuff in python

and django which i kind of almost knew a little bit and yeah basically finished the first version then some nights at acu on the train and the plane back home so if you look at the source code for the website itself on github you will see that it's not very well implemented but it's been working now for 11 years or so um yeah and then i just asked for some ideas and then lots of people just sent me their stuff from their pub quizzes from other conferences and stuff, so that's how the site got started, and then I just kept adding stuff. And trying now to publish easier and more relevant things

so that you can not only see these weird corner cases that some people dug up. Yeah. Right. So has your relationship with it changed over time then you have like a different goal in mind maybe for the website yeah yeah so first i published a lot of stuff and then i just stopped doing c++ for a few years and i kind of had it on the back burner for almost five years while i was doing something else but i wanted to keep it alive and then i got back to c++ again and then i've been trying to keep it a bit more

alive now and yeah trying to get it to be more to have more relevant contents and you have like three difficulties on the question so you have like beginner intermediate and expert or something and beginner is like not totally beginner but you should know c++ a bit and then so i want to make some way to like filter out all the expert questions or something to make it a bit more beginner friendly and uh just the main work with that is just adding enough content to so that there's still lots to do with only the beginner-friendly questions displayed. Right. I mean, you've been running it for so many years now,

you've seen many different C++ versions come and go. So you're constantly adding things from new language versions in there? Yeah. Yeah, so it's basically whatever comes to mind. If I see something interesting, or mostly nowadays people submitting stuff. But all the questions say according to c++ 23 what's the output of this question like and you either you say it's going to compile and you type in the answer uh or you say it's undefined behavior like you select

from the drop down and yeah so the reason we just ported it to c++ 23 is that's i for each question you get an explanation with references to the standard, and I want it to be correct for whatever standard we have now. And so what I could do is just like, whenever I get a new question, I say, according to C++23, and then the old ones are still at 11 or whatnot. But then every time you go to a new question,

it shows you a new version of the standard to think about. So I don't want that either. So what we did, I just exported the entire database to a github repo and then got the community to help me port it over the summer basically just updating everything and there were a couple of questions that actually changed the answer most of it is just like stuff moved around in the standard or there's a different way to reason about these things but a few things actually did change. Yeah, I was going to ask about that.

Do you have an example at the top of your head of something that actually changed? I should have prepared something. I think we have something about the range for with rvalue kind of thing. I think there's a question about that. Yeah, there was a thing that if you have a range-based for loop and you're iterating over something which is a temporary that returns a temporary, then that temporary goes out of scope when that expression is evaluated. So you're iterating over something that doesn't exist anymore and you're in UBLand and you fix that in CSS 23. set in css 23 yeah but that actually changes behavior for example there are cases where that thing that you're iterating over like if you create it it takes a lock for example

and then if you destroy it it like releases the lock it actually changes behavior so they're like uh interesting cases like that yeah yeah i think we had a question about that there's something in the book about this as well uh right about lifetimes uh there's several questions about lifetimes in in the book and yeah that doesn't surprise me so now now yeah now any temporary lives until you actually looped over that so yeah yeah i think over the years there were quite a few topics where like the standard changed like what it what it says or what it does like things like aggregate types i think the initialization for aggregates has changed i think in every standard and there's yeah there's other areas like that or like when

a type is an aggregate and when when it's not an aggregate and things like that yeah i think like now you can actually inherit if you don't have any virtual functions or anything you can inherit from something and still be an aggregate and you couldn't before like yeah stuff like that yeah yeah there's a lot of stuff like that it's interesting that you chose superstars 23 because it only became the official standard like literally a few weeks ago and i think most people don't actually kind of use it in their day-to-day coding. So what motivated you to go to the latest standard so early? Avoiding work. Because it was on the 17th, and it's a lot of work to port everything.

Like one question can take like one minute to just verify it's the same, or it can take an evening to figure out all the new stuff. So it's a lot of work to port it. And I never got around to port it to 20. And then people kept asking, can we please port it? C++ 17 is old now. And then I figured, okay, let's go straight to 23. Because I threw several person weeks of effort to port all of it.

And I don't really have a lot of time to spend on this. So in order to not do that twice, we just went straight to 23. But someone brought up the argument that we should do 20 because no one uses 23. But the answers to all but one or two questions would be

the same. It's just like the explanation is a bit different in 23 than it was in 20. And then I don't have to, three years from now, spend another several weeks to port everything again. Do you also incorporate new features, or is it just a matter of porting your existing database of questions? Yeah, when I port, I just port all the questions out there. I just dump everything to a GitHub repo.

Then people help out. Shout out to there's a user on github uh their username is talkic and they did a lot of the work so uh yeah thanks thanks for that um but yeah then we just port everything and we just dump everything back into the database and then but then that enables me to now be able to start adding stuff that's new that wasn't there before because sometimes i get submissions or ideas for new things but i can't do it yet because to say site is still on 17 or whatever so there's no c++ 23 specific questions in just yet but i don't think you added anything yeah so now we can that's it yeah i was just trying to think of

something i think there are a few nasty things with deducing this where like i was thinking that uh like it i mean not nasty it's a great feature but like it's a little bit odd if you haven't used it yet um so i think that's one where you could probably come up with interesting questions yeah is it is it more like language stuff that you do there or more like library stuff uh the language stuff at least is things i do because that's what i happen to find interesting and it's kind of timeless knowledge just like have a better gut feeling of how the language actually works when you try to learn something new or there's a bug or something and well actually i know how this works like one layer below the layer i'm trying to understand and it's a bug or something. And well, actually, I know how this works, like one layer below the layer I'm trying to understand,

and it's a lot easier to figure it out. But yeah, there's some library stuff as well. Right. Yeah, I don't think we have that many new language features in C++ 23, actually. I think deducing this is like the main one I can think of. Multidimensional subscript operator. Right, yeah.

Right. But that's kind of one where there's a bear trap that you could yeah could be maybe there is i just don't know about it yeah well given that it's come from c++ 17 um previously so you could have overloaded the the karma operator and now that won't work as of 20 and then in 23 it has a new meaning so could be something there but also but also you you haven't covered you didn't cover c++ 20 before so you could add stuff about like modules and concepts and core routines and yep what was the fourth one or the um spaceship operator the spaceship changes the meaning of some existing code, doesn't it? Oh, the spaceship operator. Yes, yes.

I have to say, I haven't actually used or seen it in the wild, the spaceship operator. You haven't seen a spaceship in the wild? I've used it just for some simple structs that just wrap some other type, and then they're just like spaceship equals default. That's, I think, all I've used it for. Yeah, I use it in some of my testing material. It's quite useful to be able to just quickly add all the conditional operators to a type.

Right. Have you run into any unexpected stuff with that yet, or does it just do what it says on the tin? I suppose sometimes it doesn't work the way I expected it to, mostly because I haven't internalized the syntax. But no, nothing that breaks anything. Well, that's good. Yeah.

So you mentioned that you had some time away from C++. Yeah. Was that before the last time you were on the show? Because I think you said in 2018 you'd just come back. Yeah, yeah, that's right. That's when I just came back after five years doing something else. So what brought you back? Did you get enough of C++?

The reason I went back to C++ was because I quit the other job I had after five years. It wasn't really going anywhere. And then I had done some C++ in the past, and there's a lot of cool stuff that happens with C++. Never a dull day. Yeah, but there's so many cool things people make with it. So I don't particularly think C++ is a great language. It's fine. It gets the job done.

Yeah, I think it's fine. For some definition of fine. There's the languages people complain about and the languages nobody uses. Yeah. And I don't have all the issues that people complain about with C++ all the time. I don't think they come up day to day that much, that they really annoy me that much. So I think it's fine.

But people do so many cool things. So when I quit my job and wanted to go back to doing C++ i interviewed with a lot of companies in in oslo like people i ended up in civet doing 3d cameras uh which is uh lots of really cool stuff to do and then like we have cisco in oslo doing all their video conferencing stuff and uh cute is in oslo remarkable that they weren't then but like there are so many cool things to include os they didn't have the chance to hire anyone but that was the coolest interview i've been to so if you're not familiar with include os it was a project where you just like basically say hash include os at the top of your file you compile it and it becomes an operating system yeah that

runs your code wait what it's like uh it's a micro kernel or whatever they call it the thing you just compile your program into like an image that you can run and it only has the part of the os that you actually use you can run on what on a like a on a virtual machine hypervisor or like whatever you can have like you make like a network switching thing in c++ and you just compile it down to an os that can run on a vm and the entire os is then like 14 kilobytes or something including your application and it has zero zero attack surface there is no bash there is no nothing right so you can't really attack it either so it's it's pretty cool and it can boot in like 10 milliseconds whoa whoa whoa okay okay wait wait um okay i guess i need to look into that like how does that work like do you need

like a kind of a kernel that does stuff is that just all completely modular is that like based on linux is that like written from scratch what is that i think most of it that written from scratch? What is that? I think most of it was written from scratch. They had a bootloader and TCP IP stack and some web server stuff and kernel and everything. Then you just

compile your program and you link it and everything you don't use just doesn't get included. There's nothing more to the OS than exactly what you use in your program program so it's it's pretty cool they went under uh they due to lack of funding oh no at some point uh but that was a really cool uh project yeah episode 63 back in 2016 was all about include os all right go listen to that one if you want to know more all right yeah yeah that's cool what i was was saying was like why c++ it's just because people do so many cool things with it that's basically uh why i keep doing c++ yeah no i think that's one of the things that keeps me motivated as well just this week we had a um so i live in helsinki

we have a monthly meetup here that I'm running. And like every month we are somewhere else, right? And depending on who can host us. And this week we were at Remedy, which is one of the big video game studios here. And obviously they do everything in C++. And just being there and then like seeing how they develop like really cool video games.

And I'm like, yeah, okay. I mean, yes, you know, working with C++ sometimes it's painful but that's what comes out like how cool is that yeah you can't really do that on that scale and like in another programming language that's pretty cool remedy that's the old demos in people or it used to be at least i think uh i mean the games that they did were it's like was it uh max pain alan wake yeah yeah there are some people from the 90s yeah i think i think yeah yeah i've actually been approached by someone i can't talk too much about it because it's proprietary but um they want me to do some training for people who have been doing c-sharp and they want to learn c++ and they're going to port all that code base over. So some of that's going in the other direction. It's quite interesting. So porting something from C-sharp to C++. Yes. Why would you want to do that?

I presume the performance matters in the particular industry that they're in. That's usually the reason. Right. That reminds me, Anders, you actually mentioned when we were preparing this episode, you mentioned that you actually also recently imported something from Rust, I believe, to C++. What was that about? Why would anybody do that?

To get a click-baity title for a podcast. No, the idea was that we had a new thing that we were using internally, and someone prototyped it in Rust because they like Rust. And I think it's also because that's the language where they knew how to make a user interface because they happen to know a library. And then that was proving that we should try to do this thing.

And then we wanted to make it more integrated into all the other stuff we do. And we integrate a lot with the LLVM and that's a C++ API. So we just figured it's easier to do our thing in C++ as well, because it's a startup kind of thing. So we have to do things quickly and then like, okay,

so let's just use those LLVM types internally in our entire system instead of wrapping everything and like making a nice API boundary like we don't have time to do that kind of stuff we just need to get something working quickly and then just embrace LLVM and then use

the C++ types so that was the reason and that worked out fine but I think it was also nice that this other I did it in Rust first because that's worked just worked out fine but i think it was also nice to that uh this other i did it in rust first because that's what he wanted to do and just previous point and then like okay let's do this and then we fortunate to see plus yeah i mean this reminds me of kind of something that somebody said whom we had on the show i'm not going to mention any names but like a conversation i had recently about how this whole thing about safety maybe is

a little bit kind of misunderstanding what c++ is about it is really all about the performance right because it lets you do things that like you could maybe do with c and assembler but that doesn't scale in the same way because it doesn't let you it doesn't have these abstraction mechanism mechanisms that c++ has yeah and and that's really what the language is about and and like there is an opinion which is not the majority opinion right now i guess if you read the the news at the moment or like if you look at the news items that we had lately but it is an opinion that some people hold that i kind of can sympathize with is that you know trying to make c++ memory save or like adding all of these checks

and making it more like Rust with like the borrow checker or whatever. That's not what C++ is about. You know, if you want to do that, just go into Rust, you know, C++ is about performance. So I think I can get behind that. I don't know if the US government can though.

Yeah, it's also like not only about performance with what you use it for so this thing that we're doing here is like we have to memory map a lot of stuff into these exact places in memory and there's a jit so we jit our own assembly language over to x86 and we execute some stuff in a jit and that can do whatever it wants like and that the simulated process has access to the simulator so we can like modify each other's memory and like i don't care if someone writes outside of a vector boundary or something that's not that's not one that's what's gonna cause me bugs uh like there are way worse things going on that's gonna cause a bug so i don't really need memory safety that much for

this particular project i think so i think it's very similar to the kind of things that i you know was working on in the past or have seen how things are made like if you're writing you know a piece of music software or a video game or even an ide i guess like the bits that are actually safety and security relevant but you like log in and talk to the server they're not written in c++ anyway right they're like kind of written in something else and then when it comes to like rendering things uh or like the stuff that has to be fast if it crashes occasionally that's not great but like kind of the that's not the main focus the main focus is to make it fast right the main focus is to render as many frames as possible so it looks cool and if you can't do that you're not gonna you're not gonna have a product right so maybe that's kind of what

zsus is about i don't know it's difficult to say because it's obviously also used in lots of like critical infrastructure and like operating system channels and telecommunication and whatever um yeah i don't know let's not get into this whole safety discussion again it's kind of a bit like a a black hole it keeps sucking you in because everybody everybody talks about this all the time yeah well let's change the topic a bit then because um and as you were a speaker at sea flood bus on sea this year yeah you're talking about symbols yes which is a an interesting take i mean what is it we need to know about symbols? Why did you feel you needed to give a talk about it? It's like most of my talks is just I'm at work and I need to figure something out.

And I discover some corner that hasn't been talked that much about. And like, this should be a talk. And so, yeah, if I come back next year, it's probably going to be memory models because that's what I'm working on now. Okay. And it's like, I like to figure out how something works and then submit a proposal for a talk about it because then I really have to understand it properly. So for me, it's like the best way to learn something. Yeah, I've done that before. Yeah, and the symbols thing was just because we also had several really weird things going on

with symbols in the place i used to work back then and uh when i wrote the talk and just figured out this is probably useful to some people and a lot of people have said things like oh so that's how it works now i understand this error message or or oh now i think i'm linking these things wrong or like yeah so so you said you have some some weird stuff happening with symbols can you say any more about that more specifically yeah so one thing was that we were shipping a library and we were using some other library that we included and then we had some cmake stuff to make sure we hide all our symbols. But then we didn't compile that other library entirely ourselves.

So they had already exported some symbols. And then when we linked them, they were still exported and then they leaked out. So I don't remember the library, but then users had a different version of the same library. And then they sometimes found our version of the symbol and sometimes found their own. That was the easiest one to explain the other one was just because we were linking all our subprojects in a stupid way so some some things ended up both in the executable and the shared

library that we were using so like the global logger pointer you had suddenly two instances of the global logger pointer and then only one two instances of the global logger pointer. And then only one of them were initialized. And depending on like which code path you took to get there, you get like one or the other. Yeah, I've been bitten by that one. And then there was a CppCon talk saying like, this is how you solve it. So then we did that. And then it turned out that didn't work on Windows. It was, yeah, it was when you take, you put an inline pointer in your header file instead

of having it in this.fp file, then according to the standard, then you should only get one copy of that symbol. But the standard doesn't know about shared libraries. So like what happens if you have one of them in your executable and one in the standard and the shared library, then like, well, according to toolchains on Linux, you get only one, but according to toolchains on Windows, you get two. Yeah, I have been bitten by that

in the past in real projects. And it's not very easy to fix either without re-architecting a lot of things. Yeah, most of my talks are just I have to figure something out and then I turn it into a talk

hoping that others will benefit from the same. Thank you for that. That's like a public service because I don't think we get enough talks about these sort of things, but we do tend to get bitten by them. Both Tamer and I said

we've been bitten by that one. Yeah. Keep it up. Looking forward to been bitten by that one. Yeah. Keep it up. Looking forward to your memory model talk now. Yeah. Oh, you have a memory model talk? Yeah, I did one at NDC Tech Town. Oh, I missed NDC Tech Town this year.

I'm so sorry. Like, it's such a cool conference. I didn't make it this year, unfortunately. Yeah. Yeah, so on the topic of, like, being an ambassador for us, though, I think NDC Tech Town is a very cool conference to have in a small place this year, unfortunately. Yeah. So on the topic of being an ambassador for Oslo, I think NDC Tech Town is a very cool conference to have in a small place like this. Yes, I can confirm.

I was there once and I had a great time and I hope I can come back again. It is a pretty awesome conference. Although technically, of course, it's not in Oslo itself. No, but for everyone who's not from Norway, it's in Oslo. But for us, it's like far away.

It's like an entire hour on the train. It's really far from Oslo. Yeah. I think it's closer to two hours. Yeah, maybe it's like one and a half hours. But from the airport, it's a bit longer. But yeah, one and a half hours maybe on the train. But it's a lot of Oslo people going there because kongsberg is a very very small town

oslo is kind of small but kongsberg is a lot smaller yeah okay so we talked about a lot of stuff uh and i think it's time for our traditional closing question which is is there anything else in the world of civil stuff going on right now that you find particularly interesting or exciting i kind of i'm looking forward to the senders receivers kind of thing i haven't properly read up on it yet but i we mentioned earlier i was doing something else for five years and that was mainly c-sharp and a language that we were developing as well so we did a lot of rx and observables and and stuff so i think for the right use case i think that approach is really nice yeah so i'm looking forward to that and uh also pattern matching uh because i i haven't done rust for

like six or seven years i did it for a few days only but like that was one of the things that was like this is really nice we should do something like this in c++ and then right then now it's coming so i think yeah those are the things i'm excited about. Otherwise, I tend to just in time learn C++ things. That's how it should be, really. Yeah, I mentioned we're a startup, so we have done DevOps. It's super simple. We're always on the latest Ubuntu

and then get whatever tools are there because no one has taken the time to do something more fancy. So just recently I got deducing this. I'm like, yeah, now I can write one overload instead of two overloads and i'm like yeah but yeah centers receivers and and pattern matching and uh yeah otherwise like i'm looking for something i also find cool is uh is the circle stuff that the short vector is doing it's just like so impressive what it's doing alone uh so i just whether any of that will ever land in c++ i have no idea but i just follow it with a interest because it's cool yeah absolutely yeah that's interesting i think you're one of very

few people this year who haven't mentioned reflection so thank you for that um it's interesting that you mentioned pattern matching because I'm not sure it's actually going. Yeah, I think that's less likely to make it into 26 at this point. I think we'll have to wait. It's not off the table yet. It's not off the table, but I think it's becoming increasingly unlikely we're going to get it in sixes.

I haven't been paying attention. But yeah, I think senders receivers are already in a working draft. And I mean, there's already kind of a bunch of libraries just out there that are doing things like that. We had an episode about that. I think my prediction is coming true that senders receivers can become the new coroutines in terms of all the conference talks and things about it. And lots of interest, even though nobody really understands it. Yeah.

Yeah. I mean, I have to say, like I said this before, like I find it really hard to understand. And I think when we did the episode on the topic, we got feedback from other people who also thought like, I don't understand how this works. So I think there will be definitely a need for people like the two of you, just kind of breaking it down and explaining to everybody what this is actually about,

because it seems like it's a really powerful tool going to make things a lot easier, but it's just not. Like the learning curve is not particularly, how do you say? I think we need the second wave of talks, I think, to start to make it more accessible. I think like for learning a lot of these things, like I don't really, I haven't looked much at Co-Routine either, but all of this thing, I think it's easier if you have done something similar in like C sharp or JavaScript or something where it's just like, it's a lot easier because you have garbage collection and other things that can like make the implementation less mysterious kind of. And if you have like,

then you kind of have the intuition that you can, it might be easier to learn it than just trying to learn it from scratch in super plus. Yeah. It's, I mean, for me it's difficult because I come from audio where you just have callbacks you just pass pointers around you have callbacks this is the world i come from

so i i know how to navigate that but anything that kind of does something else kind of breaks my brain a little bit it's just very hard to for me to understand yeah we we used a lot of rx in in c sharp and a previous job and like the entire domain model and the UI was like everything was like reactive and debugging became super hard this button is suddenly disabled why like no one knows

you just try to put a breakpoint and like it is somewhere into some Microsoft DLL that's where the call came from and it's really great for some things, but it can definitely go wrong as well. It's probably going to be even harder in C++ because it's harder to make it work correctly

and it's harder to make tools and everything. It's just harder. Okay, then I think it's time to wrap up. So is there anything else you want to tell us, Anders, where people can reach you or how they can get involved with cpp quiz yeah so to reach me just uh i'm on like all the social medias like waiting for one to win uh so macedon and blue sky and twitter and yeah so you can just find me on any of those places yeah and if you want to get involved with cpp quiz then uh there's it's the code for

the site itself is on github and we have some open issues that would be good to get some help with especially around porting to django 5 and stuff so if you know python or django don't hesitate to just pick up some small issues to get started with like making an rss feed and uh yeah some simple things and some more complicated stuff as well. I might actually have a look at that myself. Yeah, cool. Okay, well, thank you for joining us today, Anders, and telling us about your new book.

There'll definitely be a link to, in the show notes, cppquiz.org, of course, and all the other stuff you've been working on in C++. Thanks for coming on. Yeah, thanks for having me on. Thanks so much for listening in as working on in C++. Thanks for coming on. Yeah, thanks for having me on. 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 that 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 it if you can follow CppCast at CppCast on X or at Mastodon at CppCast.com on Mastodon and leave us a review on iTunes. You can find all of that info and the show notes on the podcast website at CppCast.com. The theme music for this episode was provided by podcastthemes.com.