CppCast - C++ Patterns

Episode Date: April 26, 2018

Rob and Jason are joined by Kevlin Henney to discuss C++ Patterns and things every programmer should know. Kevlin Henney is an independent consultant, speaker, writer and trainer. His development interests are in patterns, programming, practice and process. He has been a columnist for a number of magazines and sites, including C++ Report and C/C++ Users Journal, and has been on far too many committees (it has been said that "a committee is a cul-de-sac down which ideas are lured and then quietly strangled"), including the the BSI C++ panel and the ISO C++ standards committee. He is co-author of A Pattern Language for Distributed Computing and On Patterns and Pattern Languages, two volumes in the Pattern-Oriented Software Architecture series. He is also editor of 97 Things Every Programmer Should Know and the forthcoming 97 Things Every Java Programmer Should Know. He lives in Bristol and online. News Spectre diagnostic in VS 2017 Version 15.7 Preview 4 Microsoft MakeCode: from C++ to TypeScript and Blockly (and Back) Introduction to web development in C++ with WT 4 Kevlin Henney @KevlinHenney Kevlin Henney's Blog Links Pattern-Oriented Software Architecture 97 Things Every Programmer Should Know ACCU 2018 - Kevlin Henney: "Procedural Programming: It's Back? It Never Went Away" Sponsors PVS-Studio JetBrains Hosts @robwirving @lefticus

Episode 147 of CppCast with guest Kevlin Henney, recorded April 23, 2018. This episode of CppCast is sponsored by PVS Studio, one of the most powerful static analyzers for C, C++, and C-sharp source code. With PVS Studio, you'll detect errors early, during the coding phase, and spend less time debugging difficult problems later. Try the demo version today at viva64.com slash pvs studio. And by JetBrains, maker of intelligent development tools to simplify your challenging tasks and automate the routine ones. JetBrains is offering a 25% discount for an individual license on the C++ tool of your choice. CLion, ReSharper, C++, or AppCode. Use the coupon code JetBrains for CppCast during checkout

at JetBrains.com. In this episode, we talk about Microsoft MakeCode and web development with Witty. Then we talk to Kevlin Henney. Kevlin talks to us about C++ patterns and things every programmer should know. Welcome to episode 147 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 you doing today? Doing pretty good, Rob. How are you doing? Doing okay. Don't really have much news to share today. I'm at home because my daughter is sick, unfortunately. She should be fine tomorrow. That's unfortunate

and good, I guess, if she should be fine by tomorrow. And I'm back home, and I've got two weeks to work on my presentation for C++ now, so I'm feeling pretty good. Just the one presentation this year, though, right? Yep, yep, one presentation, and looking forward to it. Need to start putting pen to paper just for the record i do have lots of notes and i've been thinking about this literally for months so it's not like i'm starting completely from scratch here okay but we've got two weeks left until c++ now

so if anyone has been waiting to the very last minute, you need to buy your ticket right now. Yeah, right now. Okay. Well, at the top of our episode, I'd like to read a piece of feedback. This week, we got an email from Peter in Serbia saying, Great podcast. Started listening to you guys near the end of last year, and I always look forward to a new episode. There is a new lib in Boost 1.67 contract.

Anyways, I was interested in seeing if you could bring someone more familiar with it. Maybe it's author so we could hear more about it. That is so you could ask all the questions for us as you always do. Yes, we briefly mentioned the boost 1.67 update last week and the new contract library as well as higher order functions, I believe is the other one. But yeah, it'd be great to have the author of contract on. So I'll have to look up who that is and try to get them on the show. Yeah, that could be fun for sure. Yeah. Well, we always 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 cpcast.com. And don't forget to leave us a review on iTunes. Joining us today is kevlin henney kevlin is an independent consultant speaker writer and trainer his development interests are in patterns programming practices and process he has been a columnist for a number of magazines and sites including c++ report and c++ users journal and has been on far too many committees including the bsi c++ panel and the ISO C++ Standards Committee.

He is co-author of A Pattern Language for Distributed Computing and on Patterns and Pattern Languages, two volumes in the Pattern-Oriented Software Architecture series. He's also editor of 97 Things Every Programmer Should Know, and the forthcoming 97 Things Every Java Programmer Should Know. He lives in Bristol and online. Kevlin, welcome to the show. Hi, glad to be here. Living in Bristol puts you really close to ACCU, huh?

25 minutes walk, to be precise. 25 minutes walk, wow. Yeah, so the ACCU conference was last week, or no, the week before, and that is one of the curious luxuries of having it in your hometown, being able to walk in and not having to find a parking space or any nonsense like that. Is it safe to assume you did go this year, then? Oh, yes, absolutely. Did you present anything uh yes i presented a session um on procedural programming uh which is is part of a long-standing um area of interest to uh present people present people with a very counterintuitive view um surprise people go back and say okay what was

procedural programming really about um what do you think you know about procedural programming? Because normally people use the phrase procedural to mean bad. It's a shorthand for saying bad. You know, when somebody says our code is procedural, they don't mean it's great. So I wanted to actually go back and look at 1960s, 1970s. What were people actually saying? What were people actually doing? What was perceived as the leading edge of procedural programming um and surprise a few people with some of the things um so yeah yeah that was that was fun that sounds actually really interesting maybe we should dig into some more about that uh during the interview portion rob absolutely yeah yeah i mean a distinct relevance here is the fact that I put some code up from ALGOL 68. I did some ALGOL 68 code, and I have the ALGOL 68 reference manual.

The most important thing about that is if you've ever wondered where the keywords union, struct, int, void, all of those, it's ALGOL 68. That's where they all came from. One of the great… Most influential language nobody's ever used. Well, it's okay. Now, the interesting part from a historical perspective is, did you have an ALGOL 68 compiler that you could use? Yes, I did.

There is an ALGOL 68 implementation, an open source one. And it's, let me think i'm just trying you can get yes it's algol 68w a68 a68g a68w i'm just trying to get that right it should be um standard with uh you can get it sigwin and you can get it on most linux uh distributions as well so um yeah algol 68 genie that was what it's called um so yes and it's a pretty conforming implementation as well. So yeah, Algal 68 Genie, that was what it's called. So yes, and it's a pretty conforming implementation as well. So yeah, this is, so yes, it's quite fun.

So I was able to write some code, test some code, and present new Algal 68 code. So some of those languages from like the 60s and the 70s had like goofy things like requiring a specialized keyboard to be able to type in all the symbols. Was Algol in that world? It's not quite.

It had a sort of an idealized character set. You didn't have to do anything really too crazy. In fact, it assumed a subset because they didn't use any curly brackets whatsoever. So pretty much everything in Algol 68 was done with regular parentheses, which led to some very interesting compiler disambiguation. I'm sorry, yeah. You know, but, yeah, they assumed more of a subset.

But there was a thing that was popular, an idea known as, let's see was it's a let's see is it stropping that yeah there's a particular keywording approach so that if you didn't have it didn't have proper keywords so that sometimes people would mark those out so a common implementation was that keywords are going caps and then all of your identifiers would be in lowercase just to distinguish them so it didn't have a proper concept of reserved words which is why computer science journals got into the habit of doing keywords in bold and then all the rest of the text was in non-bold writing because actually that's how these things were

presented the bold thing means whatever you're doing locally then follow that capitalize or put it in quotes or mark it out some other way huh so so uh so yeah that's uh yeah it's good it's quite neat in that sense you know i must admit i'm slightly disappointed that you said everything was done with parentheses because i was hoping that you were going to tell us this is where biographs and trigraphs came from digraphs and trigraphs came from in c++ uh no disappointingly disappointingly not no we're gonna have to look to another source to blame for that one okay so uh but yeah there's a lot of really interesting stuff in there um and you know i've got some really nice little examples where i show radical innovations like the use of uh anonymous procedures uh or as we would call them lambdas um so uh so 1968

and then finally 2011 so that was a slow progress there so and uh interesting timing you waited until the 50th anniversary effectively to present this. Yes, pretty much. It wasn't intentional, but last year I noticed I was doing more talks that were focused on the past, sometimes in language design, sometimes on the development practices that we have. have uh and then i started i started noticing i was quoting from the uh 1968 um software engineering nato software engineering conference um report a few times and i suddenly thought well we're coming up to the 50th anniversary and then you look at that you realize algos 68 um that was significant massive influence bjana used that in the mid to late 70 to late 70s, and that had also influenced a number of other languages,

C directly and then indirectly again, C++. And then we have other things like 1968 was Melvin Conway, Conway's Law, and it was the mother of all demos from Douglas Engelbart, so the mouse and all the rest of it. 1968 was a pretty big deal in this case. So yes, 50 years. I've kind of started making a bit of a point about that one. And 2001 A Space

Odyssey was released, and that's one of my favorite films. So I had to include that one in the talk as well. There's a lot going on there. 50 years and nothing has changed. That, disappointingly, was my conclusion. Okay. That's unfortunate.

Yeah. But we'll still talk more about procedural programming later, I think, if we have time. Absolutely, yeah. Sure. So we have a couple of news articles to talk about, Kevlin. Feel free to comment on any of these, and then we'll start talking more about C++ patterns and maybe some procedural programming, okay okay so this first one is from the visual c++ blog and specter diagnostic added in visual studio 2017 version 15.7 and this is pretty cool they have a new warning that can tell you, hey, this code, you know, when compiled with

the, you know, Spectre flag is going to generate a mitigation. So if you want to avoid that mitigation, that could be potentially, you know, slowing down the processing speed, then, you know, this warning will show that to you. Did you fully understand this example, Rob? Did you try to? I didn't look too deep into the example. Why? Is there something you noticed about it? No, no, no. Well, I mean, I noticed that everything is force in line,

which just bothered me greatly. But besides that... Yes, that was interesting that you mentioned that bit because I looked at it and i initially it looks like the kind of the standard specter javascript example because you've got a you've got a branch before an array array reference and then there's that's going to force a preload and i don't know if the force in line was really just a case was just a a long-winded way of saying please don't optimize this in any way shape or form um yeah so uh i'm

not sure what that was there for it'd be fascinating to recompile it without the force in line and see if you exactly yeah agnostic yeah because there's a there's a sort of a suggestion that that was what happened first in other words that we're seeing the after picture, that they tried to show it beforehand, and actually they didn't get the effect desired. I don't know. But yeah, it does raise an interesting question. Now, you know, Andrew wrote the article. Maybe he's listening to this episode, and he can tell us later if that was required, instead of us easily typing it in and doing our own homework on it. Outsource it. No, no, no.

Crowdsourcing. It's community participation. That's what we're inviting. Okay, so... Andrew Pardo if you're listening, let us know the answer. Now, Kevin, so the part that was lost on me, and since I don't fully understand how these Spectre things work, you said the branch before

the indexed operation. That's the critical part, lines 12 and 13 in the example yeah yeah okay um because yeah because what what we're looking at here is the fact that you can end up with um a speculative load as i understand it you can end up with speculative load um and this stuff's going to lie around regardless of whether you took the branch or not and there's there and this potentially opens up an exploit um curiously enough actually because this because this um example is not designed to explore um specter itself just to outline the uh the new warning feature um it is worth going and looking up the original JavaScript examples

because those make it a lot clearer what's going on, and really the mechanics is the same, but where you see that you've ended up with something being loaded that really shouldn't have been there. So, yeah, I think that's really more a case of having to go and look at Spectre in detail rather than looking at this diagnostic to get the clue here. Okay. And I must say, it bothers me just a little bit that we keep saying,

let's go look back at the original JavaScript example to understand what the C++ is doing. Yeah, there is a truth to that. There is a truth to that. Well, I'm going to say that because that's the more dramatic one. But probably, and here's a thought to that. Well, I'm going to say that because that's the more dramatic one. But probably, and here's a thought for a future show, it might be worth getting a security expert who can walk you through this in C. Because, I mean, that's the point. It's the C level. You can do it directly. It's just that most of the examples that you find that explain it are JavaScript.

So it's not that my motivation is not really JavaScript. It's just that that's where all the examples are. And therefore, that's where the explanation is. It's also where the greater shock is. When somebody says, hey, look, we're doing this in C or C++. Shocking security breach is just like, yeah, whatever. So it has more of a shock factor there. But I think walking through that with somebody who really understands the machine is probably worth a whole episode. To be honest.

We did some of that with Matt Godbolt. Yeah. Well, yeah, if anybody understands the machine and what's going on, it'll be him. Okay, next one we have, and this is actually a video up on YouTube, but it's another thing from Microsoft. This project they've been working on called MakeCode. And if you've seen anything with Blockly,

where you're trying to get kids interested in coding and they can move blocks around on the screen in order to make a program. Microsoft kind of made their own version of this called MakeCode, only instead of just making a little in-app browser game with your code, you can actually put the code onto actual devices.

They have relationships set up with Adafruit and a couple other ones and also with Minecraft so that's the only one that's a non-device thing but you can use Blockly or I guess use TypeScript to make these programs and this talk is actually talking about how they go from the Blockly or TypeScript and put it into C++ so that they can put it

on these devices. Pretty interesting stuff. Yeah, and there's a lot going on in this talk. Like, I feel like it could be an entire episode discussing it, really. But they have C++ functions that they can expose to their TypeScript, and then they have the TypeScript compiled to a machine code so that they can then load it on the like Arduinos and execute it like some really interesting cross language stuff going on. Yeah. Yeah.

No, I was quite impressed with that. But funnily enough, the one question that I had was was asked right at the end, which was Raspberry Pi support, which did seem that was missing. It's currently missing from it, and it's not something they've said they're going to pursue. And that seems a little strange, but perhaps that might be a perspective from where I'm sitting in the sense that Raspberry Pi is quite a big deal here. So that would be people's – there seems to be more of a preference for Raspberry Pi than Arduino in the UK. But that might just be a local perspective.

Well, and the Arduino, you're compiling to like 8-bit AVR with some like simple C interfaces and such. And if you want to support Raspberry Pi, then you have to compile effectively to a Linux elf binary. It's going to be an extra level of complexity for them, I would think. Yeah, it's a different ecosystem, and it needs somebody else to put some proper effort into that. But it was interesting. The reason that question came to mind was more that they opened the talk by talking about um kind of the origin of school-based projects in the uk they talk about the bbc micro um in the 1980s and that's the beginning of the talk and funnily enough the raspberry pi was conceived as a kind of like a 21st century response to

exactly that if you talk to the raspberry pi folks that that's exactly their memory they grew up in that generation um so that's partly why i'm asking, you know, sort of, or why people might ask them that if they make the reference to things like BBC Micro. In the UK, that triggers a certain thought pattern. Right. And I think if I have my history right, arguably we wouldn't even have something like the Raspberry Pi because we wouldn't have arm if the bbc micro had not been such a success and the funding had gone and you know the company uh armed what was the original name of the company acorn didn't have the uh resources to invest in it absolutely yes yeah yeah there's there's there's an awful lot that stems from the bbc micro and flows out from it

yeah not just programmers, not just a generation of programmers here. Yeah. If you go around something like the ACCU conference, people of a certain age, myself included, had experience of that was a defining experience. But then you've also got the hardware, the culture and everything that flows out from that. Right. Yeah. Okay, next thing. This was an introduction to web development in C++ with Widi4. And, Jason, we've never talked about Widi before on this show as far as I can remember, but it's a web-based application development framework.

They actually reference Qt in the talk um how it's kind of going to be similar to cute but but it's made for the web um but i don't think we've talked about this for but they're they're on version four as of last september interesting no i had uh we i don't believe we've mentioned it at all actually i don't think i'd been familiar with this the web toolkit i i kind of wish we had had this article last week when we had Jason Rice on the show because we were talking about C++ web application development with him.

I'm wondering if he's ever used this toolkit. It looks pretty impressive and if you go to their website, which is webtoolkit.eu, in the talk he says that they make this website with Witty, and it's a pretty nice-looking website.

That's pretty cool. So I'm definitely interested in learning a little bit more about this one. It's another thing that could be a whole episode that I'm going to see if we can contact someone from Witty if we can get them on the show. Okay. Have you heard of this one before,vlin no i hadn't so i i watched this one i was really interested because they've it's it's kind of well thought out and the the family proposition of witty 4 is is that it is c++ 11 friendly although i noticed his compiler options were 14 rather than 11 so there's a

sort of suggestion there that if that that that's a direction that they're probably thinking about and it was interesting just looking at how you know i was thinking okay what would this have looked like in older c++ and there are some uh you know more extensive template usage but i think what i'd be interested in for that is an even more declarative approach if they start embracing C++17 and beyond, being able to... They currently add nodes to the web page

by just doing sort of an add operation and then passing appropriate constructor arguments through, having templated it, add a break, add a text box or whatever. And I'm wondering if using a more kind of uniform initializer style would be more natural. You can end up with a really declarative web page. Just really, you've got things there that are almost markup types as markups open curly brackets you put stuff in there and with being able to deduce template templates through

constructors now then you end up with a really clean syntax and so that sort of might be witty five but as I was looking at it I was was quite excited by the possibility, just thinking syntactically how easy it would be to actually have the C++ looking exactly like web page structure and callbacks. Because it's quite obvious they've done, yeah, it looks good with the use of lambdas, but I think there's one more step. And I think that'd be quite interesting. So, yeah, I was quite intrigued by that so nice and lightweight he's uh the use of the use of large coding font to get simple examples is always convincing it's just like yeah we can make the font this big and you can see everything rather than look i fitted it on one slide and it's all in four point it's just like no actually you fit in one slide and it's readable and it's just like

yeah this is pretty cool and i also like the way they've scoped this they said like it's one page apps that's what we're good at yeah you know they're not trying to be everything not trying to be all things to all people it's just like here's the problem we're going to solve and we solve it so yeah and i thought more impressively from another point of view that i'm talking very much about the c++ experience here but actually the way they'd structured it just a proper generalized framework that if you disable javascript you still get similar functionality um the idea that you can just change your browser setup and it will respond based on what what is available um whether it's web sockets you know you can drop that in or out whether it was um enable or disable javascript

and it still gives you a functioning web page. It just switches dynamically. I thought, yeah, that's pretty cool. It's some neat work going on behind the scenes there as well. Yeah. Wow. Yeah, that sounds really cool. One other thing I just wanted to mention is I was looking, I was curious about this when I was watching the talk,

and I just found the answer. They do have both open source and commercial licensing, which I think is similar to the way Qt runs things, where if you're a company making apps, you can obviously pay for it, but if you want to make an open source website, you can use it for free. So that's pretty nice. Yeah, I think Qt's slightly more liberal than that these days still, but it depends on what exactly you're targeting. But still, it sounds pretty good.

Okay, well, Kevlin, we've had a lot of listeners ask us to have someone on the show to talk about kind of common patterns and practices within C++. And it's something that Jason and I aren't really experts on. So it's really great to have you on the show. And maybe you can start off by talking about what some of the more common c++ patterns are that c++ developers should be aware of um yeah this uh the problem is i think let's rewind a little bit is that the the problem is that with um when anybody and i noticed this a lot perhaps more in c++ space than elsewhere a lot of people when they

hear patterns they immediately leap back in time they get in their time machine they go back to 1994 and the gang of four book and as if that was the the first and last word on it and it's like no no no really that was just 23 23 ideas that happened to be around at the in the early 90s and we've kind of moved on quite a long quite a lot since then um so that sometimes people use that as their kind of very their their total definition of what design patterns are and also from a c++ program's perspective when people look at that book they look at the patterns as if they were the code in that book and we've got to remember what 1994 was like that was that was pre-standard value was pre-draft standard um so there is not a single remotely standard feature in there um for anything you know you're not even using a there's no concept of strings uh no containers nothing you know 1994 was the year that the stl was kind of adopted but

that would have been way too late for this book so um sometimes people look at that and they go well i'm not going to use these patterns because um the uh you know this this this this this is not how we do c++ anymore and they kind of miss the idea that the pattern itself is somewhat deeper this was an implementation code example and actually it goes a lot deeper than that's the idea so i think the first thing is to decouple that idea get get to the idea that a pattern is a way of solving a problem that happens to have trade-offs and it has some kind of recurrence other people have found it useful and you go you know what this is pretty good so we can start and and there's always something about the context

and context is a very patently term but here we can say if i'm working in c++ then one of the common context features is i probably have to manage my own memory so therefore what coding practices can i adopt that makes sense now in this space a lot of people say oh you're talking about idioms well yes there is a there's a distinct overlap. These two terminology sets came from different sources. And part of the idea, and the problem is I think with some idioms, the way that they're expressed is they don't offer you the full idea of the solution. What problem are we trying to solve? So resource acquisition, yeah, R-A-I-I as has been named because it's actually it's nothing to do with acquisition it's release um you know there's nothing particularly special about the

acquisition um so naming is hard but that's your classic one from uh that's your classic old school type of pattern we still expect people to be using that but commoditized at some level um uh but now the thing that people need to be looking more towards is the opening up of the more um functional space so once upon a time people say oh the command pattern and they call anything that involved a callback and an object a command and command pattern it's like well it's a richer space around there once you've got lambdas once you've got std function all of this kind of stuff there's this whole idea of a compositional mindset that's really different so you start moving into genuinely the functional space but the idea of what does that mean if i've got language if the language changes then what

does that mean it means i can change how I do observers. I can change how I do notifications. I don't necessarily need class hierarchies to do stuff where I can use compile time polymorphism or I can use type erasure and get around that. So there's this idea of these old school patterns. Either they get displaced or they get expressed very, very differently, and there's a sort of a blurring of the boundaries. And then you've got commoditized stuff, your good old-fashioned iterators, which hopefully are going to turn into ranges very soon. But,

you know, the syntactic overhead of using that stuff in C++98 was a problem and actually held back probably a more widespread adoption of the styles that were associated with that. And indeed, I did a talk many, many years ago on patterns in the STL. I'd identified 25 patterns, probably half of which are now dead because, you know, I involved trait classes. There's a whole lot of stuff now that we no longer need the same way. But it was what is the language that describes the STL? What are the patterns inside that? You know, what patterns would you say? And people use terminology like half open range, these kinds of things.

These are little design ideas that all fit together to create a programming style. And that's kind of the way that I would think if you approach C++ 11, 14, 17, and 20, you start looking at that and say, well, what problems have gone away? And what new ways of expression have I got that tidy up the old problems and just make things more syntactically lighter? So patterns you want to be focusing on,

not threading. There we go. That's almost a negative, an inversion of a pattern. The idea of not creating command objects that own their own thread. That used to be a really popular idea. The idea these days is that we favor a much more architectural view.

The idea of keep your code small, single-threaded, and arrange something that coordinates that, so pipes and filters around it, talk through futures, use promises and futures, think about queuing. We kind of talk about this in the pattern-oriented software architecture books. Keep away from raw threading. That's your low-level jump statement.

You can build everything out of it, but work to a higher level. Continuations, all of these ideas are kind of where I think the modern C++ view is taking us from a compositional point of view. And if you look around, you'll see that each of these patterns is documented somewhere, continuation, future, message queues, and so on. These all got written up at one time or another. So C++ now makes it easier to sort of embrace these. And based on the intro, I'm guessing those all got written up in about 1968. Oh, let me think.

Yeah, some of those we had to wait as late as the 70s for. But yeah, by the time you reach the end of the 70s, most of those ideas had appeared in one form or another, you know. So yeah, it takes a while for these things to filter through, doesn't it? But, yeah. You mentioned lots of different things like commands, objects, continuations. You mentioned specifically not avoiding manual thread management. Is there any particular thing that you think is worth, like,

digging into right now that you would like to talk about some more um well i know you're going to ask me a question about well reference reference counting i wasn't going to dig into that necessarily but um but actually on the threading on the threading front i think that is, I think that's the kind of the overarching paradigm we should be embracing is the idea of take a step back. The threads, just because you have threads doesn't mean you want to launch them. Just because you have mutexes doesn't mean you want them in your code. And so there is this idea that C++ is a language that embraces uh many styles perhaps too many some days it feels like particularly in legacy code it embraces many styles but there are some

that make more sense than others and there is this idea of um composition and i don't think historically c++ developers have embraced that enough the idea of creating small parts that you can compose easily that have minimal effect or zero side effect and that's the same philosophy that drives continuations as drives just the ideas of being able to pick stuff up from promises or push stuff into promises, pick stuff up from futures. The idea that wherever you are, it should look simple and single-threaded. The fact that your whole program is massively concurrent, that shouldn't worry.

This little piece of code has a very single-threaded view of the world. It asks for things, it pushes things out, and it doesn't ever see a raw thread that it has to engage. And it's this small unit-like composition, I think, that is the architectural style that modern C++ can support much more effectively than it has done. So if I had to pick something, I'd say, yeah, it's all of these things. Getting people to be much more serious about immutability, which is easier, again, in more modern C++. So all of these things that just, you know, take us in a direction. It's like small, simple parts that you combine together. And that would be, yeah, that's where I think people need to be looking.

I want to interrupt the discussion for just a moment to bring you a word from our sponsors. Development of qualitative software is impossible without the use of static code analysis tools. These tools detect errors on the coding phase, i.e. at the very early stage. The earlier a bug is detected, the cheaper it is to correct it. One of the powerful static analyzers is PVS Studio.

This tool detects errors and potential vulnerabilities in the source code of programs written in C, C++, and C Sharp. It works on Windows, Linux, and macOS environments, and it conveniently and easily integrates into the Visual Studio IDE versions 2010 to 2017. You can easily check your CMake-based project or use a compile monitoring if you use your own build system. The analysis can be conveniently integrated on the CI servers by using a command console. To reduce the analysis time, you can apply incremental analysis and IncrediBuild. The analyzer can identify potential vulnerabilities due to compliance of the PVS Studio diagnostics to classification of common weakness enumeration. To ensure continuous quality control of the source code, the analysis results can be uploaded to SonarCube. Try the demo version

of PVS Studio and find errors in the code of your project. Since you did mention it, you wrote a paper on C++ reference accounting, and I usually hear it referred to as reference counting. What do you see as the difference between accounting and counting with references?

Well, part of that was – I mean, that was written nearly 20 years ago, 18 years ago, 16 years ago. Not 1968. So what I did in that paper, that paper came out of a conversation I had with Jim Kapline in 1999 over a few beers when he talked about reference counting and he said oh there's two ways and i sat there i sat there in a pub in oxford and i thought about it for a moment i said no there's six ways and he said there's two ways to reference guys and there's six ways and one of them doesn't involve counting so um when i came to actually write this paper which is nearly 50 pages long, I wanted to really break down the whole space and realize that not everything was actually counting. So, for example, you can have linked handles.

Obviously, this is going to be a terrible idea in a multi-threaded environment, but there are cases where this makes sense if i have smart pointers um that form a uh two-way link list when i assign from another smart pointer then i can say well hang on i know you i'm going to keep i'm going to keep a hold of the other smart pointer um we form a we form a chain um all of the people all of the smart pointers that know about an object there's no direct count there but if you were to measure the chain from one into the other you'd have the total number the nice thing about this is it does allow you to do collective operations on all of the owners it's a very edge case but there i have encountered a couple of cases that require it so when i come to came to write the paper i was case like well reference counting technically five out of

the six core patterns do qualify um as that but i thought actually there's play on words reference accounting because that's what we're trying to do um just keep track of stuff it's like double entry bookkeeping in some way so um so yeah that was that was the kind of approach of exploring where do you put the count do you put it inside uh the pointer inside the object at a point in the middle or somewhere else in a lookup table? And each one of these has different consequences

and has different advantages. Okay. Have C++ patterns changed or evolved in more modern times as the new versions of the standard have been coming out? Yes, because some of the things that people... First of all, the emphasis.

So when I wrote that, shared pointer was a boost thing, but nothing more. I mean, this was pre-TR1, so there wasn't even the kind of slightest hint of this being standard but so therefore people were still rolling their own now shared pointer actually fills a very important space it captures the most common uses um but that paper is still if you're interested in how would i go about implementing this or what are the other cases

that are not covered by it then it shows you how to build those but when i wrote it it was more for the point of view of you want to build um you need to build a reference counting pointer from scratch what kind of thing do you need to do so that kind of manual approach that's the patterns are still those patterns are still there but we don't really worry about them as much. They're much more for the library implementers, not the users. They become commodified in one sense. So from one point of view, the center of gravity has shifted. Those patterns are still valid. It's just that there's not as much need to know them because you can get them from the library.

Likewise, implementing type erasure for a lot of people is not really something they need to worry about because they've got any, they've got function, all of these things do the right thing. So most of these mechanical things that you might need to know have kind of disappeared. RAII still, I can't see that ever going away as a low-level pattern is still something that I think we'd like to think everybody knows, but actually it turns out it's a minority of people that know it. I'm going to guess pretty much everybody that listens to this show knows it, but that's not most C++ programmers. the balance has shifted with lambdas and lambdas auto and std function because that allows you to do a lot more decoupling through smaller functional units it just gets rid of the whole ceremony of i need to fight i need to create a new class boilerplate that put in loads of stuff

override something do all of this just to get some kind of callback mechanics working it's just like nope i've now just got a line of code and that just makes it a lot easier to write certain things that massively shifts the style and you're not paying a penalty for it either the compiler is on your side for most of this stuff so i would say that the ability to use all callback-based patterns, anything that involved notification, pluggability, or anything like that, those suddenly become much more C++ friendly. And they finally move a lot of C++ code away from either being too C-like or being a little bit clunky with their objects you know high ceremony classes with lots of boilerplate stuff in them now i'm curious and i kind of now want to bring this back around to the procedural programming if you don't mind we've talked about the uh gang of four from the 90 1994 the classic uh design patterns book and you talk talk about some of these patterns kind of being legacy things

because we don't really need to use, we don't need to manually write that machinery anymore. So where's the historical context for this? Where is the advantage in still understanding how these work and relying on the abstractions that the language is currently giving us? And how did you, I'm assuming your talk on procedural programming relates to this. It touches on a couple of those things, but let me,

let's have a look at that from another point of view. Why is it worth knowing some of these things? One, because not everybody works on a code base that is right up to the minute. So a lot of systems have a legacy tail, which means that you can start – you can open up a file and it can start in the early 1990s.

And you can kind of – by the time you reach the end of it, you've projected quarter of a century into the future. So in other words, you've got this massive massive span of version so a lot of people are having to go into legacy code that was conceived at a very different time and either they were handicapped by a lack of availability of features in the compiler so for example a lot of people sort of our templates not really sure about those or we can't get consistent support for those. So, therefore, we're going to do all of our stuff using void pointers and casts and crossed fingers.

Or we're going to just make everything virtual and everything's going to happen. We're going to create a universal base class and this kind of stuff. So, it turns out that sometimes the reason you need to understand this stuff is because your code will have this um regardless of what is what it doesn't matter what you can do now it's the code still has an opinion that is based on something from 20 years ago and we have to remember that c++ 98 uh the clue might be in the year but honestly the rollout

you know the adoption of it was relatively gradual. We've been, in the last few years, people who've intentionally focused on C++11 have been able to track 14 and now 17 much more closely. But in 2005, you were still lucky if you could find anybody saying, actually, we've got a C++98 project. Wow. So there is that. So there is the historical perspective. History is still with us. The other perspective is if you are a library builder, you want to know about the mechanics.

That makes sense. You need to know what it looks like under the hood and then there's another one which is to stop people using old patterns you need to know about the old patterns to say don't do that because actually some of them um have been were superseded even at the time uh there's things like decorator is really just not the best way to do a pipe and filtering approach and an adaptation approach it's quite clumsy doesn't matter what programming language you're in it's just actually not really the best way of doing it um you're much better off saying i have a collection of things and i have something that is going to iterate through them and apply actions much more like an interceptor so in other words it holds little functional objects um and then applies something to them iterating through them much

better than saying i'm going to pass something to an object then it's going to do something and pass it on to the next one and then and so on and so on uh it's not just that that gives you memory management nightmares and c++ it's just that it's actually quite a violation of the single responsibility principle, and it does involve a lot of choreography and coupling, whereas the alternatives tend to be a little more layered. So some of those, even back in the early 90s, were not considered to be great. But now it's a case like, really don't do this um you know so so i think that there is this idea of revisit some of these things uh to know enough about them to say actually you don't want to do that um uh so yeah there's three reasons but that shouldn't mean that everybody spends all of their time looking at the old stuff because this whole idea of being able to look at the uh the modern

more compositional approach i think is where people should be spending, devoting most of their energy. Makes sense. Could you tell us a little bit about the book you wrote, The 97 Things Every Programmer Should Know? Well, I mean, straight to speak, I edited it rather than writing it because I managed to get everybody else to do the work, which is a minor stroke of genius um um that was that was a part of a series that um o'reilly had at the time um 97 things uh and the idea was we start the whole series start off with 97 things every software architect should know then there was 97 things every project manager should know and i propose 97 things every programmer should know and uh motivation for that was from a personal point of view uh was simply that i think we assume i think it's it's easy

you can get 97 things out of any programmer just take them to the bar or whatever and apply them with the appropriate fluids and you will get 97 things that's not a problem what's more interesting is the fact that no two people think the same way if you if you poll a whole group of people they will give you uh ideas you never even thought about they will say it in ways you'd never thought about and they will emphasize things that they personally have found important and uh and you go yeah yeah you'd nod your head but you probably wouldn't have picked it so it was just one of those things what is what is it that would really help people um not so much you know give them a complete education but just sort of say here's a bunch of pointers lots of different points of view you know get get a whole load of people and ultimately

we had 73 contributors to that book they're not gonna have the same point of view and if you're going to be a software developer you need to have a broad base and you want to have a kind of suggestion from different people you don't want to be just made in one person's image so to speak you want to get it get as many ideas as possible and so we had some really great and very different suggestions and proposals from that so that was the motivation for. A book that would actually be kind of fun, a scope for education. In other words, you can use this over lunch. You can say, okay, we're going to have a reading group at work and people can go through one or two items a week, as simple as that, because each item is two pages. It's relatively non-threatening. It's not the whole topic that it covers, but it's an eye-threatening it's not the whole topic that it covers but it's it's an eye-opener or it raises questions and it points in the right points in direction

i've actually got things in the book that contradict each other so some people have gone like oh my goodness you shoddy editorial editorial work it's like no no no actually that's intentional because not everything has one simple answer. I'm hopefully causing you to think, you know, here's two sides of the story. Where does the truth for this company or this team lie? And it gets you talking about things. So there's that. And a suggestion from a colleague was you can use it for book bombing. You know, you can in that sense of, you know, your colleague is doing something that you've disagreed with.

And then you walk by and, you know, you leave a post-it in the appropriate page. You know, you just say, look, see, somebody else said it. It's in this book. It must be the truth. So it was that. And so we covered a variety of things, some of them low-level, some of them team-based. So, yeah, so that was the motivation,

to just sort of take a slice through something that is really quite large, which is the development space, and just say, we're going to sample it and see what different people say. Is this a language agnostic book? It is. That one is language agnostic. And therefore, from that point of view,

managed to get, you know, I've got folks from JavaScript, Ruby space, C++, you know, sort of Unix folk, Windows folk. Hell, it's probably even, yeah, I think I've got VI and Emacs mentioned by different people at different pages. You know, so, you know, very, very broad church. You know, it's very inclusive. Is there any standouts from there that you would like to mention? Any of your favorite ones? Well, speaking as the editor, I'm not supposed to have favorites.

Oh, yes, right. All 97 of them are your favorite favorite all 97 of them are my favorite okay yeah but i'm actually going to pick on a couple i might as well um one of them i really quite like is a message to the future by linda rising and it's a it's a lovely way of putting this idea of like how should i think about writing my program and and the and she relates a tale she's very much so very much a storytelling approach but this idea of you know you have a developer says look i've just done this in the cleverest way that i possibly could you know and uh and and then there's this idea of like well hang on you know is that the best way to do it is is it the cleverest way? You know, if your little brother can't understand it, you know, could your little brother understand it? No, he hasn't got this far in terms of his studies.

And it's like, well, okay. Well, how would he feel if he saw that code? Ah, you know, so there's this idea of like, well, maybe you should communicate to him. Maybe you shouldn't do the smartest thing. Maybe you should do something that is simpler. Maybe the smartest thing made you feel satisfied at one point but probably there's a simpler story trying to get out in the code and there's that idea of your it's the idea of something that i

i often try and emphasize to people is that coding is an act of communication and you're not just talking to a machine and you're not even just talking to yourself um there is this idea of what am i really trying to say you're trying to shuffle your thoughts around. How do I divide up the universe in a way that makes sense to me? And I'm offering somebody else a model. What is that model? So I really quite like that piece because it is this idea of a message to the future is how do I communicate to somebody I have yet to meet or to myself in the future? It's a very constructive and very well-written piece. So that one, I'm going to pick on that one. Then something that I also strongly believe in, Russell Winder's piece, Know Well More Than Two Programming Languages.

I think these days it's probably, I mean, the book was published 2010, and I think it's safer to assume people are being are a lot more polyglot now than they used to be but yeah i but there is this notion still as as russell says no well more than two programming languages because there is that idea of looking at these things from another point of view you pick up you pick up sort of patterns in other programming languages by just seeing them you go well hang on like i know how to do that it's a different way of thinking and it actually allows

me it's a problem solving technique these you know other languages offer you different ways of looking at problems it's not just a coding thing at the lowest level it's a a way of looking at problems it's not just a coding thing at the lowest level it's a way of looking at the world every programming language is a way of looking at the world you can formalize things what are the formalisms available to you and so once you have that you have binocular vision you know you've seen things from more than one point of view you see more of the whole so I think that that one for me is a is something I I do quote that one quite a bit as well. So, yeah, yeah. So I'll pick on those two without being overly favorite, overly favoriting things.

But, yeah, yeah. Okay. Jason, is there anything else you wanted to ask? Well, we should maybe just mention that you are currently editing another 97 Things book. Is that correct? That is correct yes and obviously because this is um because this is cpp cast it's a java book you know so still um yeah we kind of i got into talking with o'reilly about um about doing another book and we had this kind of question like well what should the emphasis be and we were wondering either uh programming domain um you know so there's there's a lot of possibilities

of how you slice this one so you could say oh well let's do something on web development or let's do something on mobile um or you can do it in terms of um programming paradigm say let's do something on functional programming or you could do something in terms of programming paradigm, say let's do something on functional programming, or you could do something in terms of platform. So strictly speaking, the book is actually about the Java platform, but that's a mouthful of a title. It's really, it's about things that fit in the JVM and the JVM ecosystem,

and therefore language, so therefore JavaScript is acceptable as a language and i'm not entirely sure i want to be misquoted on that one uh kevin heady says javascript is acceptable as a language no i'm not entirely sure that's true but um uh but you know it means there's uh i'm expecting people to talk about um the sort of the java build system, the JVM itself, where it occurs. So in other words, talking about web development, mobile development, language-specific stuff, whether we're talking Kotlin or Clojure or Java itself.

And I discussed the options with that. We did talk about C++. We talked about.NET space one. And O'Reilly felt that actually getting back into this because the timing of the last book was just in time for a recession, it turns out. Well, or rather, it was just as the world was sort of going into the crunch and publishing was undergoing a bit of a crunch as well. So that's why there's been this hiatus since basically 2010 on their book series um so they thought okay the java space is probably one that they can rely on and then actually we will see what happens after that so that's what that's what i'm looking at and if any listeners are find themselves as they got one

foot in that camp then this book book is looking for contributions, basically. So get in touch. There's nothing special from your point of view. If you want to contribute, you just have to be able to think of something. Oh, I've always wanted to tell somebody that, or this is a way of thinking about something. And, you know, 500 words, that's about it. So that's pretty much it.

Okay. Well, if you ever do a 97 things for C++, you'll have to let us know. Come back on the show. I will do. And I will come back cap in hand begging for contributions because it's just like,

send us your stuff. But yeah, so I'm hoping the Java one is going to be successful because that could reawaken this. Because i think a lot of people have enjoyed uh there's certainly people enjoyed um uh contributing to be honest people do write stuff and contributing oh this is quite fun but also it had it see this this book seems to have had quite a life uh quite a good life um it seems to be quite useful from an educational point of view you can kind of say read through this ask questions it's quite useful um and that kind of book i think that

kind of book that gives you a cross-section um and certainly i can imagine the c++ space that would be really useful in other words we've got a lot of people who are new who don't know the language don't know his history and then you've've got people who've got pyrotechnic techniques that you're not entirely sure that you can understand. And that's just the error messages. So there's this idea, there's a massive range of possibilities, and I think that there's a lot of people to be reached through such a project. Okay.

Well, it's been great having you on the show today, Kevlin. It's been an absolute pleasure. Thanks for joining us. Thanks so much for listening in 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 about that too. You can email all your thoughts to feedback at cppcast.com.

I'd also appreciate if you like CppCast on Facebook and follow CppCast on Twitter. You can also follow me at Rob W. Irving and Jason at Leftkiss on Twitter. 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.