CppCast - foonathan/memory and standardese

Episode Date: June 8, 2016

Rob and Jason are joined by Jonathan Müller to discuss some of his recent blog posts, as well as the foonathan/memory library and the standardese documentation generator. Jonathan is a CS student passionate about C++. In his spare time he writes libraries for real-time applications and games. He is mainly working on foonathan/memory which provides fast and customizable memory allocators that are easily integrated into your own code. Jonathan tweets at @foonathan and blogs about various C++ and library development related topics at foonathan.github.io. The blog posts are well received and often shared in the cpp subreddit or ISO C++. News C++ Core Guidelines Checkers are now in a single Nuget package How to avoid wasting megabytes of memory a few bytes at a time Asynchronous callable wrappers Jonathan Müller @foonathan foonathan::blog() Links You (probably) don't want 'final' classes foonathan/memory foonathan/standardese

This episode of CppCast is sponsored by JetBrains, maker of excellent C++ developer tools including CLion, ReSharper for C++, and AppCode. Start your free evaluation today at jetbrains.com slash cppcast dash cpp. CppCast is also sponsored by CppCon, the annual week-long face-to-face gathering for the entire C++ community. Get your ticket now during early bird registration until July 1st. Episode 59 of CppCast with guest Jonathan Mueller recorded June 8th, 2016. In this episode, we talk about the core guideline checkers and memory alignment. Then we talk to Jonathan Mueller. Jonathan talks to us about his memory library and the standard ease documentation generator. Welcome to episode 59 of CppCast, the only podcast for C++ developers by C++ developers. I'm your host, Rob Irving, joined by my co-host, Jason Turner.

Jason, how are we doing today? All right, Rob, how about you? I'm doing pretty good. No real news for me, but we were just talking about how this is the last week to get CppCon registered with their early bird special. Last month. Last month. I'm sorry. Yes, last month.

You have until the end of June if you're interested in getting the early bird discount for CppCon. So that's definitely worth checking out. Yes. Okay. Well, at the top of every episode, I'd like to read a piece of feedback. This week, Rodrigo wrote in, we were having a bit of a Twitter conversation with John Carmack, and Rodrigo wrote in,

CppCast is my favorite tech podcast, and John Carmack is a legend amongst us game devs. Jason, you want to talk about this thing with John Carmack? It doesn't look like we might be able to get him on, unfortunately. I thought it would be a good idea to see if I could get Twitter to help me get John Carmack's attention to see if we could get him on the show. And it worked pretty well. I got more tweets and retweets and likes than I have with any other comment I've made. And we sent an official request to have him on the show.

But yeah, it doesn't look like it's going to go through. Yeah, unfortunately, it's not just up to him. He told us to go to Oculus Media Department email, and we sent an email to them, and unfortunately right now they're just too busy with E3 prep, but maybe we can get him on at a later time. Maybe we'll reach out again after E3 is done. Yeah.

Okay, so last week we had Anastasia kazakova on from jet brains and obviously they've been sponsoring the show for the last few weeks and earlier and we talked to her about doing something new and she agreed to it thought it was a great idea so this week we're going to give out uh a jet brains license to rodrigo for writing into the show on Twitter. And hopefully we'll be able to keep doing this. But basically we really appreciate JetBrains' support, and we love that they're able to give out some free licenses to our listeners. So we'll try to keep doing this to give out, to give out something to have rights into the show from our sponsor.

So, Rodrigo, I'll reach out to you on Twitter. And if you can send me your email, I'll forward that on to Anastasia. And you'll be able to get a free license to either ReSharper, C++, CLion, or AppCode. So, pretty cool stuff. We'd love to hear your thoughts about the show as well. You can always reach out to us on Facebook, Twitter, or email us at feedback at cppcast.com. And don't forget to leave us reviews on iTunes. Joining us today is Jonathan Mueller.

Jonathan is a CS student passionate about C++. In his spare time, he writes libraries for real-time applications and games. He is mainly working on Funathan memory, which provides fast and customizable memory allocators that are easily integrated into your own code. Jonathan tweets at FooNathan and blogs about various C++ and library development-related topics at foonathan.github.io. The blog posts are well-received and often shared in the CPP subreddit or ISO C++.

Jonathan, welcome to the show. Hello, Rob. Hello, Jason. Nice to be here. Thanks for joining us. So you're a CS student. What year are you in university? Oh, I'm actually, the bio I sent you was for my Meeting C++ application. I've not actually started yet. I'm starting this summer at university. Oh, so you're just going into your freshman year. I'm just going into my first

year, yes. Oh, wow. That's really impressive with all the work we've seen coming from you. Thank you. Okay, so we're going to go through a couple news articles, and then we can start talking to you about your blog and some of your libraries. Okay. This first article is from the Microsoft

Visual C++ blog, and it is about the C++ core guidelines, core guideline checkers, and how they're now available in a single NuGet package. So this just should make it easier to acquire the CPP core guidelines

if you want to use them from Visual Studio. And is there much else here, Jason, that you saw that's worth bringing up? There's some interesting discussion from users in the comments on that article, but no, it's just cool that they're getting things out there. Oh, and they also mentioned that Clang-Tidy has been following along with their core guidelines checkers. I don't think we've actually mentioned that before,

that Clang-Tidy is also implementing some of the core guidelines. Have we? Yeah, I don't think we've actually mentioned that before, that Clang-Tidy is also implementing some of the core guidelines. Have we? Yeah, I don't know. Okay. And we're actually going to have Andrew Pardot, who wrote this article on the show soon, so hopefully we can get a lot more information

from him about the C++ core guidelines. Yeah. The next one is from the Red Hat Developers blog, and it's how to avoid wasting megabytes of memory The next one is from the Red Hat Developers blog, and it's how to avoid wasting megabytes of memory a few bytes at a time. And this is about padding, which is something that maybe not all C++ developers are aware of, and this is a really good overview of what you can do

to take account for padding when creating new classes and structures. Definitely a good primer on that kind of thing. Yeah, is this an article that you read, Jonathan? I didn't read the article before you linked it to me, but I instinctively

follow the advice and just out of habit order my types and size just to be sure on that thing. I rarely think about it personally. I try to keep member variables of the same type organized to get a little bit of help with the padding. But one thing I wasn't aware of is these tools that you can use

to kind of let you know if you're having padding problems to better align your structures. So I mentioned the GCC compiler has the WPADDED option, and there's also POKEAHOLE. That'll tell you about padding holes, which is worth trying out. I hadn't seen that one. Also, it's worth mentioning that Clang has a padded, an equivalent warning level for padding. Also, it's worth mentioning that Clang has a padded, an equivalent warning level for padding.

Okay, that's good to know. Okay, and Jason, do you want to introduce this last article about package task? Yeah, it's just a cool article from Modernist CPP from Rainer Grimm. I'm probably mangled his first name. I'm sorry. Thank you, Ryan. Rainer. I am not a native German speaker. I am. It's Reiner. Reiner. Okay. Thank you. Anyhow, he's just he's given a couple of articles on overviews of modern, multi threaded stuff and C++ 11 and forward with package task.

And there's a follow on one with futures. And I just thought they were good articles to call attention to. Okay. Well, let's get started talking with Jason. Jason, actually, you wanted to. I'm sorry. We're going to start talking with Jonathan. And Jason, I think you wanted to ask the first question. Yes.

So I'm curious. Most of the interviews that we have had on lately are people who learned to program in the 80s with their Z80s and assembly language and that kind of thing. And since you mentioned you're just getting ready to go into university, I'm curious how you got your start programming. How I started programming? Well, a couple of friends of mine did some stuff with HTML. So I looked into that. But I didn't find it much interesting, so I wanted to write real programs. So I actually went to the Wikipedia page for programming language, and there was an image of C++ code.

So I just decided to start learning C++, and that's how I started to learn C++. It was five or six years ago. And that was basically your first programming language? Yeah. So five or six years ago, that puts you at 12 or 13? What? Five or six years ago, that puts you at what age? Like 11, 12, 13? I was 12.

12, okay. So you learned C++ completely on your own. How did you go about it? Did you read online or you got books? I read many things online, and to admit it, I quickly go to C. But then I went back half a year later just because the book I've bought about game programming teach me C++, and I had this really bad C++. My first game used to crash because my pointers were wrong so it had double deletes at the end and

then just crashes when I wanted to close it because I didn't actually implement a shared pointer, I implemented something similar but it didn't work so and it took a really long time until I finally learned proper C++. And I must admit, Rainer's German C++ book actually taught me about Ray. Oh, okay. Which was interesting when I one day thought that he started following me on Twitter. Oh, that's cool. I did not realize he actually had published books. Yeah, I read his book about C++11. Okay, cool.

So you haven't done any programming in high school yet? Everything's been on your own? In the German equivalent of high school, I visited an informatic course, that's called, but it was nothing too serious. Okay, interesting. Let's start talking about one of your recent articles It's been getting a lot of attention on the C++ subreddit

You probably don't want final classes What were your opinions in this article? Well, as I write library, I try to make my code very generic And one easy way to do this is to use policy classes I use a lot of policy classes, especially in memory. And they are often empty, so I store them by inheriting from them to benefit from the EBO,

which allows you to have empty classes actually take up zero size, which they don't if you just have them as normal variables. But the problem with inheritance is that it requires... So the final is that you cannot inherit from it. So you cannot use EBO on that matter. So I forbid final on my policy classes in order to efficiently store them. Okay.

And then I started thinking, if I forbid final on policy classes, I mean, there's no need for it to do it on classes without any virtual functions. It's unnecessary there because every C++ developer is taught early on that you shouldn't publicly inherit from classes without virtual functions and a virtual destructor. So it's unnecessary there. And since I'm not using so much polymorphic classes i didn't really see a reason for them there either so i thought it was a reasonable argument to forbid final on to not use final on classes so i wrote this blog post published and shared it thinking and you got a lot of

go ahead yeah no just yeah yeah you got a lot of feedback from ahead. Yeah, no, just... Yeah. You got a lot of feedback from it, then. Yeah, on Reddit, a couple of people made the point that Final can benefit you from an optimization called de-virtualization, where the compiler can better see that you need to call the virtual functions, but can statically call the appropriate type. I was aware of the optimization but my main point

wasn't against the polymorphic classes but against the non-polymorphic classes. I didn't mention it in the article. John Karp actually commented on my blog post and made the good point that one Scott Myers guideline is that you should make non-leaf classes abstract for reasons he outlined in this book. And non-leaf classes are leaf

classes, if you make leaf classes final, it is ensured that they stay leaf classes, that they stay leaf classes, it is enforced. So if you use final on leaf classes, you're basically enforcing Scott Me's guideline, and only the non-leaf classes which aren't final are then abstract, so to enforce the guideline, but again, this was with polymorphic classes, where I just didn't saw a reason

at the time about this article, but then someone on Reddit, I forgot his name, made a really good point, he asked me if final was default, and I mean it should be default because non-final is a wider contract than final. So final should be default. It's the same with constness, but historical reasons.

So I made the good point that if final was default, would I advocate for putting the non-final keyword on every class, which is basically the same as I advocated in the article, just the other way around. And it got me thinking, and I realized that I wouldn't advocate for it, because then I would have been used to final classes everywhere.

And I realized what the real problem was. The real problem was that the empty base optimization EBO is such a hack that it should be changed instead of enforcing or prohibiting finer. That someone should do something about the EBO, maybe an attribute or a magic library class or something like that that uses EBO even without finer. So unless a mistake in EBO even without Finder. So unless I'm mistaken, EBO is something that the compiler is allowed to do, but the standard doesn't really enforce it or anything, right?

No, no. It's a common optimization in GCC and Clang. Okay. The compiler can do it. For those that don't know, an empty class in C++ has size 0, has size 1, because all classes must have at least size 1.

But if you use it as a base class, the compiler is allowed to optimize the object out so that it does not appear in your code and doesn't inquire the robot. Right. I'd like to interrupt the discussion for just a moment to bring you a word from our sponsors. ReSharper C++ makes Visual Studio a much better IDE for C++ developers. It provides on-the-fly code analysis, quick fixes, powerful search and navigation, smart code completion, automated refactorings, a wide variety of code generation options, and a host of other features to help increase your everyday productivity. Code refactorings for C++ help change your code safely, while context actions let you switch between alternative syntax constructs and serve as shortcuts to code generation actions.

With ReSharper C++, you can instantly jump to any file, type, or type member in Solution. You can search for usages of any code and get a clear view of all found usages with grouping and preview options. Visit jb.gg slash cppcast-rcpp to learn more and download your free 30-day evaluation. So let's talk a little bit about your memory library. What are your goals with this? My goal is to provide a library with various allocators that you can very easily use inside the STL or your own code, so that everyone gets the benefit of custom allocators very easily, and it already provides some more difficult allocator implementations. So what kind of allocators do

you provide then? I currently have the common adapters, so you have an allocator that uses malloc, and one that uses new, and one that uses fancy OS allocation, and a couple virtual memory allocators, but also the more complicated pool allocators and stack allocators. But it also has a lot of related infrastructure, because I'm defining an entirely new allocator model. I'm not using the STL one I've defined my own raw allocator and then I have the infrastructure you need for that I have a trades class, I have various adapters to use it with STL containers or smart pointer deleters And then I have storage classes like a type-erased reference or a normal reference

But it had the optimization if you have an empty allocator, it uses EBO so that the reference doesn't actually store anything, which was the main motivation for the aforementioned article and things like that. Maybe we should take a step back for maybe our listeners who don't know. The standard library allows

all the standard containers to have custom allocators passed to them, right? Yeah. You have this parameter for you can pass an allocator with. Okay.

But the standard library doesn't actually give you any allocator options? It just has one default allocator? It currently has only one default allocator which uses new. I think it's required that it uses new. But it doesn't actually provide its own allocator. So far, the polymorphic memory resources will come in C++17,

and they will provide things like pool allocators, but for now they don't have any own allocators. Oh, I didn't realize that was coming in C++17. I recently noticed it was in cppreference.com. Okay. And the reason I'm not using the standard allocator model, but instead I've defined my own model with a different required interface and then adapters,

is that the standard allocator model is complicated. It doesn't only care about allocation. It also takes care of construction and destruction of elements and has all this propagation parameters and stuff about two blog posts about. And I just wanted a simple allocator

that just takes care of allocating raw memory, not constructing any elements, not propagation, not comparison of the allocator for very advanced stuff, but just allocation. So I designed the RAR allocator model that just takes care of allocation and nothing else, unlike the allocator.

And it also has the benefit that it isn't dependent on any type. So you can use the same allocator for ints and floats when they have the same size and not two different allocators. And not everything needs to be templated and complicated, and it's simplified. It's similar the way the polymorphic memory resource TS is organized, for those who know that. But it is compatible with the standard containers? It is compatible through an adapter class. So you don't put my calculators but the adapter

which forwards. Oh, okay. You have adapters for smart pointer deleters and stuff like that, so you can use it. So what compilers do you currently support? I do currently support GCC 4.7 or so, and Visual Studio 2013 and higher, and some Clang, I don't know. Oh, okay.

The big three. Hmm? The big three. Yeah, yeah. It's tested on there. I might support other compilers, but I don't know. But I have taken care that Mal library must not depend on the standard library and can work completely without exceptions.

Oh, that's interesting. I cannot use exceptions on the standard library. That makes it more attractive to game developers who typically avoid exceptions. Oh, you said you work without exceptions. I was going to ask a question about that. I can work without exceptions. I was going to ask a question about that. I can work without exceptions. I throw an exception by default, but it is wrapped in a macro, so you can remove the throw and instead

it will just call a handler function, which then must abort or continue. Yeah, that's what I was wondering. So, yeah, if it tries to call malloc internally and gets back a null pointer, it gets a null pointer, it throws an exception, but wrapped in a macro. And if you compile without exception

support, it will call a handler function and then abort if the handler function doesn't do anything. You know, that's an interesting way of handling doing non-exception support that I'd never considered. Yeah, I wanted to write a blockbuster about it, but I don't have the time. Have you gotten any feedback on the library?

I have a couple of feedback on Reddit, especially in the game, the feedback. Many people seem to like it. That's great. I'm curious about your pool allocators. What's your threading story?

Do you have built-in thread support? Do you have any safety? The allocators currently are not thread-safe. For example, my memory pool, it is not thread-safe. But if you store it, for example, in

the class, the allocator reference class, which takes an allocator and stores it by reference appropriately, it is locked via mutex. So there's external locking for the allocators, but the allocator per se is not thread-safe. I'm planning on doing a

lock-free allocator, something like that, or a thread allocator in the future. But I was focusing on other issues. Sure. But anywhere you use an allocator where you need reference semantics, which is basically everywhere because my allocators are only required

to be movable. So if anywhere you want to copy you cannot store it by value but instead have to use it by reference and then I recommend allocator reference because allocators that are empty are not stored at all due to the optimization. Not even a pointer to an empty

which means that you can just create a few storeware reference. You have to keep the allocator alive, but for the empty allocators, like the malloc allocator, you only need to temporary is enough because internally it isn't stored

at all, but just constructed whenever needed. And this is a nice application. How easy is it to... I'm sorry. all, but just construct it whenever needed. And this is a nice application. How easy is it to... How easy is it to get started with the memory library with an existing code base? You can...

I'm sorry, I don't quite understand your question. I mean, just, you know, if you're integrating the library into an existing code base, how much effort do you think that would take? Is it just a header file include, or is it a library to compile? Oh, yeah, it's a library to compile. You can use CMake and install it or use it as a subdirectory,

but C++ building, it's a unified build system. I hate CMake. It's horrible. It's horrible. It's horrible. And then you can, it is very easy because you can just, you drop an allocator into your STL classes and then you can use it. You just have to

wrap it inside an adapter and there are convenience type tests in my library for that. So. Okay. If you wanted to. Yeah. If you wanted to have multiple containers that all shared the same allocator to provide contiguous memory that's something that's possible

sure you just there's there's an example but for allocator users but you first create the allocator a separate object and then you pass it to all the

containers that need it and internally they store a reference to that because you might want to copy an allocator so it cannot use the allocator itself but the reference and yeah okay so you just create the allocator and then pass it to all the objects that need allocating.

I might see places where I could use that. You're welcome. Thanks. Okay, and you just recently started working on another library. Do you want to tell us a little bit about Standard Ease? Standard Ease isn't really a library. It's a tool. It's a c++ documentation generator similar to doxygen um i was using doxygen for memory but ran into a couple of limitations

that so i needed to put macros into my hada files so that doxygen sees different source code than the actual source code because it cannot handle some things. For example, I'm talking about EBO again, but since everything is designed around allocators in memory, I use a lot of EBO. Basically, every class uses EBO because every class can take an allocator. For example, the pool

allocator itself takes an allocator which controls how the big underlying memory block is allocated. And this allocator is stored directly as base class to benefit from EBO. And Doxygen doesn't really have a way to hide those classes because they're implementation details

and you don't want to see them as base classes listed in the documentation. So I have a macro for that which hides them on Doxygen and I have other macros. And I just wanted to write a documentation generator that can handle the source code exactly as I write it and can hide inappropriate things and basically knows a lot more about C++ than Doxygen does. So I've started working on it recently. It is currently back in progress. I would have released version 0.1 but I'm currently writing on the release blog post,

so I think by the time this is released, it will be released as well. And this is just very basic. The frontend has much improvement and can parse a lot of C++. Basically, my entire library is parsed properly, and there are probably some corner cases I've forgotten, but it uses libclang for parsing, so it's robust, and it currently only supports a markdown output because I was focusing on the frontend first before I started adding multiple outputs, but it works really well already. Okay.

It's a basic prototype for what's coming. but it works really well already. Okay. Basic prototype. So you're using libclang. I'm curious if you implemented it in C++ or Python or something else. I've implemented it in C++, yes. I don't know Python. There's been a lot of discussion on Twitter about how the Python bindings for libclang are more accessible, easier to use than the C++ bindings? I don't know.

I went into a couple of issues with the C++, with the libclang bindings. Either I'm doing something completely wrong, or there are some weird bugs in there. I don't know. But I had to put a couple of work around there, and I detected

it's a bit tricky to get working. And there's a lot. I still need to do manual parsing because it doesn't give me all the information I need. For example, whether a constructor is explicit or a function. No, except this information isn't given to me. So I have to manually parse the appropriate source code to look for an outsept on explicit and the right place. Oh, that's surprising. Yeah, I should have used slip tooling

or something, but oh well. So I needed to use so I put boost wave in between which can give me the tokens for just the part I needed to pass, so I have flip clang, it generates me here's a function

here's another function, here's a class and then then when I pass each entity, I use boostwave to tokenize just this source code of the entity and pass that again to get all the information I need. So I get rid of the most difficult problems, for example, detecting whether something is a variable or a function or something like that. I'd have the overview of the file, but I still have to do some manual parsing to get all the information I want. So BoostWave is a preprocessor for C++ written in C++, is that correct?

Yeah, that's correct. It's a preprocessor library that tokenizes. I used it mainly for tokenizing. Okay. You give it a string and it returns a C++ source code, a string, and it gives you the tokens via an iterator interface, which makes it very easy to use.

Specifically designed for tokenizing C++, correct? Yeah, correct. What's the output like from standardese? It looks like you're trying to produce output similar to the standard library documentation, is that right? Yeah, I try to mimic the C++ standard, hence the name standardese.

And this means that you have, for example, in the C++ standard, I don't know how familiar you are, you have a function, and then it is documented with the effects and the return type and whether it throws and requirements. Unlike the DocCision style, which is more direct, where you have this is a param, this is another param, this is a return type, this is a template param, etc.

Just by the way the commands are structured. So in my case, the markup is you have the effects markup to specify effects, and then the flows, and then the output is similar to the plus standard, where you have the signature of the function, and then the paragraphs of the sections. And also mimic the high-level structure with the chapters. Chapters aren't currently implemented,

but so that you have chapters and sub-chapters, and then the function signature. Because I really like the way the C++ standard documents the library. And I just wanted to mimic it. Do you have any builds for this available for people to be able to download and check out on their own projects? I don't have any pure build binaries.

You have to manually download and run CMake over it. But this is something I've already found someone who is willing to maintain, for example, a Debian package. So when this is finished, I'll definitely try to incorporate as many package managers as possible.

Okay. That'd be cool. Okay. I think that might be all the questions I have. Is there anything else you're working on? It looks like you're going to be speaking at Meeting C++. Is that right? I've submitted a talk about my memory library.

I wanted to talk a little bit about the design decisions of my allocator concept and why it is better than all the other allocator concepts obviously I really hope it gets accepted Is there any

preview or tidbit for what you hope to present there that you have not yet mentioned that you would like to go into? I tried to implement something with Romain. I'm not sure whether I'm going to talk about it, but I tried to implement something. It's called joint allocation. For example, if you have a vector of string, you have allocation for the vector and then allocation for the string. And the standard library has this script allocator, I think it's called, this really weird way where you can pass allocators to children containers, which is designed for that. And

my aim is, I'm not quite sure whether I manage it, but once I'm done with the entities, I'm going to go to memory and try to implement something so that it's very easy to have the vectors that they are all efficiently allocated. Wow, that could be huge for people that are concerned about lots of dynamic allocations. Yeah. I'm not quite sure whether I'll manage it or how complicated it will be, but I'll look into that

and yeah good luck thank you and then there are other things memory does for example if you have a pool allocator you need the size of each node in the pool and for example if you want to use a pool with a list

a standard list of int you don't know the size of the pool because internally the node, the allocator is rebound to a node type and this node type has the int and the pointers to the next imprefront and there's no way to get it in a portable way. There's no

member constant or something like that of list where you can get the node size. There's no way to know the node size to give it to the allocator before you actually start allocating nodes. And to tackle that issue, I've actually wrote a code generator that will run when you build the library. It will allocate, for example, a list of int,

and then it will remember the size that is needed for the node and store it as an invite constant in a file. So you can get that via a member constant defined in a header file from the code generator. That's very interesting. Yeah, it's it does it for all the

fundamental alignments and then subtract the type you have. So you have the base type and so it works with arbitrary types because it just uses the base value for the appropriate alignment and then adds the size for the type you're using in front of it.

Am I clear? So you can use it for all the types, and it works until you change the standard library implementation it is built with, then everything breaks. It's an ugly hack, and there is a proposal that

the container should expose this node size, and I really hope it gets accepted because this is so ugly and will break when you blow at it. Do you know if that's a proposal that's currently in review for C++17? I mentioned it in a...

It was in one of the mailings, the papers. I think it's in review, yes. Okay, interesting. Okay, well, it's been great having you on the show. Thank you. I'm sure you're going to do great in university, and I hope it doesn't slow you down from being able to make lots of blog posts

and work on these libraries. I really hope that um and people can follow you online where exactly uh i recommend following me on twitter occasionally i tweet something interesting i'm my name is tronathan double and it's in the links i think we'll put that in the show notes. So follow me there, and I'll tweet about everything relevant I do. Okay. It's been great having you on today, Jonathan. Thank you. Thanks for joining us. You're welcome.

Thanks so much for listening as we chat about C++. I'd love to hear what you think of the podcast. Please let me know if we're discussing the stuff you're interested in, or if you have a suggestion for a topic, I'd love to hear that also. You can email all your thoughts to feedback at cppcast.com. I'd also appreciate if you can follow CppCast on Twitter and like CppCast on Facebook. And of course, you can find all that info and the show notes on the podcast website at cppcast.com. Theme music for this episode is provided by podcastthemes.com.