CppCast - Software Architecture with C++

Episode Date: December 2, 2021

Rob and Jason are joined by Adrian Ostrowski and Piotr Gaczowki. They first talk about profiling tools and reverse iterators. Then they talk to Adrian and Piotr about their book on C++ Software Architecture, and what all C++ developers can learn from it. News Another way of looking at C++ reverse iterators C++ Profiling and Benchmarking Tools in 2021 A footnote on "Three reasons to pass std::string_view by value" Links Software Architecture with C++ Software Architecture with C++ on Amazon Sponsors Indicate the #cppcast hashtag and request your PVS-Studio one-month trial license here https://pvs-studio.com/try_free C++ tools evolution: static code analyzers: https://pvs-studio.com/0873

Episode 327 of CppCast with guests Adrian Ostrowski and Pyotr Gachkovsky, recorded November 24th, 2021. Sponsor of this episode of CppCast is the PVS Studio team. The team promotes regular usage of static code analysis and the PVS Studio Static Analysis Tool. In this episode, we talk about profiling and benchmarking tools. Then we talk to Adrian and Piotr. Adrian and Piotr tell us about their book on C++ developers by C++ developers. I'm your host, Rob Irving, joined by my co-host, Jason Turner. Jason, how are you doing today? I'm okay, Rob. How are you doing?

Doing all right. It's Thanksgiving Eve. We're recording this episode before Thanksgiving. It'll air a week after, I guess. But yeah, looking forward to the holiday. You? Yeah. Well, I mean, one of the main things on my mind at the moment is that the episode of C++ Weekly that's going to air on Monday is my 300th episode. It's a nice number. Big round number. Congratulations. Thanks. And that, uh, it's, this will air after that has aired. Okay. Because that's going to air on Monday.

This will air on Friday the same week. Right. So I won't give, it's not a spoiler, but if you, if you haven't seen the episode yet, then you're going to want to go back and watch it because I went a little off my norm and the intro of the episode was changed a bit. I'm just going to say that. I'm expecting to get comments on it. I'll look forward to seeing all that on Monday. All right. Well, at the top of every episode episode, I like to read a piece of feedback. We got this tweet from Eric Kneebler, who we had on the show quite a while ago, I think.

It's been a while, yeah. He wrote, finally got a chance to listen to this episode of CppCast. Sounds like senders and receivers were well-received by the HPX team. I'm so curious to hear more from them about their experience with the future standard C++ concurrency model. Which episode is that in reference to?

That was... It must be the somewhat recent one that we did with Harkmoot and Simberg on HPX. Yeah, okay, okay, okay. That sounds believable. Yeah, all right. He didn't link to the episode

he was referring to, but that must be the one. Right. But yeah, lots of talk lately about senders, receivers. Hopefully that proposal does move forward. Well, we'd love to hear your thoughts about the show. You can always reach out to us on Facebook, Twitter, or email us at feedback at cppcast.com. And don't forget to leave us a review on iTunes or subscribe on YouTube.

Joining us today is Adrian Ostrowski. Adrian is a modern C++ enthusiast interested in the development of both the C++ language itself and high quality code written in it. Some of his past projects include parallel computing, fiber networking, and building a commodity exchange trading system. Currently, he's one of the architects of Intel and Hibana's integration with machine learning frameworks. In his spare time, Adrian used to promote music bands, learned to fly a glider, and sail in the Baltic Sea. Currently, he likes playing with his pupper and browsing memes.

Adrian, welcome to the show. Hey, welcome. Glad to be here. I think browsing memes might be the most interesting hobby we've actually had listed. Well, it's probably one of the most, you know, it's a frequent hobby of many i would assume something you think to put down in a bio do you actively fly though i am curious since you put that in the bio do i actually actively search memes yeah no no no fly fly you're flying lighter

part is what i know no i i did that uh like like a few years ago now. So actually it was quite a bunch of starts and landings. But in terms of hours, it wasn't really that much of them. Because when you start learning to fly the glider, usually you start with like those three minutes in air, just, you know, to try to launch yourself, do a circular around the airport and then land still in one piece. As you can see, I managed to do it. I plan to return to it though. It was great. It really

pumped the adrenaline. That's cool. Also joining us today is uh peter gotchkovsky peter has over a decade of experience in tech and uses his skills to improve people's lives he likes building simple solutions to human problems organizing events and teaching fellow professionals peter is keen on automating boring activities when not coding he's most likely listening to music reading or doing some parkour welcome to the show pr. Hi, glad to be here. I don't think we've ever had a guest say they do parkour before. No, that might be the first time that's come up, yeah. That's cool.

I have done exactly one parkour class, and it was in a window here in COVID where they were allowed to have the classes again, and then they weren't allowed to have them. And I thought, you know, I could, it was fun. It was fun. I could go back and keep doing it. Yeah, it's great fun, I would say, because you're constantly challenging yourself.

You're learning new stuff. It's kind of, I don't know, other physical activities sometimes could get boring for people. Here, you can do totally different stuff each day and hardly get bored because there's so much thing to experiment. And then there's always the aspect of getting to know the outdoors better. So, yeah. So you are doing that outside outside in the city uh yeah so uh we we

have a few spots that are like uh training spots designed for for for training but we're also sometimes doing some some some totally freestyle stuff you know just using the city's infrastructure lots of fun recording those illegal videos of you jumping rooftop to rooftop kind of thing as well? I can't really answer this question. But if you check the videos...

Alright. Well, we got a couple news articles to discuss, guys. Let's talk about these. Feel free to comment on any of them, and then we'll start talking more about your book, okay? Perfect. Cool. So this first one is a post from Raymond Chen's blog, and this is another way of looking at C++ reverse iterators. And it's a pretty short post um and i just really like the graphics

in this to uh be able to visualize the the difference between a normal and forward or reverse iterator it's it's quite nice i kind of felt like one of the key things in here for me which i had just never stopped to think about is that you can't do a normal reverse iteration because you can't have one before the beginning of an array even the one after the end has always been valid uh so that one i was just like yeah yeah so fortunately i i think with ranges it kind of gets easier right i mean you don't need to think about using the iterators for me me, I mean, if you take ranged-based for loops and you iterate the container, you can do it forward, right?

But there wasn't any easy way to do it backward. And now we actually have a way. So you just take a reverse view of a container and you're done. You can iterate through it like you usually do. Just out of curiosity, if you try to take a reverse view of a forward list, what happens? Does that fail to compile? To be honest,

I never tried, but I would expect it to fail to compile. It should require a bidirectional iterator. Probably. But I guess you wouldn't take a reverse iterator also right so it's actually not it's the same in both cases right yeah you wouldn't be able to right that's

a good point all right the next thing we have is uh this post on hacking cpp which i don't think we've looked at before this is just a list of profiling and benchmarking tools. A lot of these we've talked about before on the show. They're highlighting Intel VTune, which is a really great profiler tool that is for use from Intel. But they have a whole bunch of different ones listed and some of their capabilities and what platforms they work on. It's a nice list. They even added a star in front of Intel VTune. So I think they really think it's one of the

better ones. I was curious to see that the AMD profiler is also there, although I haven't played with it. I wonder how they differ. Because Intel really has a major product now. Yeah, and I think AMD has restarted theirs a couple

times, because that says UROF, and that's not the name that I... If I'm looking at the right list here, that's not the name that I recall AMD's profile being called. Anyhow. That's not familiar to me. Yeah, I think... I'm pretty sure this is a relatively new product from AMD, but I could be wrong.

We need to give it a shot, right? So, with those profilers, one of the more known by me was the gperf one. So even not the new profilers, but the perf tool. Chandler Karouf made a few talks about it as a console tool. And if you take the flame graphs,

it's really quite easy and simple to start using it. Right. Maybe not as simple as VTune still, but... So have you used VTune then? Yeah, yeah. So actually we did some optimizations, optimization of the data loading for some machine learning frameworks using VTune

and it really did a good job with helping us find the bottlenecks. Awesome. Very cool. Yeah, it's cool that it also has some threading capabilities, like detecting issues with threads, detecting issues with memory contention, which is often the case. So basically, it has a nice way of showing you where to put your focus when fixing

the issues very cool peter anything you want to add any uh tools you want to highlight here um i'm not sure if there's much to add the list was pretty great um regarding uh the jupiter that we that we've mentioned it's also worth mentioning that it's basically available wherever you need it. Like it's, you know, portable. So it's worth to be familiar with that because if you're working on some ARM platforms or some maybe RISC platforms, whatever, I mean, the MIPS stuff.

Then it may come in handy, while other tools may not be available. Yeah, that's a good point. Interesting point. One place where I found it not to be working, although I haven't checked for quite some time now, was the Windows subsystem for Linux, because you don't really have a Linux kernel there.

So I think I had some issues with running it because of this. On GPROF, you're saying, right? The perf tool, yeah, GPERF. Oh, okay. Was it WSL 1 or 2? It was 1. So yeah, it was quite a few years ago, I guess. Okay. Maybe they fixed it was quite a few years ago, I guess. Okay.

Maybe they fixed it. I hope so. Yeah, but WSO2 also has a different underlying architecture. So I think there is a working kernel right now. I haven't really checked that, but that's my assumption.

So this might be fixed by itself. I heard they plan to bring SystemD to WSL. So yeah, it looks like we're on the right path. So that Snap will finally work and some other tools

like you could run services on WSL. Okay. Without any hacks. I still haven't even tried playing with WSL. Okay. Without any hacks. I still haven't even tried playing with WSL. I feel like maybe I should do that someday, huh? Yeah, it works pretty well. Yeah. Yeah.

I mean, and if you're in a Microsoft environment and want to use some Linux tools, it's pretty easy to get up and get running. And it's integrated pretty well with VS Code and with recent Visual Studio so you don't even need to actually use the console all the time. It can just work with regular VS Code or VS Projects

and under the hood it's using just different toolchains so yeah. Even if you're using CLion, you can easily plug in the WSL backend, so you can use GCC there. And it's really a good setup to have on Windows, I think. Interesting.

Yeah, because sometimes I end up doing like a temporary commit on a temporary branch so that I can hop over to linux or hop over back to windows real quick if i could share a file system or something that could be handy yeah all right and then this last article we have is uh from arthur dwyer's blog and this is a footnote on three reasons to pass std string view by value did we talk about the original post here jason no i realized that after i put this article in the uh in the list but i don't think we needed the first one because i feel like anyone who's been paying attention uh to like what best practices around string view and span and those

kind of small easily copyable things is everyone says to pass them by value. So I felt like most of our listeners would already have the basis here and then we could, but anyhow. So this whole article is, you know, like you said, he was advocating passing stream views by value, but he did have some people commenting that it doesn't give you as much performance as you would want with Visual Studio on Windows,

but he's kind of arguing that even if that's the case, it's still the right thing to do, right? Yeah, with a very interesting breakdown, in my opinion, because I'd just been wondering about this myself recently, in a slightly different level because of the Commodore 64 stuff that I play with, because there I have a different problem. A pointer size is 16 bits, but a word size is eight bits. So passing 32 bits on the stack is now very big in that code. So I was wondering, well, should I pass by reference here by copy, but then anyhow, looking at this breakdown of it, I thought was interesting for the Windows calling conventions.

All right. So we mentioned, after I read your bios, that you both worked on a book, but I don't think we've said the name of it yet. So does one of you want to start off by just telling us what the book is you worked on and maybe give us a high level overview of it? Yeah, sure. So the book is called just Software Architecture with C++. Actually, there's also a subtitle, but I guess the whole title would suffice if it were those four words. Basically, it's a book about becoming or improving your skills as a C++ oriented software architect. So it actually goes through several skills that architects should have. It starts with an overview of what architecture is and how we can, in a high level, compose architectures.

Then we go through requirements that systems should have, like how to gather them, what they even could be, right? And which ones of those are important, documenting them. Then we go through architectural design patterns. We go through C++ and the way that C++ treats patterns. So usually we have idioms, not patterns that are common here. And there is a whole chapter that discusses the issue. We go through some techniques that use various features of the language to create efficient software.

Next, I think there is a whole section on building C++ code, packaging it. So that's that. And then the second half of the book is more the work of Piotr, and maybe Piotr, you could say a few words about it. Yeah, so we're also going through some quality attributes, how to make your software testable, how to make it performant,

how to make it secure and stuff like that. So there's basically a dedicated chapter to each of the quality attributes that we want to cover. And then there is stuff that may be relevant to architects who are not solely working with C++ code, but are probably architecting some bigger systems. So there's introduction to different service-oriented architecture-related, how do you say it, patterns. I don't know. Basically, yeah, different approaches to how to implement that. A bit of stuff about microservices, about connecting stuff together,

about continuous integration and continuous delivery or continuous deployment. continuous integration and continuous delivery or continuous deployment. Also some cloud-related stuff if you want to host your software

in the cloud environment. Stuff that is I think not very often talked about when you're talking about C++. So we wanted to have the modern approach to C++. So this was actually kind of an adventure for us because we wanted to have all the new standard features explained there.

But when we started writing, the standard was like almost final, but not yet. And a few things like, you know, totally changed. And we have a whole chapter on contracts. I had to cut out.

Actually. Yeah, we did have a section on them. I had to remove it out of my training also. Yeah, there was also the funny fact that we had a release date

set in stone, but none of the compilers were feature complete, so we had to compile GCC from source to provide some examples. And we had to hope that the stable release would work exactly the same way

so the code would still compile. So yeah, writing a technical book is lots of fun. So you both mentioned software architect when you gave the description of the book. So I'm just curious, can you give us like, uh, who is the ideal reader of this book? Are you, are you saying someone who's higher level who, who does like the design of the application or, or, you know, me down in the trenches with my C++ compiler churning out code all day? Yeah.

Average programmer engineer. Yeah. Yeah, average programmer, engineer. Yeah, should they read this book too? So I would say they could benefit from parts of this book, but mostly we targeted people who are more senior than junior, right? And if you are a developer that starts to think about

how architecture should like, how you could influence the bigger picture, not just the day-to-day code that you work on, then it's definitely a book for you. If you want to become a software architect, it's a great place to start because it really gives you a nice overview. Also, if you already are an architect,

then you can still probably benefit or learn more about software architecture, maybe broaden your knowledge. I think one of the things that C++ developers are often not that familiar with is how to write those distributed systems with C++. Many don't know how to run a microservice using this or how to even start building an architecture

that could use several microservices, right? So if you're a C++ architect and you don't know those things, then you can definitely learn a bit from the book. I think also if you're into learning about the whole process of building and testing the code, like building CICD pipelines, it's also something that you could benefit from, or maybe thinking about how to design them. Yeah, so going with Jason's example,

if you are a developer sitting in trenches with compiler but you realize everything around you is a mess and you would really would love to improve the situation, then this might be a book for you because you can learn

what exactly might be the reason for the mess you are in. Usually it is either the lack of proper architecture or there was some architecture, but the implementation went, you know, in a separate way. So understanding better what you can do to improve your situation and, yeah, deal with, ideally, less less mess so i just got a perfect image in my mind for adrian since you love memes you said right i got that right here you the dog

in the burning room this is fine he needs to be sitting there reading a copy of your book well maybe he would then notice that it's actually not fine and this is not fine sure yeah yeah right what do yeah so i i think if you're not reading the book and you don't know what's in it then yeah you you could be this dog and not even realize it right i have not had a chance to read through the book yet but i did read through uh the introduction and in there you you had this mention of a concept of accidental architecture um and i guess that's kind of the situation jason was just talking about you know being in the room that's on fire all around you um if you were in that situation where you think there wasn't much thought of architecture you

know what sort of things could you do that maybe this book talks about so i guess you need to first stop and reflect on how this current state looks like so if you realize what are the main pain points then you can really start addressing them right right? If you only do write code and not worry about anything else, then probably you can end up quickly in an accidental architecture scenario. If no one takes care of architecture, it won't take care of itself, right? You will end up with just accidental architecture. So learning about how the code could look like can help you with dealing with this. I guess you need to first know how it could

look like, what are the good practices, and then look at your project from time to time and either just fix what's wrong or even better, look at how you can plan forward, you know, not in a waterfall-like manner, but for the near future and think about what are the crucial design decisions that you need to take

so they don't take themselves. Are you implying that accidental architecture is never good architecture? It could be good, I guess. In some cases, just like in

some cases when you throw a bunch of rocks, they turn into some masterpiece but you know the chances are not that great so yeah if you're feeling lucky i mean define good right if job security is your thing then yeah it's probably the way to go. Yeah. Okay. So you said job security and I was just half joking in my head that people reading your book might go, I just need a new job. Right. If, if they don't, it's, it's, and it probably, you know, it happens,

right. People like you're exposed to good architecture or whatever, and they know what that's like. And then they look for something new, but just out of curiosity, like for real, if you did from the perspective of this book, if say I'm I've read your book now i'm looking for a job and i'm thinking well i want a job at a company that cares about architecture what kind of questions should i ask my potential employer that's a good good one i think you you

need to somehow sense if they know what they're talking about, if they are planning forward. Sometimes even the technologies that they use can tell you a lot about the company, right? So you could ask them how their CICD pipeline looks like. What do they use to actually package the deliverables that they have? What testing framework they are using. to actually package the deliverables that they have. If someone is creating... What testing framework they're using. Yeah, yeah. Or if they are using testing frameworks at all, right?

Yeah, that was my reasoning. Ask them what testing framework are they using and if the answer is, what is a testing framework? Then it means that probably architecture is not, you know, their number one. Well, I find your other... I'm sorry, go ahead. So if you find that they are doing things by hand

that they could easily do by using components from the market, for example, if they are doing packaging by hand, running some set of scripts instead of maybe using Conan or CPAC or whatever, then I

would say that's one of the signs. That's just one thing, right? But in-house solutions usually aren't that good, but I guess if you're Google, then maybe yours actually could work.

If you're smaller than Apple, then maybe yours actually could work. Yeah. If you're smaller than Apple, then you should maybe be making your own in-house solutions, possibly. That's a good rule. The sponsor of this episode of CppCast is the PVS Studio development team. PVS Studio is a static code analysis solution that helps enhance code quality, security, and safety. The analyzer detects bugs and potential vulnerabilities in C,

C++, C Sharp, and Java code on Windows, Linux, and macOS. CppCast listeners can use the CppCast hashtag to get the analyzer's one-month trial version. To request the trial, use the link in the podcast description. C++ projects are getting increasingly complex, too complex for people to analyze them thoroughly during code reviews. That's where code analyzers come in. They notice everything the human eye misses, thus making code reviews more productive and enhancing code quality. Want to know more about the problem? Take a look at the recent article from the PVS Studio team,

C++ Tools Evolution, Static Code Analyzers. The link is in the podcast description. So you talked about CI and CD, and I don't think we've ever really talked about CD before. We've definitely talked a lot about unit testing and continuous integration. But could you tell us about CD and how it applies and what you go over in the book?

Okay, so CD has like two different meanings. And in C++ world, one CD is applicable most of the time, I would say. The other CD, only in some special cases. So one is the continuous delivery that you continuously produce new artifacts that can be used by the end users wherever they are. So when you say that, I think of like a website, right? No, no, no, no, no. Not necessarily?

No. Continuous delivery, like for example, ready to install binary, like an MSI with an installer, a Debian package, something like that. So this is like continuous delivery. You build it, you put it someplace, and people can use it. Of course, people have to take some steps to actually use it. But yeah, other than that, this is mostly that. If I can just clarify for my own understanding,

if I've got my GitHub pipeline and for each commit in my CI, I also generate an installer and post that so people can grab the instantaneous build, you would call that continuous delivery? Yeah, exactly. Because you don't have to basically do anything manually for people to be able to use your stuff. So that's that. And for continuous deployment is what you suggested, like a website, web service, whatever,

something that's actually made to run, not just delivering something so somebody else can run, but you actually are responsible for making it run. So I don't know. I didn't mention before like commodity trading services. So you have something that is, you know, crunching the numbers and taking some decisions. And you always want to have the fresh logic running on your servers.

So you want this to be deployed as soon as the code is tested. And that's that. And in that kind of scenario, that might be even multiple times per day, perhaps. Even multiple times per hour if you really want it. Yes, exactly. This depends a lot on how well is your test suite. Because if your tests are very good and you have all the possible scenarios tested, then you feel confident and can basically deploy each commit and that's fine. But if you know that your tests might not be

covering some cases because they are, for example, extremely hard to test, then continuous deployment, like several times per day might be, or per hour might not be what you want. But then again, if you want to practice continuous deployment, you probably want to have a rollback procedure ready, just in case those, you know, perfect tests are less than perfect. So yeah, that's that. And yeah, continuous deployment, I mentioned that it's usually meant to work with stuff, web services, stuff running on servers, etc. But not necessarily. You can actually have continuous deployment with IoT,

for example. You can have a fleet of trucks that are running some custom software for the drivers to be able to see the delivery schedule, etc.

And you can use technology like application containers to actually deploy the fresh version of your application this way. So this is not just limited to WebStuff, but like regular. Regular, I'm not sure it's regular. But you can say that you are running a desktop application on the IoT-embedded devices because these are not like

all-purpose PCs, but usually something a bit slimmed down just to show some UI, etc. I think an important thing when it comes to continuous deployment is that it's not all or nothing. You can do canary deployments,

like deploy to just, I don't know, one-tenth of your customers or servers and see if it works. If it does, then gradually move the percentage of the hosts using your new software. And also with continuous delivery, it's not that you need to always deliver. You always need to be ready to deliver.

I think it still includes like a button that somebody presses and bam, you have this release, right? But the thing is you should be ready instead of spending like three weeks looking for the perfect build because always some tests fail or yes and using the the holy build machine which is the only one that has the compiler and all the dependencies

installed on it i still remember the days you know out the days uh even a few weeks back i think i tried to do some some embedded development and getting the tool chain running. No, it was pain. Sorry, I'm still laughing at the holy build machine. I think we've all experienced that at some point, the one computer. Or you're like, oh no, it's going to take me a week to get my development environment set back up again, you know? Yes. I remember my very first job, I was sitting right next to the build machine.

I would have to be putting DVDs into it to actually burn discs for delivery. Yes, yes, exactly. And imagine what happened if the person who had the credentials to the machine went on vacation, for example. Or even worse, were sick, which is unplanned. I'm so curious what you were burning to DVD. Which job was that, Rob? Is it one you've talked about? That was my previous job.

It was navigation software to get installed on laptops. Right. Well, so the book, you say C++20 in the subtitle of the book, and we talked about some of the C++20 features that you had to have the latest and greatest builds for. Well, my company, you know, hypothetical developer, we're stuck on C++14. Can I still gain things from your book here?

Yeah, well, not the whole book is about C++ 20, right? Most of the book is actually applicable to any C++ standard that you may be using. We do put some pointers about things like app sale, for instance, so you can benefit from

libraries like that if you're using an older standard. Oh, okay. So yeah, I think you can still benefit greatly from all the contents. And even if you don't, I think it's still valuable to know about

the features that came into C++ 20 or 17. Even if you cannot use them, it really is a good thing to know about them. Worst case scenario, you can even try to think of something similar and implement it on your

own. But usually you can take AppSale or other libraries and just use this stuff. I mean, you won't use concepts, for instance, right? But still. The idea was to focus on the new standards to help people decide where each feature might be relevant. But still, architecture is something that is similar,

not just between the language standards, but even between different languages. So a lot of stuff is like equally applicable to writing, I don't know, Golang code or whatever else. Of course, not everything, because a lot of stuff is tied to C++. For example, when we are talking about building and packaging in C++,

this requires at least an entire chapter in some other languages. A lot of this stuff may actually be standardized and not require a lot of thought. But yeah, definitely, if you are using older C++, still there's a lot to learn, I think. And also, it's not only about C++, right? You can be stuck with an old CMake, for instance. And it's useful to know that

sometimes you can work around issues with all their tooling. So in some cases, companies can require that you only use things that you can install using the set of packages available in your operating system, right? And it turns out

that if you can use pip, for instance, if you can use pip for install, for instance, then you can pip install CMake and suddenly you have the latest greatest version or something similar. So sometimes there are really easy ways to bump up your tool chain. Also

sometimes you can just download a container and build your code in it or if you take, again, Python and you build some code using Python's many Linux containers, then you can actually, even though the Glypsy used in those containers is pretty old, you can still use new compilers. So sometimes there are ways to get up to date, even if you think that there aren't. Usually the reason why companies use older C++ standards,

I would say it's about glipsy compatibility. And sometimes you can just take a newer compiler, build it against a very old glipsc and you're good to go but yeah it's it's often the hardest part of doing it is convincing your managers to allow you to well since you're talking about uh compatibility with old libc versions do you address ABI stability concerns in here? What do you have to say about it? I'm making Rob laugh because we have to ring up

ABI in every episode but if you're talking about architecture of a large scale system it seems like that must at least be a consideration at some point, right? I mean if you're stuck with let's say the preGCC5 ABI, you can still compile using newer compilers, passing this flag to retain the compatibility.

So it's not like you're alone in the woods. But do you have anything in here for the C++ developer and whether or not they should be worried about ABI stability from one version to the next of their tool? Yeah, I mean, that's a serious issue, and definitely you should take it into account. Even if you try to use things like AppSale, for instance, depending on the C++ standard version that you're using,

you can end up with AppSale symbols resolving either to their implementations or the standard library ones. So that's not even as much as an ABI incompatibility symbols resolving either to their implementations or the standard library ones. So that's not even as much as an ABI incompatibility as it is for an API incompatibility in this case, right? So you don't even need to dive into ABIs to have some issues with mismatched versions. Yeah, we are also mentioning Conan as a package manager, dependency manager, basically, for C++ in a book. And this also has some ABI-related consequences because I think by default, it configures GCC to use the old ABI and not the new one,

yet the packages are mostly using new ones. So it's necessary to be conscious about it and configure the stuff so it works properly. I recall they had plans to actually change this default in Conan 2.0, although I haven't checked if they did it. So maybe this problem is already gone, fortunately. Yeah, I've been bitten by that a few times, so I now remember to check it the first thing whenever I see an error.

It's the API set properly right so what are some of the best practices that you talk about that you know should be used if you're starting on a new project maybe okay so yeah some of the obvious ones are

to actually use what the C++ language gives you, right? So use RAII and if possible, use a pretty recent compiler version or C++ standard. I think we mentioned also to have a pretty good set of tools pre-installed, like use Clang Tidy for your project up front, because if you want to add it later on, you will always have issues, and it's not that easy to introduce the project

easily. So I think having linters and all of this infrastructure around your code early on can go a long way. Aside from that, if you know what you should be doing in this project

in some perspective, you can think about what are the important design points, like where to put your focus when you try to design the system properly, right? I cannot give you ready answers how the system properly, right? I cannot give you like ready answers how to structure it, right? But definitely if you plan ahead instead of just improvising

or hacking back in time, you could be better off. Yeah, and also make conscious decisions about stuff like having tests at hand, thinking about performance, thinking about security, because I think performance is something that people usually have in their minds. Security is still something that is not as widespread as it should be, knowledge about how to make stuff secure. So yeah, this is like sit down for a moment and think where you want this project to be in when you finish it

and then choose appropriately, pick up the best design patterns, pick up the best tools to help you get your job done because we have a lot of tools that can help us automate stuff, that can help us make our code more secure, more performant, whatever. But we need to introduce them early on and first

of all we need to be aware that they exist because because a lot of people are still stuck in a in a world where there is you know gcc there is make there is auto tools and that's all or there is just you know visual studio solution and you just press build and that's all. Or there is just Visual Studio solution and you just press build and that's the entire automation around your project. And there's tons of stuff that you can use that could help you write better code. So, yeah. Yeah, so it's important to,

if you have some features or qualities of the software, if you identify the need for them early on, it can really go a long way. So one of those is also portability, right? I've seen many projects where they assume from the start that, yeah, we'll always target just Linux. So yeah, don't bother. We can use everything from like the POSIX API, Linux headers and whatnot.

And then suddenly in the vast majority of those projects, there finally was a need to either support, I don't know, Android or Windows or any other platform. And suddenly you need to figure out how to change your system specific, like maybe Visual Studio based project to something that can actually be built on many systems. Yeah, and this is actually something that CI can help you with because it's relatively

easy and relatively cheap to have a CI pipeline for platforms that you're even not actively using, just, you know, making sure the stuff compiles with different compilers. Yeah. Yeah, and you get the additional benefit of just making sure the stuff compiles with different compilers. Yeah, and you get the additional benefit of, just like you said,

checking with multiple compilers, and usually they can give you a different set of warnings or errors in your code. They can point out things like assignment instead of equals or the other way around. I was surprised to learn that GCC doesn't detect it in any in every case. It does it for some types

of variables, but not for all of them. And this is something that Clang will detect without any configuration, just on default. So it really goes a long way if you try to be portable from the start and build your project with multiple compilers from the start. Right. That's some good advice. Nice. I will just say, as I was flipping through your book, like it's been more than 10 years since I've needed to do any real distributed development work. So I just found it like even just from like a reference perspective to be able to go and look like what is Kubernetes?

What does it mean to me? How are dockers used in modern distributed architecture? You know, what's the state of the art and message passing systems, like all that stuff. Like if you're someone like me, who hasn't like had to deal with like a modern system architecture in a while and a big scale, it totally could bring you up to speed on just a ton of terminology, if nothing else. Okay, where to start? Well, no, you don't need to, you don't need to go into any of that. I'm saying your book has all that in it. So I appreciate that.

If there's anything you want to highlight, by all means, go ahead. Don't feel like you have to define all those things for our listeners right now. I was encouraging the listeners to go buy your book so that they get those definitions. Okay, cool. Actually, yeah, since you've mentioned all this stuff, I think it's useful to share the fun fact that one of the most popular web proxies, so stuff like Apache, NGINX, AJProxy, et cetera,

is actually, like in the number of deployments everywhere, is actually a project named Envoy, which is written in C++ and mostly targeted at the distributed systems. Usually it isn't even deployed as a standalone thingy, but as a sidecar so something that goes along the main service. So yeah C++ is still widely used in distributed system in cloud native environments even though Golang is eating most of the pie currently,

people are still seeing that there is a place for something like C++ if you need to for example get more performance out of this stuff or whatever. So that's

really cool. We did talk to someone from Lyft about Envoy about a year ago, Jason. out of this stuff or whatever. So that's really cool. Cool. That rung a bell. We did talk to someone from Lyft about Envoy about a year ago, Jason. That sounded perfect. I was wondering if that's what you're doing because I thought that might be part of the possibility there. Yeah.

All right. Well, we've talked about a lot. We're starting to run low on time. Is there anything else that either of you want to share about the book to maybe pique our listeners' interest? Piotr, maybe you have something? Yeah, I'm thinking, actually.

We've touched a lot of different points so far, so I'm not sure if there's anything that is missing. Yeah, we tried to go broad. And we still had to cut some content out of the book. We only did an appendix on company culture and how it relates to the

DevOps idea. So basically we could write another book on this. But I guess there's lots of ideas covered in the book. And even if you're not familiar with them, this broad overview that we give can benefit you. And sometimes it's good to even be aware of things and you can then do some further

research on your own right like exactly devops culture but what adrian mentioned is actually pretty important and i'm glad you said it because uh a lot of technical books focuses on like just the technical parts like okay this is a book about architecture, so we are telling you all the dry facts about architecture. But the truth is that at the end of the day, there is a person who you will be working with to implement this stuff. And this is something that is very obvious once you say it, but software architecture is all

about teamwork and about communicating with your team, so you still need to have this in mind when you are doing any project, right? So we also wanted to

touch this cultural aspects of software architecture with it. how to conduct code reviews, et cetera. But yeah, this is still something very important because even if you design like the best possible architecture on paper, unless you have a team who can deliver, your product won't fly very high. So that's it. Okay. How long did you both spend writing it, by the way?

Excuse me? How long did you spend writing the book, both of you? I think almost two years. But of course, when we started, the plan was like half a year. And we were talking with other authors, how long does it take to write a book? And they were like, well, you know, it's two years. It's definitely two years. And we said, yeah said yeah yeah maybe for you not for us we only do it in half a year so yeah two years to be frank it wasn't just writing right i think when summer came we did

some some breaks from writing so writing to enjoy life outside work. And it was a part-time project, right? We were working our day-to-day jobs and the book was created in our, let's say, spare time. So, yeah, two years, but as a side project. I think if we would just throw our hands in and leave everything else aside, then we could

do it even much faster than this, half a year. Let's say that it would still take half a year because, yeah. Well, we'll challenge you. The next book you write, let us know how long it takes. Okay.

All right. Well, it's great having you both on the show. We'll definitely put, you know, links to the book into the show notes, encourage listeners to go check it out. Thanks.

Great. Thanks. Perfect. Thank you. See you. Thanks so much for listening in as we chat about C++. We'd love to hear what you think of the podcast. Please let us know if we're discussing the stuff you're interested in, or if you have a suggestion for a topic, we'd love to hear about that too. You can email all your thoughts to feedback at cppcast.com. We'd also appreciate

if you can like CppCast on Facebook and follow CppCast on Twitter. You can also follow me at Rob W. Irving and Jason at Lefticus on Twitter. We'd also like to thank all our patrons who helped support the show through Patreon. If you'd like to support us on Patreon, you can do so at patreon.com slash CPP cast. 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 podcast themes.com.