CppCast - Cache Friendliness

Episode Date: December 4, 2019

Rob and Jason are joined by Björn Fahller. They first discuss articles on the C++ ABI and a blog post on performance analysis. Then Björn talks about cache friendliness, C++ contracts and type safety. News C++20 and ReSharper C++ Clang-format tanks performance Some intricacies of ABI stability Links Programming with Contracts in C++20 - Björn Fahller [C++ on Sea 2019] Type safe C++ – LOL! :-) - Bjorn Fahller [ACCU 2018] Sponsors Backtrace Software Crash Management for Embedded Devices and IOT Projects Announcing Visual Studio Extension - Integrated Crash Reporting in 5 Minutes JetBrains

Episode 225 of CppCast with guest Bjorn Fahler, recorded November 26th, 2019. This episode of CppCast is sponsored by Backtrace, the only cross-platform crash reporting solution that automates the manual effort out of debugging. Get the context you need to resolve crashes in one interface for Linux, Windows, mobile, and gaming platforms. Check out their new Visual Studio extension for C++ and claim a free trial at backtrace.io.cppcast. And by JetBrains, makers of smart IDEs to simplify your challenging tasks and automate the routine ones. Exclusively for CppCast, JetBrains is offering a 25% discount for a yearly individual license, new or update, on the C++ tool of your choice, CLion, ReSharper C++, or AppCode. Use the coupon code JETBRAINS for CppCast

during checkout at www.jetbrains.com. In this episode, we first talk more about C++ ABI stability. Then we talk to Bjorn Fahler. Bjorn talks to us about cash friendliness and the future of C++ contracts. Welcome to episode 225 of CppCast, the first podcast for C++ developers by C++ developers. I'm your host, Rob Irving, joined by my co-host, Jason Turner. Jason, how's it going today? I am doing all right, Rob. How are you doing? I'm doing fine. Looking forward to the upcoming holidays.

Although we should mention that I think this episode will come out after Thanksgiving if you're in the U.S. We'll probably be missing that week. But we will be back for December. That's reasonable. Yeah. I am, well, since this will be airing then, currently in the Czech Republic. And Bruno having just finished one set of training on the trip that I'm currently on. Do you have any plans for what you're gonna do for thanksgiving while you're abroad are you trying to celebrate it in any way

yeah my mom actually like asked where we're gonna be for thanksgiving and i'm like i i don't even know and then i decided i'll be in prague okay and uh she told me she's like oh well the last couple of years that we've been in europe for thanksgiving we managed to find turkeys and i'm like to me it really just doesn't matter that much um i'm gonna be doing a day of training and then i'm going to relax okay and that'll be my holiday right like uh i mean it's it's not it's just i don't know yes i always celebrate thanksgiving as an american when i'm home but when i'm traveling, it's going to come up. It just doesn't seem like that big of a deal to me. No need to go through the extra effort to try to find a turkey or something like that. No, no. And that's just ridiculous. Cooking a turkey at an Airbnb for the two of us

makes no sense at all. Yeah, I agree. What about you? Big family plans? No, I think we're just doing Thanksgiving local here this year. My family's going to come by the following weekend. Oh, okay, so also relatively quiet. No Friendsgiving or whatever? I don't think so this year, no. Well, enjoy.

Yeah, thank you. Okay, well, at the top of every episode, I'd like to read a piece of feedback. We got a lot of tweets after last week's episode uh this one is from barney deller and he wrote two of my favorite tech topics collide on cpp cast c++ and systems thinking we have created an ecosystem of dependencies and it has unintended emergent behavior we now have old libraries that we can't recompile but that we depend on but now we can't update our core language to be faster or we'll no longer be able to use these old libraries emergent behavior is hard yeah um i feel like we could have gone into a you know we could have just kept that discussion going about abi for a lot longer and i look forward to seeing how the committee responds to uh to titus's proposal

when he does present that api paper next year well and i think we have a news item coming up today that definitely adds to this topic for me i mean we'll discuss that in a moment but yeah i still am strongly in the camp of well you should be in a world where you can rebuild the world because i mean depending on binaries that you don't have the source code to that's always going to be a problem it's bad it's real bad and one thing i thought of which i forgot to bring up when we had titus is it seems to me like the people who are depending on these old binaries and can't rebuild them are not necessarily the same people who want to jump on the new C++ standard, right? Makes sense.

Yeah, and there goes our guest. I don't think that's necessarily true, though, because you might have some business legacy reason that there might be three-quarters of the people who are ready to move forward, but one-quarter of the people rely on this old binary, and that's going to take a big engineering effort to get rid of it i've even heard about people who have some built library that they depend on but for whatever reason no longer have access to to the sources too so tough for them yeah i think i heard and i don't remember if it

was with titus or someone else mentioned maybe you lost the source right which hopefully that doesn't happen but i know it does i mean for those of us who are into retro gaming stuff we hear stories about like oh they found some old computer from uh team 17 or whatever who made worms and they found the old source code from that thing on the thing that's like been lost and forgotten for 30 years you know whatever like these things do happen but inside of it I'd really

hope it doesn't well we'd love to hear your thoughts about the show you can always reach out to us on Facebook Twitter or email us at feedback at cbcast.com and don't forget to leave us a review on iTunes or subscribe on YouTube. Joining us today, you just heard him, is Bjorn Fahler. Bjorn works for NetInsight where he wears many hats including mentor, trainer, troubleshooter,

networking protocol designer, software architect, and programmer. And he's continuously pushing the code base to increasingly modern C++. Programming has been his full-time profession since graduating from university in 94, mostly writing embedded software for networking equipment. Bjorn first experienced programming when home computers became popular in the early 80s, and it quickly became a permanent interest of his. Occasionally, Bjorn has been seen tinkering with unorthodox software constructs, pondering what can be done with this. He lives in Stockholm. Bjorn, welcome to the show again. Thank you for having me again. I have two questions from your current bio.

The first is, I don't believe in any of your conference talks that I have seen, anyhow, that you mention network protocol design. True. I haven't found much reason to talk about them. All my conference talks, or all of them, as if there were a lot, have been about programming issues, more or less generic programming issues. So in our conversation with Titus the other week, it was, he made this analogy between ABIs and network protocols. Now, a well-designed network protocol has a version number, and you know if you're talking the right version to someone else,

but our ABIs don't really seem to be doing that so much. Yeah, I guess that's largely why we are where we are. Right? Yeah. Well, the other thing that I was just curious about is this note that you graduated from university in 94. I graduated in 96, but I believe you are more than two years older than I am.

So I'm just kind of curious if you went to university later or if you have a PhD. I do not have a PhD. I was late into university, so I worked for a while doing electronics design. Oh, interesting. Do you still continue that hobby at all? No, not at all.

No, I have a multimeter that I can use to troubleshoot things, but that's pretty much it. Ah, okay. Okay, well, Bjorn, we got a couple news articles to discuss. Feel free to comment on any of these, and then we'll start talking more about what you've been up to, okay? Alright. Okay, so this first one is

a blog post on the JetBrains ReSharper C++ blog, and it's from Phil Nash, C++20 and ReSharper C++, and this is just going over how, you know,, C++20 and ReSharper C++. And this is just going over how with C++20 kind of more or less set in stone, you can start to test out some of the new features if you're using ReSharper C++ and choose to use the C++ latest option in Visual Studio. You can see some of the new features. And he goes over in the post aggregate initialization

and designated initialization and how you can see that and how it lights up in the IDE. That's pretty cool. Yeah. I wonder if this is like the first of a series of other C++20 stuff where he's going to go over or if it's just the first stuff that's available for testing out right now with the latest ReSharper. I feel like we saw an earlier article a while ago

about something else C++20 with... That's possible. ...Sea Lion, but now I don't know. Yeah, Sea Lion has... Oh, okay. It's currently in beta, I guess, the next version that will have some C C++ stuff, concepts among them. Okay.

And I think part of the difference here is ReSharper C++ is trying to keep parity with Visual Studio, specifically since it's a plugin for Visual Studio. Right. Okay. Next thing we have is a blog post on performance matters. Uh, and it's clang format tanks performance, which is a bit of a click baity title. Um, but in, in the post, he's doing some testing on, uh, calling two upper and finds that, uh, depending on your include order,

that performance could be altered significantly. This was pretty interesting. It was. My cousin who does Rust development sent me this article a few days ago, and I was like, what the heck? And I read it, and I haven't responded to it yet, actually. But yeah, that's...

It was an interesting read because you just got into more and more of surprises that kept popping up. But it turned out to not be so mysterious in the end. But it was a fun article. So for the sake of our listeners, if you include, let's see if I can get this right, if you include ctype before algorithm is included, then it basically breaks inlining of to upper.

Is that right? I think it was the other way around. If you have ctype first, then to upper is inlined perfectly. But if you include algorithm first, it defines some macro that is checked for in the C-type header, and it breaks inlining, yeah. Yeah. Weird. I mean, it's like a problem with having a macro-based include system, I guess, right? Copy and paste of these things.

Yeah. It makes me wonder if it'll kind of accidentally be fixed when we, in what, C++ 23 or whatever, get the... Modularized library. Modularized library headers, yeah. Yeah. Maybe. Let's hope

for that. That's great. So in five years, we'll all have a fixed version. Can finally do two upper in ASCII. Okay, and then this last article is a blog post on intricacies of ABI stability. And this definitely relates to the conversation we had last week with Titus. So this post kind of goes over what some of the problems are with ABI and then goes into one proposed solution where the author is basically suggesting that we could change the way we do name mangling

between ABI versions. So you wouldn't have one version of a function, you know, overriding, you know, breaking one definition rule with some other version of a function. Is that basically what this is saying, Jason? Yes, yes. And Clang and GCC

use the itname ABI specification with their mangled names. Visual Studio does a different name mangling. Right. So Visual Studio has to take some different approach i'm curious if bjorn if you have any opinion on this as well um i'm not sure i i happily live in this world where i where we always recompile everything so it's never been an issue for me personally um But yes, I understand what the blog post says about using the mangling to get a differentiation between the symbols in the different versions of the ABI. But that's pretty much the extent of it for me.

Okay. Well, with this proposed solution, it would either become a compile time link error because it couldn't find that or if it was some runtime loading of a shared library then we might get a runtime link error a runtime error if it can't find the symbol when it goes to load the dll or so or whatever or dilib right and that'd certainly be better than i guess what would happen now it should just be a runtime error when the ABI boundary doesn't match, basically. No, that's the best case scenario is a runtime crash.

The most likely scenario is undefined behavior land, and we don't know what state our application's in. Right, right. That's much worse. Yeah. Okay. Well, Bjorn, we wanted to have you on the show because we just saw that you were giving a code dive talk along with Jason recently, or along with Jason being a code dive. And you did a talk on cash friendliness, which seemed to be getting a lot of attention on Twitter, at least. Can you tell us a little bit more about that talk? Okay. Twitter at least. Can you tell us a little bit more about that talk? Okay, so this talk was pretty much a hands-on thing to show what cache effects actually are,

how you can profile them and see where you have bottlenecks, what is causing them, and see how you can model your software in a different way and see the performance gains that you can get. So this was, as I actually mentioned in the introduction to that talk, this is pretty much the talk I wish that someone had given to me many, many years ago, because I would have written faster software if I had. Okay, so what are some of the main things that you discovered or that you would like to convey? Okay, for everybody who is already aware of how to write with the cache in mind, this will not be anything new. But for those who don't, then, well, to begin with, this only works in languages like C++, where you have access to how your data structures are laid out in memory.

If you don't have that control, then there's not much you can do. But if you can, then rule number one is for small data sets and linear access rules. It's super fast. The problem is, of course, is to know how small is small. My experience typically is that depending on the size of your elements, but at least a few hundred elements is usually good for a linear axis. And related to that is to keep the working part of your data structure small. So if possible, you can maybe split your data structure small. So if possible you can maybe split your data structure into two parts. One part that you keep as

small as possible with data that is moving around and that refers to other data that is more or less static so that you will touch as few unique memory addresses as possible while you make changes to the structure. The one that is maybe surprising that a number of attendees said that they had never thought about this is that, depending on the system, if you have a data structure that is used here and there in a program that does a lot of things, then if the operations on your data structure will evict fewer cache entries,

that means that the rest of your program has more of its data in hot cache. So when you do this kind of optimization, it may actually be worth to choose not the best performer, but the one that evicts the fewest cache lines, which may not be the fastest one. But since that means that the rest of the program has more of its data in hot cache, the overall program performance can be better.

And one thing... Sorry, Jason. No, no, I was going to say that definitely surprised a bunch of people, including myself. Yeah, I hadn't thought about it. And another that surprised me, even though I actually knew about it, was that a mispredicted branch can still evict data from the cache. So that is Spectre for you. This can lead to extremely surprising results when you do the cache profiling and run and see how.

So I actually had this happen to me when I prepared the presentation and I found that Linux Perth showed that I had more evicted, more cache misses than I had data accesses. It's like, how is that ever possible? But that is because a misprediction led to an evicted cache line, but since it was a misprediction, it didn't count as a data access. So, confusion. And you showed this live, what, on like the fourth try,

it showed 106% cache miss or something like that? I don't remember exactly. Yeah, just over 100%. And yeah, that is pretty confusing. Right. And that is also a problem. Since I'm using Linux,

I use the Linux Perf for the cache profiling. And a problem with Linux Perf is the enormous number of counters that you can use to observe the system, and it's really hard to know which ones are good to use. So there was a short rant by Travis Downs, who wrote about this to Upper, by the way, about the Perf counters, what they mean, which you should choose depending on what you're looking for. So you also showed using Valgrind with its cache simulator. How would you compare its reliability versus the perf counters?

Well, it has two things going for it compared to perf. And one is that you can actually choose to simulate the cache that doesn't look like the cache on the machine that you're running on. So this can be useful if you're doing, normally do embedded stuff, you could do cross-compilation for another CPU, but you want to do your performance tuning with good visibility on your development machine. And then to just say that, yeah, by the way, for this run,

assume that we have 32-byte cache entries and a 4-kilobyte L1 cache, whatever, and set the associativity also. So that is definitely something that Vowel Green does a lot better, because Linux Perf will just tell you what the host CPU, what it has observed about the host CPU. The other thing is that many of the counters in Perth are, the granularity on where they are counted can be confusing. And I'm not sure how much of that is how the counters behave. I think there's a difference between counters,

but also because Perth uses statistical sampling. So, sure, if you have a performance hotspot, you will hit that hotspot often, obviously. But it may, for example, give you, say that you have a cache miss on an instruction that doesn't touch memory, which can be confusing. So you have to sort of interpret the results from Perth a little bit carefully and see where can this cache miss actually come from.

But the downside of Walgrind is that it's super slow. 20x slowdown is nothing special. It can definitely be worse than that. That is a showstopper for some people, depending on the nature of the application. Yes, exactly. But if you have isolated a small test program, a benchmark program that is tailored for understanding the cache behavior of your data structure, then yeah, maybe it definitely works. That was actually how I showed in this presentation the final version. I solved the same problem over and over and over again with

faster techniques. And the last one I used was a data structure called the B-Heap. And this B-Heap was originally developed with the aid of the Walgreens cash green.

Another comment you made during the talk that really stood out to me, and I just actually shared it with my students today, was you said, assume that any pointer in direction is a cache miss. Yeah, definitely.

Unless you have very specific information to the contrary that you know that this will be a hot cache. But yeah, as a rule of thumb, assume that JSON pointers means you're missing cache entries. Wow. I think most people think, ah, well, it's just an allocation. It's not a big deal. It's whatever.

But that sounds pretty important to me. It's not a problem if it is the occasional pointer that you must follow. That is not a problem. But if you're in HotPath, you follow different pointers all the time. Like when you're traversing a data structure, say that you're traversing a map, which is a red-black tree.

You're following pointers everywhere, and they are everywhere in memory. So there is no way a prefetcher can know where to read next. So every time you follow a pointer, assume it's a cache miss. So that really speaks pretty poorly of map and set and list and forward list. Yep. Okay. Do we know if the CodeDive talk will be available online eventually?

That is what I understand. There were two tracks on that conference that were live-streamed to YouTube, so they are already available, each of them as one huge video where you just have entries of where to watch for a specific talk. But I understand that all talks will end up on YouTube. Yeah, mine was live-streamed, which was quite the surprise to me when someone told me they had just watched the talk from Germany or something. I was like, wait, what?

Are there any other kind of favorite tips or anything from the cash-friendliness talk that you wanted to share measure measure measure measure measure it's uh it's what i mentioned now are just rules of thumb there which means that they will most of the time be worth something but occasionally they will be just plain wrong so you have to measure and and then try to figure out why you're observing what you're observing. Try something else. Try to measure again. See why do you observe the change that you're observing.

So it's that. Okay. I want to interrupt the discussion for just a moment to bring you a word from our sponsors. Backtrace is the only cross-platform crash and exception reporting solution that automates all the manual work needed to capture, symbolicate, dedupe, classify, prioritize, and investigate crashes in one interface. Backtrace customers reduce engineering team time spent on figuring out what crashed, why, and whether it even matters by half or more. At the time of error, Backtrace jumps into action, capturing detailed dumps of app environmental state. It then analyzes process memory and executable code to classify errors

and highlight important signals such as heap corruption, malware, and much more. Whether you work on Linux, Windows, mobile, or gaming platforms, Backtrace can take pain out of crash handling. Check out their new Visual Studio extension for C++ developers. Companies like Fastly, Amazon, and Comcast use Backtrace to improve software stability. It's free to try, minutes to set up, with no commitment necessary. Check them out at backtrace.io.cppcast. You also gave some talks on contracts earlier in the year, and I wanted to know what your take was when the feature was taken out of C++20.

Were you disappointed by that? Not really. I was surprised, yes. I did not expect that. But there were definitely problems with the contracts as they were specified. And I've said this to others who have asked that I don't have enough knowledge to be able to tell if those problems were such that they could be fixed in future updates or if it was better to do as now has been done to scrap them temporarily

and hopefully bring them in in 23 or something. What problems did you see that you hope they do fix if it ever comes back? Well, one thing that is just plain evil is that they said if you pass

a parameter to a function by value and you use that value in a post condition, then it was undefined behavior if the implementation of that function changes that parameter in any way. That is just asking for trouble. People will make that mistake. The validity, yeah, that is worth coming to also. The contract, the precondition and postcondition is something you specify typically on the interface,

because it's on the declaration, because it's an agreement between the caller and the implementation. So it makes sense to state it at the declaration. And now you have something where the validity of, or the legality, rather, of a postcondition that you state in the declaration depends on how the function is implemented. And bad things would come from that, absolutely. Another thing that is problematic is that the way they were proposed is that all preconditions and postconditions were checked inside the function body. So the code generated by the compiler to do the precondition and-condition check came first in the implementation for the pre-condition and last in the implementation for the post-condition. And the problem with that is when you want to test contracts, because normally you definitely – well, this is controversial. People will hate me for this.

But I would say that normally, if you have a contract violation, you don't want to continue program execution because you have just said that my function requires this to be true to be able to do anything meaningful. And it's not true. Therefore, there's no use continuing. And it's not really a good idea to throw exceptions either, because a contract violation is by definition a bug. And the person who wrote the buggy code is very unlikely to catch an exception and do something useful with that. So you don't continue. But then comes the issue, how do I test the contract then? Because you want the program to die, hopefully, with meaningful

information. So how do you test it? Well, you can say that yeah, sure, do instrument your violation handler such that it throws an exception. But since the violation handler is called inside the function body, it means that you still get a hard terminate if the function is noexcept. So that is problematic.

And also, this might be that I didn't quite understand this. So maybe it's not really a problem with the proposal as it was. But it was unclear to me how how shared libraries were to be handled if if they can be compiled with uh the different the thing with the proposal was that you can say this makes sense this is really good you can state your preconditions and post conditions on on a level so you can say for example in debug builds i want everything checked super expensive checks but in uh release maybe i just have super cheap checks as a sanity check to ensure that nothing is totally off and the question then becomes how how does a full program behave that uses shared libraries that are built with support for different levels? I don't know.

Sounds like an ABI issue. Maybe related. I don't know. But like I said, it's perfectly possible that this was actually adequately described. I just didn't understand it. Standard EC is not always easy to understand. Or almost never easy to understand. Yeah. Are you hoping that contracts do make it back into C++ 23?

Oh, yes, definitely. I do. So one thing that also to just to be clear, there's no necessity to have language support for contracts to be able to program with contracts. You can use it with libraries, etc. But I think it's good to have it in the language because then we can have it visible in the declarations, in the header files or modules. And also, when they are standardized, it means that third-party libraries will use the same mechanism. Everybody will use the same mechanism. Otherwise, you will see one library uses this solution, another library uses another solution,

and it just becomes a little bit messy. And also, when it is standardized, it means that you will get support from tools. So maybe IDEs will be able to just flag what the preconditions are on a function call or something such. It's going to be pretty neat, I think. Definitely. What contract libraries are you familiar with? I don't think we've ever talked about any third-party

contracts libraries. On top of my head, I actually don't know any. I think there is one in Boost. I think there is one in Boost, but I haven't used it. You can pretty much just say, there is one in Boost, and you're probably right. Yeah, that is almost always true.

Unless it's a GUI library. You also had a talk last year on type safety at ACCU. I just wanted to ask, what does that talk go into? Do you consider C++ to be a type-safe language? Yes, but with caveats. I mean, the built-in types are just terrible. Everything converts to everything, more or less. With a little bit of luck, you will get sane warnings.

But it's really bad for them. But if you think about it, if you write a class, which conversions are allowed to and from that class? Well, the ones that you write. Everything is forbidden by default. So when you write your own types, when you write your own structure or classes, then I would say that, yeah, it's really, really, really strong.

Unless you choose to open it up with implicit constructors and implicit conversion operators continuously frustrates me that the standard library has so many implicit conversions built in at least with w conversion i can get warnings if i'm doing float and 64 or whatever but between optional and shared pointer and file system path and string and const character pointer, there's so many implicit conversions in the standard library.

Yes. Do you have any solution? No, that is a problem. Frankly, it is. The only thing I can see is that, just as I say, that you don't want primitive types in your APIs, if you can get away from it.

You want your own specific types. And maybe we should treat the types in the standard library the same way that we create our own encapsulations of them with our defined semantic meaning, our defined conversions. But the problem with that is, of course, that it's a lot of work. It's a lot of typing. Something I was just discussing with my students and thinking about myself is

I did not appreciate that multi-parameter constructors and default constructors can be themselves marked explicit, and that changes the meaning in some cases. Yes. Do you have any thoughts on that? Like, should we make all constructors explicit? All is a strong word. Okay.

But I think it's a good default, yes, to do that. The thing that changes is that if, say, if you have a constructor that takes two parameters, say, and you mark it explicit, and you have an array of such objects, then you cannot initialize the array with each element just being curly braces. You have to save the type in front of everyone, which can be annoying, can be quite verbose, but it also reduces the risk for accidentally creating something

that wasn't what you thought it was. Right. But what this sort of comes to is that you can get surprisingly far with getting rid of a lot of the repetitive typing of pretty much the same thing over and over and over, but for different types, with library solutions. I believe it was Jonathan Miller who first started that with his TypeSafe library. I don't remember its name, if it was StrongType or SafeType. And then you have had, there are a number of follow-ups. Peter Somlad has one. Anthony Williams has one that I know of. I have one that is very experimental.

Other than to experiment with. one that I know of. I have one that is very experimental. Don't use it. Other than to experiment with. And I know of a few others also. And it takes away a lot of the repetition. There is some boilerplate unfortunately required because you

need tags, tag types to distinguish between strong types of the same underlying type. Okay. Which means that you either have to create a nonsense tag type or use CRTP. Both are boilerplate-y. And this library solution fails completely if you want to use them for more complex types, like std string, for example, because you have a huge number of member functions. And how do you make those visible in a way that does not require a lot of repetitive typing?

You just can't. Well, you could do something that inherits publicly from it, but that kind of defeats the purpose. I'm toying with the idea that maybe metaclasses can help there, but I haven't had time to dive into it. Our first earliest chance for metaclasses is 2023 at this point. We'll see what happens. So what you're saying is that I have a few years to experiment, right? Yeah, a few years. By the time you come up with the optimal solution,

there will be a different solution that's better. Yep, absolutely. But that doesn't mean it's not worth trying, right? That's how we advance our knowledge. Yeah, there's some things I've been playing with lately, I don't get into any details or anything, that within 200 lines of code

you can have something implemented that in C++98 would have taken literally thousands of lines of code when it comes to some metaprogramming techniques and constex for compile time things and type generation. Yeah. C++ 98 metaprogramming

was pretty painful. Yeah. And simply having variadic templates or whatever just makes so many things so much easier. Fortunately, the language seems to be getting better. Definitely. Okay. Bjorn, is there anything else you wanted to go

over before we let you go today? Yeah. If you're in Stockholm, come to our meetup. We have a pretty vibrant C++ community here. At the very least, get in touch and get a chance to geek out

with like-minded people. But why not propose a guest talk or sponsor us for that matter? And also a shout out to the – we have – originally it was Sweden CPP. That was in fact Sweden CPP is sort of an umbrella organization, in quotes, for the Swedish SQL Plus user groups. So go to swedencpp.se and see which is the user group closest to you and when they have events, meetups. If you want to start one and you're not living in one of those towns, get in touch so we can help you. Or for that matter, if you have a user group and you're not listed, definitely get in touch.

Do you have some specific meeting coming up in the next couple of weeks to tell the listeners about? I think I will actually have to look. I think Malmo is meeting tonight, right? That might be too late for our listeners. Yeah. Now, Linköping

is meeting on the 12th, December 12th. So, now you know. Go there. I will not be making it. Maybe Rob will. Probably not. I'm sure he will be very welcome there. Okay.

Well, it's been great having you on the show today again, Bjorn. Well, thanks for having me again. Thanks for coming. Thank you. Thanks so much for listening in as we chat about C++. We'd love to hear what you think of the podcast. Please let us know if we're discussing the stuff you're interested in, or if you have a suggestion for a topic, we'd love to hear about that too. You can email all your thoughts to feedback at cppcast.com. We'd also appreciate

if you can like CppCast on Facebook and follow CppCast on Twitter. You can also follow me at Rob W. Irving and Jason at Lefticus on Twitter. We'd also like to thank all our patrons who help support the show through Patreon. If you'd like to support us on Patreon, you can do so at patreon.com slash cppcast. And of course, you can find all that info and the show notes on the podcast website at cppcast.com. Theme music for this episode is provided by podcastthemes.com.