CppCast - Effective C++

Episode Date: September 9, 2015

Rob and Jason are joined by Scott Meyers to discuss the Effective C++ book series. Scott Meyers has been working with C++ since 1988. He’s the author of Effective C++, More Effective C++, Effective STL, and his most recent book, Effective Modern C++. For 25 years, he’s delivered C++ training to clients worldwide. He once lectured about C++ on a brass-railed nightclub stage while the audience sat at cocktail tables. News AWS SDK for C++ Thoughts on the Vagaries of C++ Initialization Scott Meyers @Scott__Meyers The View From Aristeia Links Effective Modern C++ Scott Meyers Videos Scott Meyers Training The Evolving Search for Effective C++ DConf 2014 - The Last Thing D Needs

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. And by CppCon, the annual week-long face-to-face gathering for the entire C++ community. The 2015 program is now online. Get your tickets today. Episode 26 of CppCast with guest Scott Myers recorded September 9th, 2015. In this episode, we discuss the new Amazon Web Services SDK for C++. And we'll interview special guest Scott Myers. Scott will talk to us about the effective C++ book series C++ developers.

I'm your host, Rob Irving, joined by my co-host, Jason Turner. Jason, how are you doing tonight? All right, Rob. I think I'm almost done with the slides for my presentation for CppCon. That's good. You had a busy week working on that, I guess? Yeah, it's a little bit more research left than i thought there was yeah you mentioned to me how there's a lot more static analysis tools than you thought there were right there's just a lot of uh potential places that this talk could go and i signed up for 30 minutes and it could

potentially be a three-hour talk really if i wanted it to be yeah that's the way those things work isn't it yeah okay well at the top of every episode i'd like to read a piece of feedback uh this week tony writes in and he says dear cpp cast thank you very much for the podcast great work though you've already had several good episodes on threads transactional memory etc i think it'd be really useful to have some expert give an overview of the current state of concurrency in C++. This would assume some basic knowledge of threads

and mutexes and perhaps some vague familiarity with the standard library. So that sounds like a good episode. We did talk with Hartmut Kaiser about concurrency a lot a couple episodes ago, but I guess that was specific to that library, right, Jason? Yeah, HPX, right?

Yes, HPX. But it could be good even to have him back on and see if he wants to dig deep into something like that if he's interested. Yeah, I'm sure he'd be a great person to talk to about concurrency more in depth. Well, thanks for the feedback, Tony. And Tony actually wrote us three emails. This is just one of them. And he also wrote about asking if we could get Eric Niebler on the show and another email

just giving some more general topic suggestions and complaining about the clicking. We did get a couple of pieces of feedback about the clicking in the last episode. We are sorry about that. I'm going to keep a better eye on the editing process and try to make sure that doesn't happen again. And Jason's holding up his pen. Okay, so we'd love to hear your thoughts about the show, though. You can always email us at feedback at cppcast.com,

follow us on Twitter at twitter.com slash cppcast.com follow us on twitter at twitter.com cppcast or like us on facebook you can also review us on itunes we always really appreciate the itunes reviews as they help us get more listeners so joining us tonight is a very special guest scott myers has been working with c++ since 1988 he's the author of effective c++ more, More Effective C++, Effective STL, and his most recent book, Effective Modern C++. For 25 years, he's delivered C++ training to clients worldwide. He once lectured about C++ on a Brass Rail nightclub stage while the audience sat at cocktail tables. Scott, welcome to the show. Thank you very much. It's great to be here. It's great to have you.

What was the nightclub talk about? Yeah. I don't remember the topic anywhere near as much as I remember the nightclub, but I was in Egypt at the time, actually, and it turned out that it was a three-day training, and the first day of training was not a very good training room, and so we asked for a different room for the second day, and they said, well, okay. And so they scheduled us in the nightclub in the bowels of the hotel where they normally had belly dancing. And so I was up on stage.

There were spotlights. It was not the optimal learning environment. And so the next day we actually went back to the previously unacceptable classroom and suddenly decided it was a giant upgrade. That's pretty awesome. You said it normally has belly dancing, but you weren't sharing the stage with belly dancers, were you? Well, the belly dancing didn't start until about 11 o'clock at night, I think. So basically it was dead space from their perspective during the day.

That's pretty funny, though. Okay, well, before we start talking to you, Scott, we just had a couple pieces of news we wanted to go over. The first one was pretty interesting. Amazon just put out a C++ SDK for Amazon Web Services. Obviously, there have been AWS SDKs for multiple languages. I don't know the specific list, but I'm guessing JavaScript, C Sharp, Java all have AWS SDKs. And they just came out with one for C++. And it works with a standard library. It's multi-platform.

And they have a couple code snippets in here. And it looks like it's pretty easy to use. Jason, did you look into this one anymore? I did. One of the projects that I've worked on for the last couple of years actually is a C++ application that calls into Ruby to be able to call the Ruby AWS SDK. Oh, wow. So the people that I've talked to basically say it's about time. Yeah. So now you can stop jumping through those hoops and just uh call in the c++ directly yeah scott i'm wondering what your thoughts are on this it seems like c++ has been gaining a lot more

momentum in the web space um have you noticed that as well um i don't really follow that area very closely so i um and usually when i'm with people, I honestly don't know the kind of stuff that they're working on. So I can't say whether it's more popular or less popular than it used to be. What I can say is I took a look at that announcement myself and was kind of intrigued by their comment that they support the standard template library. And I kind of wondered what that meant. And it turns out it has to do with memory allocation and from what I can tell by looking at what they posted either you get to use the default memory allocator in which case they'll use the default memory allocator or they're going to use their own memory allocator and this is for the STL containers right

what was not clear to me was whether you can use your own custom memory allocators with the STL containers, and then that will be propagated into Amazon services. And it caught my attention because one of the things they say they're targeting are game developers. And for game development, it's pretty common to write your own allocators for the STL. So it'll be interesting to find out whether they actually allow the third possibility of writing your own custom allocators and using it with their SDK.

Interesting. It says on the second bullet point, right after the works with STL, it says custom memory management support. So that, I guess, at least implies what the game developers would be after. But I guess you have to use it to really find out. I clicked through to the GitHub description of what they had, and they have some more details there. And my impression was that it's possible that they don't let you write your own allocator. They have a custom allocator that they use, and you can use that if you

want to. But I may have misunderstood the documentation. Okay. So the next article is actually from your blog, Scott, and thoughts on the vagaries of C++ initialization. And this is obviously very interesting and somewhat frustrating. Did you want to maybe go over the article a little bit? Well, what it really boils down to is that there are, if you just conceptually say what I want to do is I want to initialize an integer,

conceptually. And so if it's an actual int, there's four different syntaxes that you can use for saying exactly the same thing. And so the blog shows those. And then I say, okay, now let's suppose what you want to do is instead of just having a regular integer, you want it to be an atomic integer. But conceptually, it's still an integer. And it turns out that of the four valid syntaxes for regular integers, only three of those work for atomic integers, but one of them does not. And then I said, well, all right, now let's suppose that instead of expressly declaring that you want it to be an integer, you want to use auto and have the type integer deduced. And then it turns out that according to the C++11 and C++14 standards,

two of those four syntaxes will actually give you an initializer list rather than an integer. And there's been a proposal accepted for draft C++17 that will change that for one of those two, which common compilers like GCC and Microsoft already implement. So in practice, it turns out that three of the four syntaxes will give you an int, and one of them will give you an initializer list. And if you list all 12 of these situations out with the int, with the atomic int, and with the auto deducing an int,

the inconsistency of the situation becomes pretty apparent. And this was actually, if I were going to be giving a talk this year at CPPCon, which I'm not, I just didn't have time to prepare one. And I think you both are familiar with how much time it takes to prepare a talk for that kind of a conference. This was going to be part of the motivation for what I wanted to talk about at the conference. But as far as the blog post goes, I simply wanted to point out that there's essentially 12 ways that look like they should all do conceptually the same thing. Some of them work, some of them don't. And in at least one case, it has a, in my view, completely insane type deduction that ends up so you don't get an integer at all. Yeah.

Now, I had heard that they were fixing the braced initialization that winds up giving you an initializer list. And they're fixing it for one of the assignment operations, but why not the other? Do you have any insight as to why they didn't just change this for both? I don't have any insight into that. What I can say is I have been trying to find out the original motivation for the rule that says that if you use a braced initializer and you have an auto type that you deduce an initializer list. And I have been trying to find out why that rule exists for at least three years, maybe four years now. I have never found out what the motivation is. I've talked to members of the committee. I've done searches

through the committee papers. I've blogged about it on more than one occasion. So I know that the rule exists. I know that it is in there deliberately. I don't know why it's there. And I also know that the rule in C++11 and C++14 causes all kinds of pain. People make that mistake all the time. And so the proposal that the committee adopted, which is N3922, my very favorite proposal in the world, takes two syntaxes that cause trouble and eliminates one of them. And so your question really is, why didn't they eliminate the other one? And I just don't know. Somebody on one of my previous blog posts tracked down a paper where the author of the paper remarks that it was a deliberate decision to interpret something as an initializer list but they never say why so it's a it's one of the

mysteries of c++ 11 it's it's a real shame because to me it's a reason to just kind of avoid braced initialization just for fear of running into this and having it catch you. I definitely avoid it with auto personally. It's a stumbling point and I think it's really quite unfortunate. But the members of the committee have very deliberately made the

decisions that they've made. I just don't know why they've made them. Well, it seems like after three years of research, if anybody should know, you would by now. Well, one thing I should probably remark is I'm not on the standardization committee and I've never been on the standardization committee. So the information that I get is because other people have chosen to give it to me. So it's possible. Let's put it this way. Somebody somewhere wrote those rules down in the first place and got them into the standards. So there is a human being somewhere

who understands why those rules were adopted. And I simply haven't found out who that human being is yet. Since I've played with language design, I am not by any means going to pretend like I know the intricacies of working on something like C++. I have to think that it came down to someone assuming that it would cause ambiguous syntax in some cases when you actually wanted to pass

an initializer list. Whether or not that was a correct assumption, it's just my opinion. You know, I simply don't know. All I know is that there is a proposal where they say that from the beginning, we wanted to have an initializer list deduced with braced initializers if somebody uses auto. What they don't say is why they want to do that. Okay. I personally think that it's a mistake to have that type deduction rule.

I haven't seen any examples that convince me that it's a useful thing to do as opposed to simply declaring expressly that you want an initializer list. I know that it's caused all kinds of trouble for programmers. It doesn't make life any easier for people like me who try to explain things to programmers. And for those of us who keep track of these kinds of things,

it actually means that there are five different sets of rules for type deduction in C++, whereas if we didn't have that, there would be four sets of type deduction rules. And I really think four should be enough. Yes. Yeah. Well, you just mentioned there how part of your job is basically to explain C++ to other programmers.

I just recently rewatched your Deconf keynote from the Deconf conference in 2014. And in there, you talked about the last thing that D needs and how the answer to that question is you don't think the D language needs someone like you. Do you think the D language is on a good path with that goal? Well, I haven't followed the development of the D language very much. And it was a surprise when they asked me to give a talk at the D conference in the first place because I don't actually know D. The message that I wanted to convey in that talk was that they are a young language and they still have an opportunity to avoid introducing the kinds of

complexity that exists in C++. What I can tell you is that I did read the D programming language by Andre Alexandrescu that describes the language. And I was a little bit surprised because when I read the book, I said, you know, this language doesn't actually sound that much simpler than C++. There's an awful lot of rules in D as well. But that doesn't necessarily say anything about what it's like to program in D in practice. It's entirely possible that on paper, it sounds kind of complicated, but in practice, it's clear and straightforward. So I certainly hope that that's the case. So on the topic of these effective C++ books that you've been working on for the last...

Actually, when did you publish the first version of Effective C++? I wrote the first version of the book in 1991. So 24 years now. It was a while ago. That's the one book that I've been told, by the way, that I absolutely must read if I'm going to be a C++ developer. It's clearly true. You must read it. Although I wouldn't recommend the one that I wrote in 1991. Okay. I did read it just for the record. So you are the consulting editor on the effective software development series with Edison Wesley. And I've read effective C sharp and effective JavaScript and the effective C++ books myself. I'm just curious what your role is with the series.

What is in a consulting editor? Traditionally, what a consulting editor does is find prospective authors and convince them to write books for the series. And that is not what I do. That's not really my strength. What I actually try to do is act essentially like a technical editor. So I try to help people. I try to read all of the manuscripts. I give feedback to the authors. And my goal is to try to make sure that the content of the book is clear, direct, straightforward, and very practical advice for people who are working in whatever technology

is being discussed. I'm not an expert in most of the technologies that are discussed. So, you know, when I read Effective C Sharp, I didn't know C Sharp. When I read Effective Ruby, I didn't know Ruby. But what I can do is I can look at the item titles, I can read through the description, and then I can look at the summary, and I can say whether I have been convinced by what I've read that the item title is actually good advice. And it is surprisingly common for authors who are experts in the technology to write down an approximation of what they mean rather than what the advice actually is. So I tend to give a lot of feedback on, you know, do you really mean that this is your advice or should you perhaps be

wording it this other way instead? So basically I act as a technical editor. Okay. So in your exposure to those languages, which I think the Effective series does a great job of pointing out the warts in languages, do you have any favorite warts outside of the C++ world that you've come across? I wouldn't say that. What I would say is two things kind of strike me, and one of them is no matter what language you're looking at, people always seem to be able to come up with an entire book full of things that warn you about not doing something in a particular way

and doing it in some other way instead. So it's not just C++ that has these little pitfalls. that warn you about not doing something in a particular way and doing it in some other way instead. Okay. So it's not just C++ that has these little pitfalls. Every language you can read about where they say, you might think you could do this and this and this and it would yield this, but in fact it does this other thing and this is the much better way to do it. So that's the first thing that strikes me. And the second thing that strikes me is it is not uncommon for me to be

reading about a particular problem that a language is trying to solve or a particular thing that it's trying to let programmers express. And I'll look at that and go, oh yeah, I've been down that road before with C++. I know exactly what the trade-offs are here and I know what they're trying to do. So if you are very familiar with C++, it's not uncommon to look at other programming languages and find analogies to problems that C++ had to deal with already. Okay.

So it sounds like you spend a lot of time teaching and consulting with C++ developers. What are some of the common misconceptions or errors you see these developers making? What I would say is in recent years, since moving to C++11, there is a lot of misinformation and a lot of confusion about the broad topic of move semantics. And that includes move semantics,

R-value references, what I call universal references, move forward. There's just a lot of confusion. Part of it is syntactic because an R-value reference has two ampersands and a universal reference, which the standardization company

now calls forwarding references, also has two ampersands, but they actually behave in quite different ways. You have the function called move, which doesn't actually move anything. You have the function called forward, which doesn't actually forward anything. And then there's just a lot of vocabulary confusion about, for example, what does it mean to be a copyable type? I mean, does that mean it can be moved? Or what does it mean to be a movable type? Does that mean it can be copied? Because some types support copy semantics, but they don't support move semantics. And if you apply, for example, move to them, it looks like they're being moved, but they might actually be copied. And so what I find is that the high-level concepts of we want to move things rather than

copy, people understand that. That's clear and straightforward. But when you push down into the details, when do I use move? When do I use forward? How do I tell what an R-value reference is as opposed to a universal reference? People have difficulty sorting all that out, which I sympathize with. I had a lot of trouble sorting it out myself. Yeah, I can accept that. When I read the pre-release of Effective Modern C++ and understood that basically by providing my own copy constructors,

I was prohibiting the compiler from making move constructors for me. And I just basically had to go in and put in some equals defaults in there. And I got a two times performance improvement in my code. Fantastic. So I've recommended the book for just that reason, for the understanding of move semantics, personally. Oh, good. So, you know, it's conceptually a

very simple topic, but the mechanics of it and the details are pretty involved. Much more involved, certainly, than I expected when I started with it. So, aside from move semantics, do you have another favorite item from the Effective C++ series that you would want to point out, say, as your favorite item? Well, I guess if I sort of think of individual items, I'm going to mention a couple of different things for a couple of different reasons.

So one of the items that I wrote about in Effective C++ is to make interfaces easy to use correctly and hard to use incorrectly. And I'm just really happy with the wording of that item. And what I like is that it's about interface design. It's not anything specific about C++. It applies to every single programming language. And I just think that that's very important advice for everybody to be keeping in mind as programmers. Because you're always writing function interfaces, you're writing class interfaces, you're writing template interfaces. There's just a tremendous amount of interface design. And I think it's important to bear in mind that the way you design those interfaces can affect how well people can use them without making mistakes.

So I like that item a lot. There's two items that historically I'm kind of proud of. One of them is from More Effective C++. And what I said was that you should make non-leaf classes abstract, which may not sound terribly radical now, but I wrote that in 1995. And in 1995, giant class hierarchies were the standard way of doing library design. Templates were still in their infancy. And so it was really common to have a sorted container would inherit from container and things like that. And so I

think as far as I know, I was the first person to explicitly give advice to the C++ community that essentially all of the internal nodes in your hierarchy should be abstract classes. So I kind of like that one. I think that one has proven the test of time. I came up with the idea that if you have a choice between making a member function or making a non-member, non-friend function that does the same thing, that you should prefer to use the non-member function. And the argument I made was that by taking functions out of classes, you increase the encapsulation of the class, which I think was a pretty radical idea. And again, I think that has really stood the test of time. And in fact, there's a proposal in C++17 to essentially unify the calling syntax for member functions and for non-member functions. And that will address one of the objections that people had to that, which was that they wouldn't know whether to say object dot or the function call and make the object as the first parameter.

Other languages have already addressed that. I'm pretty sure they have extension methods in C sharp, which essentially allows you to do the same thing. So I'm pretty happy with the advice to basically keep things out of classes when you can. So do you have any concerns about that proposal to unify member and non-member calling convention? My understanding is there's two proposals that take a slightly different approach to it. I haven't read either one of them.

Okay. So I don't have any particular concerns. It seems like a reasonable idea to me. And since the same idea has already been adopted in some other programming languages, you know, we have some experience from other languages to draw on, so it seems reasonable to me. What I will remark on is it's going to make the name lookup rules in C++ even more complicated, and that's already one of the most complicated things in the

language, so it would not surprise me if that ends up having some interesting secondary effects that we may not yet appreciate. Right. Yeah, reading Reddit discussions about that proposal, it seems like it makes people uncomfortable in a way that no one really particularly articulated, similar to the dot operator overload proposal that's up. Yeah, it'll be interesting to see. I've heard about the dot operator proposal. I'm kind of curious as to what happens with that, because one of the things that Bjarne has been pointing out for 30 years,

or whether he still says this, I don't know, but certainly for many years, he pointed out that dot already has a meaning on classes. It means that you want to actually access a member. And this was the reason why you couldn't overload the dot operators, because it already had a meaning for every class object. And you could overload

the arrow operator, because the arrow operator was not defined for every object. Right. That makes sense. So, like I said, it'll be interesting to find out what happens with that. I understand why people want to overload operator dot, but I also understand that there already is a meaning

for the dot operator on every class object. Huh. C and C++ have a long history, going back to the early days of programming itself. Still, it's hard to find a good development tool for these languages. Luckily, our good friends at JetBrains, after spending over a decade making all sorts of tools for a great many technologies, now provide C and C++ developers with three dedicated tools. CLion, ReSharper C++, and AppCode.

All three take care of the routine and help developers focus on important tasks. They natively support Scene C++, including C++11, Lib C++, and Boost. C++ templates and macros are resolved correctly and supported throughout each tool. Find your way through the code quickly with hierarchical views and instant navigation to a symbol's declaration. Boost your productivity by generating the missing members with override implement actions. Rely on code refactorings and be sure that your changes are applied safely throughout the whole code base. Write better, safer, and more efficient code with on-the-fly code analysis protecting you from errors and redundancies before you even compile. Choose one of these three tools depending

on your needs. For a cross-platform C++ IDE, choose CLion. If you work in Visual Studio, go through Sharper C++. Or if you develop for iOS and OSX, use AppCode. Visit jetbrains.com slash cppcast dash cpp to learn more and download your free evaluation. And if you're a student or an open-source project, use all of them for free, courtesy of JetBrains. So shifting gears a little bit,

what do you think is one of the more important things that C++ needs to do in order to stay relevant? Or are you even worried about C++ losing relevancy? I'm not concerned about it losing relevancy, and I think that the most important thing that any technology can do is to stay in touch with the people who are using it and find out how to better meet their needs. And to be honest, I think that C++ is probably doing that better now

than it's done for 20 years. There's more involvement in the standardization process. There is, last I heard, I think, what, maybe 10 different, whatever they call them, technical committees doing investigations into things, everything from transactional memory, which I think you discussed last week. Yes. And there's one on concurrency. There's one on parallelism, there's one on parallelism, there's one on modules. There's all these focused committees that are addressing concerns

that the programming community has. And so I think as long as the Sanitization Committee is, you know, expanding the reach of its efforts to try to better provide tools for C++ programmers, that's going to keep C++ very relevant. It's going to keep it moving into new kinds of hardware, new kinds of application areas. So I think it's a really positive development. Are you excited about C++ 17? Do you have any favorite features from looking at some of the proposals? I'll tell you the truth. I actually haven't followed C++17 very carefully. And the reason for that is that first I was following

C++14, and then I had to finish my book. And since then, I actually was, the book came out in November, I think. And you sort of think, well, okay, great, you're done. I was actually handling reader feedback pretty much full-time through the end of April. So let's just say I learned a lot after the book got published. So I haven't really followed the developments of C++17 very carefully. What I will remark on is that for the first time ever in C++, to be abreast of what's going on with the standardization of the language requires not just following what they're doing for a new standard, but also what they're doing for all of these technical committees. Because they are releasing technical specifications, and I think they've already got a couple out. I know some of you guys like... It's funny. I've always laughed when I listen to your podcast

because you make fun of the fact that they talk about voting something out of committee. To me, I'm like, well, of course they voted it out of committee. That means they approved it. And you guys put it out there. You know, out doesn't usually mean it's in. But I'm pretty sure they voted something out on concepts, and they voted a couple of other

things out. So to know what's going on in C++17 actually involves not just following the standardization of C++17 itself, but also these parallel technical specifications. So there's actually a lot of stuff going on right now, and I simply have not done the work necessary to keep up. The good thing is, though, you know, obviously there's a lot of data to consume if you want to follow everything going on in standardization, but the good thing is you can follow it more easily these days with the internet. I mean, you know, years ago, if you were interested in what was going on with C++98, you know, you'd probably have to be actually going to all those meetings, I imagine. So, no, there's no doubt that it's a much more public process than it ever

was before. On the other hand, it's kind of the downside to that. And don't get me wrong, the upside vastly outweighs the downside. But what it also means is that when you go on the internet, you have to be really careful about the accuracy of the information that you read. Because for, I think it's cleaned itself up pretty much now, but for quite a while there, there would be information about C++11 that had been correct as of 2009, and then proposals evolved in various ways.

And so by the time C++11 came out, some of the stuff on the internet seemed plausible. It's just that it wasn't true. And so you have to kind of be aware that if you're reading a blog post, for example, if you read a blog post now, it could be entirely true about draft C++17. If you read the same blog post a year from now it's possible that something has changed and so you gotta have to be kind of aware of that right so so go ahead a few minutes ago if i got my math right here you basically said you spent five months just following up with reader feedback from your release of modern c++ effective modern c C++. So I was wondering if you have any advice to aspiring authors with that in mind. Not so much with that in mind.

What I will say is that if you are somebody who thinks that you have something to say about C++, or any technology for that matter, I would make two comments. The first one is that I think that we are in a time when people get their technical information in written form, but they also get their technical information in video and online form. And what I know is that publishers are spending more and more time and frankly, making more and more money from videos as opposed to from books. So if somebody came to me and said, I want to write a book about topic XYZ, I would say, you know, a book would be great. I'm very comfortable with books. But you might want to think about whether what you have to say

could be said in video form instead, or possibly in both book form and video form. It's pretty common now for publishers to talk to prospective authors and say, you know, we can make this a book, but we could also turn it into a video series. So the first thing I'd say is that rather than thinking of yourself as an author, you should think of yourself as somebody who has technical information that you want to convey convey and then think about the fact that there's more than one way to convey that information now. So that's the first thing. And then the second thing I would say is writing a book or producing a video. In fact, you guys have both talked about the amount of time it takes, for example, to prepare a talk for CppCon.

So, Jason, I think you said you've been spending a giant amount of time preparing a 30-minute talk, which could be a three-hour talk. When you said static analysis tools, I went, oh, yes, that could easily go three hours. Yeah. So, I actually did some informal back-of-the-envelope calculations. And for effective modern C++, that took me about 1,350 hours, which I think the math said is about eight and a half full-time months. And if you consider that I've already written several books before, so in theory, I should be better at it than somebody who's never done it before. That's a lot of time. And you need to be willing to devote that kind of time to get something done. And then the second thing is that if you are doing it because you want to become rich and famous, that's a low probability option.

So I wrote Effective Modern C++ because I really felt like I had something to say that would be useful to programmers. Maybe it would sell well, maybe it would sell poorly, but I really felt like this is a contribution that I can make to the community, and that was my primary motivation. So I think that people need to ask themselves, why am I motivated to write this book or to produce this video or to do both or whatever it happens to be? And if the motivation is, I think it'll be a really interesting experience, that's fine. If the motivation is, I really feel like I have an important technical story to tell, that's fine. If the motivation is, it seems like it would be kind of fun, then my recommendation would be, write the first first 25 pages see how fun that is and then multiply it by between 8 and 15

and you'll get some idea of how much fun it's going to be I enjoy writing books it is a lot of work so I always encourage people to do it because I think it's a great endeavor but I think people need to go into it realistically So you talked a lot about

video being kind of seems like where the direction things are moving. What do you think about the like live coding trend that's going on? Do you have any opinion on that? You're going to have to tell me a little bit about it because I'm not even exactly sure what it is. This uh programmers who will record their desktop session with a corner of their their video in the corner probably and audio while they're talking through what it is they're programming record like an hour session of just basically programming and explaining what it is they're doing along the way it's popular as a law among some game developers and then they uh they could they do it both as a live stream,

and then you can watch it later if you are so inclined. So programming as a spectator sport. Essentially, yes. I like it. I mean, I think it's a perfectly reasonable thing to do. And it would depend, you know, different people like to see different things. I like the fact that there's a running commentary. I think that's cool. I think you would need to be careful about what it is that you're showing, because a lot of parts of a lot of programming are frankly not that interesting. But for example, if I think about, let me put it this way, I think that there is a role for that to play. And if there are people who already are doing that successfully and they found an audience, then that indicates that there are people who prefer to acquire the information that way.

And I'm kind of agnostic about how the information gets delivered. So different people like to acquire information in different ways, and different kinds of things lend themselves to different kinds of presentations. For example, if you're trying to show somebody how to use a particular tool in practice, then a video is much better than trying to describe that in textual form. One of the examples that often gets kicked around in writing circles is it talks about writing versus doing video. And so if you were going to try to explain to somebody how to tie their shoe, would you rather do that with a video or would you rather do that with text? Right. And I think we can all agree that video is a vastly

better way to get that idea across. That's a very good point. So then in a more traditional sense, do you have any specific advice, anything you'd like to call out for people who are giving presentations or recording technical videos? Well, my main comment about people who are doing actual technical presentations, for example, at conferences, and since you guys are at least one, I guess, Jason, Rob, are you presenting at CppCon? I can't remember. I'm not this year. I'm hoping to next year. All right. So then this is advice for next year, for what it's worth. All the talks at CppCon, I believe, are going to be recorded.

And what that means is that in all likelihood, each presenter will be seen by more people on video than they will be seen live. And so my general advice these days for anybody doing a technical presentation is to prepare it under the assumption that you're on television and that people may be able to see the presentation materials, but they may not be able to see you. And so try to avoid things like pointing at the screen or using laser pointers or things like that because those don't convey very well on videos. Any kind of thing where you're going to be using your body to show dynamic movement and this is how the tree rebalances itself or this is what the memory allocator is doing. Assume that people can't necessarily see that and so try to build all that information

into your materials as much as you can. That works really well for the people who are live in the room with you, and it works even better for the people who are not live in the room with you. So my thinking these days is if you're going to prepare a presentation, you should prepare it on the assumption that people will be watching it on video rather than seeing you live. All right. Thank you. I'll try to keep that in mind with my presentation. Yeah, that's really great advice. So I guess going back to C++, are there any features you would call out

that you wish you could take away from the language? I'm going to mention a couple. One from the core language and actually one from the library. So the one from the core language, this should not be a terrible surprise, is I would get rid of the interaction between auto and braced initialization, yielding initializer lists. I just think that really that has no payoff whatsoever, and it just causes a lot of people to get tripped up. And I guess sort of the language analyst in me likes the fact that it would eliminate one of the five sets of rules for type deduction. As far as the standard library goes, there's a few things that I could point out, but the one I'm going to select is I would get rid

of forward list. And it's not because I actually have anything against singly linked lists. I mean, they're perfectly fine data structure. I have no problem with that. What I dislike about forward list is that they try to take a data structure which doesn't really fit the STL framework very well. And they tried to force it into the STL framework. As an example, with every single container which permits insertion except for forward list, when you specify an insertion point, then it gets inserted in front of that element. But the problem is that would require going backwards against a singly linked list, and so they can't do that. So there's actually no insert function for forward list. Instead, it has an insert after function.

Interesting. And it also means that, okay, if you're going to insert after something, and you need to insert something at the beginning of the list, they actually have a member function called before begin, which allows you to insert before the begin, so that actually puts it at the front of the linked list. And it's because they're trying to take this data structure, which doesn't really fit very well into the framework of the STL, and then they're trying to sort of hammer on an interface

that makes it look as if it actually is part of the STL. So I'm not morally opposed to the existence of a singly linked data structure. I just don't like the fact that it doesn't fit very well with the STL conventions, and yet they put an interface on it that suggests that it fits well with the STL. I have not personally found a good use for forward list. I thought I had once until I realized that vector was actually faster for my use case, which was just pushing things onto the end of a list and it still was slower than I expected it to be. My understanding is that forward list was adopted into the standard library specifically because the committee felt that there was a need for a data structure

that had absolutely no time or space overhead compared to a singly linked list written in C. Okay. Which is why you can't even ask it how many elements are in the list. It doesn't support that because that would require an extra word to keep track of how many elements are there. Right. Wow. Personally, in my 25 years of doing this, I have never heard anybody complain about the lack of a singly linked list that had exactly the time space overhead of C, but maybe I don't get out very much. So again, I'm not opposed to the data structure. I just don't think it fits very well into the STL. And I think the way that they've tried to make it fit into the STL is problematic.

In fact, I'm really looking forward to seeing what they do with concepts as regards, let's put it this way. If you have, we think of forward list as a container. Yes. But you can't insert or erase in the normal locations, but you can insert and erase. So the question is, does it satisfy the concept of a container? Because there has to be a technical definition of what a container is. Right, yeah. If it does satisfy the concept of a container, then container has a very, very small definition, right? So I'm really,

and they've already run into trouble with this. If you are so foolish as to look at the official table of requirements in the standard for what it means to be a container. So you go in there and there's a table and it says these are the required operations for container. And so you can read through those and you go, okay, well, now I have some idea of what a container is. And they're called container requirements. And then you start reading through the containers and you'll find things like this container satisfies all of the container requirements except for the following things, which means it is not actually a requirement. It's more like something we'd like to have.

And so there's already this disconnect in the official standard itself between what is a container in concept and what things are actually containers. And they're going to have to now formalize that when they come up with concepts. So it's going to be interesting to me to find out what they do about things like that. For example, a standard array. As I recall, a standard array is considered a container, except, of course, you can't insert and you can't erase.

Right. And so if you have a concept that says, I will take any container, I'm really curious as to what that's going to mean. So you've probably done more archaeology about the standard than anyone else. There's got to be some other nuggets in here that you like or don't like.

Well, the first thing I'll say is that compared to people like you guys who actually have to work for a living, I probably understand the standard pretty well. But compared to the people who actually work on the standard itself, the people who write the proposals, the people who actually come up with the formal wording for the standard, trust me, I am a rank amateur. I don't even make the top 100. So it's like reading something versus being able to write it. So I can read the standard and have some idea what's going on, but I've never tried to contribute standard text. It's very difficult to do that.

What I will say is that the standard shows that it has been worked on by probably at least 200 or 300 different people. And it has the coherence that you would expect from a document that's been around for two decades and worked on by a couple of hundred people. Okay. Which, you know, at the same time, you know, the fact that C++ is such a widespread,

successful, portable language and is so important in industry indicates what a very successful job the people have done putting that standard together. I mean, the only reason the standard exists is so compiler writers can produce compilers that adhere to it. And so standard library developers can write libraries that adhere to it. And by that measure, it has been a tremendous success. It's quite an

accomplishment. That's true. It's very true. Well, I feel like we've probably taken enough of your time. Do you have any new books, talks, anything coming up? Or are you taking a break after finishing up all that feedback with Effective Modern C++? For the most part, I'm taking a break. I do have a few things that I want to say. And so I'm making some blog posts. So you referred to the one about initialization syntax. It turns out that's actually just the tip of a much larger idea that I want to get out there.

So there's going to be probably some more stuff coming about that. And then I'm working on, actually, just today I'm working on a blog post that has to do with... So here's sort of an interesting question, at least I find it an interesting question. If you need an associative container, you can use the standard associative containers, which in C++98 were set and map, and they're multi-variants. Then in C++11, they added the unordered versions,

which are basically the hash tables. And then what people discovered a while ago, quite a while ago, was that for lookup purposes, if all you cared about were lookups, you could also put all your data into a sorted vector and then do a binary search on the sorted vector. And in many cases, that would offer faster lookup speed, primarily because it uses less space than a set or a map. And Boost has actually formalized those. It's called the flat containers in Boost. So there's flat set and there or a map. And Boost has actually formalized those. It's called the flat containers in Boost. So there's flat set and there's flat map. So the interesting question to me is, if you need an associative container, under what conditions should you choose set or map,

or flat set or flat map, or unordered set or unordered map. And I had made some assumptions about what probably was the appropriate set of choices. And then I was giving a presentation recently and somebody came up and showed me some data that they had collected, which was not consistent with what I expected. So I spent the last couple of weeks playing around generating some tests and stuff. And so the results of that I find very interesting.

And I'm hoping to publish that as a blog post here in the next day or so. So it's possible that'll be out by the time this recording airs. I'm not sure. So not riveting to most people, but I personally find it interesting. Okay. I'll definitely take a look at that post when it comes out. It sounds interesting to me. Definitely.

It's got pretty graphs, if nothing else, and I'm always happy when I can use color. Then you can just look at the pictures. You don't even have to read the article. That's my goal, is to make the pictures a compelling story. Okay. Well, is there anything else you want to plug

before we let you go? Nothing in particular. I guess I will just mention something you guys have mentioned before, which is I was at CPPCon last year, and it was quite an amazing conference. And I'm not going to be speaking this year. Whether I'll be there is as yet undecided. But I think that CPPCon is a giant opportunity to learn a whole lot of stuff about the language and to talk to other people who are working with it and who are standardizing it. And so for people who have the opportunity to attend live, I would encourage

them to do that. And for people who can't, they should keep their eyes out for the recordings that are going to be available on the internet, because I think it's going to be a great resource. It's an overwhelming amount of information, it looks like. I'm having a hard time picking which talks I'm going to attend. Well, my recommendation is that you attend your own talk. That's always a good idea. Planning to, yes. And good luck with that talk, by the way.

Thank you. Okay. Well, thank you again, Scott. All right. Well, thank you both. 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.