CppCast - Modern C++ in Embedded Systems

Episode Date: July 5, 2018

Rob and Jason are joined by Michael Caisse from Ciere consulting to discuss Modern C++ in Embedded Systems, boostache and his work at Ciere Consulting and in the C++ Community. Michael Caisse has been crafting code in C++ for 28-years. He is a regular speaker at various conferences and is passionate about teaching and training. Michael is the owner of Ciere Consulting which provides software consulting and contracting services, C++ training, and Project Recovery for failing multidisciplinary engineering projects. When he isn't fighting with compilers or robots, he enjoys fencing with a sabre. News Herb Sutter Trip Report Announcing C++ Just My Code Stepping in Visual Studio cmake release manager AMA C++ On Sea call for speakers still open Michael Caisse @MichaelCaisse Links ciere consulting C++Now 2018: Michael Caisse "Modern C++ in Embedded Systems" boostache El Dorado Hills C++ Meetup Sponsors Backtrace Patreon CppCast Patreon Hosts @robwirving @lefticus

Thank you. at backtrace.io slash cppcast. In this episode, we discuss Herb Sutter's trip report and just my code debugging in Visual Studio. Then we talk to Michael Case from Kiera Consulting. Michael talks to us about modern 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 Irving, joined by my co-host, Jason Turner. Jason, how are you doing today? I'm okay. I am sick. I seem to have gotten some crud on the airplane coming home, but I'm back in America. Back in America, just in time for the 4th of July, right? Yes, and my dog has been terrified for at least the last week because of everyone setting off fireworks. Oh, yeah. And because this is thunderstorm season around here. So it's either been a thunderstorm or fireworks every day for, I think, over a week, and she's just over it. You can see it on her face.

Poor puppy. Yeah. Like, refusing to eat, that kind of thing. Oh, man. I hope fireworks calm down and she can get back to her. Yeah, I haven't heard anything yet tonight. And the people around here have been starting it while the sun was still up, which is still confusing for me. So maybe they used the molifosmite.

I can't really see them that way. Okay. Yeah. Well, at the top of our episode, I'd like to read a piece of feedback. This week, we got a comment on the website from Tony about last week's episode. He said, Titus mentioned a possible proposal or desire to either slow the evolution of C++ or provide better structure for rapid changes. The churn of modern C++ has concerned me as well.

Perhaps the committee should consider a rolling versus stable model similar to some Linux distributions. For example, new language library features would migrate from experimental to testing to stable with experience and confidence, perhaps years for some features. Defining these terms would take some effort, but a simple first pass could be experimental features are under development

by compiler groups, testing features are available for general use with the caveat of future breaking changes and stables for features that have had sufficient use that breaking changes would be unlikely. In this way, mistakes could be caught before being fully baked into the standard, the number of deprecations or modifications would be reduced,

and tooling providers would have more opportunity to exercise the standard. Thoughts? I thought that was the entire point of the TS system. Yeah, that's kind of what I thought too, that by putting something in a TS at least one of the many compiler vendors is probably going

to implement it and let users use it before it becomes standard but I guess they're saying but I guess TS might be limited to larger features like modules are in a TS but some smaller feature

is just going to go straight to the standard. Right. Right. So yeah, they're, they're saying kind of bundle everything into some, you know, preview version. Right. I have no idea if that's feasible or not, but. Yeah, I don't know either.

Well, we'd love to hear your thoughts about the show as well. You can always reach out to us on Facebook, Twitter, or email us at feedback at cbcast.com. And don't forget to leave us a review on iTunes. Joining us today is Michael Case. Michael has been crafting code in C++ for 28 years. He's a regular speaker at various conferences and is passionate about teaching and training. Michael is the owner of Sierra Consulting, which provides software consulting and contracting services, C++ training, and project recovery for failing multidisciplinary engineering projects. When he isn't fighting

with compilers or robots, he enjoys fencing with a saber. Michael, welcome to the show. Thank you very much. Good to be here. Saber is a relatively heavy sword for fencing, isn't it? Or am I thinking of something wrong here? Well, there are three weapons in the sport of fencing. Foil, epee, and then saber. And saber is a slashing weapon. Foil and epee are poking weapons.

Poking weapons. Okay. Yes, yes, poking. So they call us the knuckle draggers. So the saber fencers are the knuckle draggers of the group. Everybody else is more refined. Right. It's like you may as well actually be in like SCA or something compared to like a real sport.

Yeah, I won't admit that I was an SCA in college, but I might have been. You might have been. I never was myself i didn't know some people that hung around uh that uh group yeah in that world i'm gonna i'm gonna go ahead and app myself that i used to play larps so we we mentioned sca and larps on this show that's the first that's awesome yeah okay well uh michael we got a couple uh news articles to discuss uh feel free to comment on any of these and then we'll start talking to you more about uh modern embedded c++ okay sounds great okay uh so this first one is um another trip report i feel like we've been

talking about rapper's will for a couple weeks now but there's been so much talk about yeah and this is a herb service report which is great goes into a lot of detail um i i really liked the way he's really selling contracts as the biggest feature so far for c++ 20 yes i feel like from a teaching perspective, I agree. It's the most important thing here so far. I think just as a whole package, in comparison to maybe even concepts or modules or things like that, contracts are going to have a lot larger impact, I think, on the general population. I'm pretty excited about contracts. Yeah. One of the things that I like to teach is, you know, some of these things like, I mean, it gets a bit wordy by the time you have const, constexpr, no accept, no discard, you know, on a function declaration. But they're all about expressing some, the intent of the code. And contracts gives us yet another tool to express the intent of the code.

Right. And I also like the point he made about how this could significantly reduce the number of exceptions and how if you look at other languages and how they handle exceptions, like a large portion of exceptions that are thrown are like the no argument exception. And with contracts, those could all just go away. Yeah. Is there anything else you wanted to call out in uh herb strip report jason um not that i recall at the moment although i was glad that feature test macros were approved it's definitely something that i wanted yeah and i agree with with uh herb statements here that here that it's necessary because not all compilers are going to adopt things at the same rate.

Right. Although they all are getting much better about adopting things quickly. Yes. Anything else for you, Michael? The metaprogramming side of me is appreciative of explicit bull, but pretty much the same items okay future test macros are great i'm not a fan of magro but future test macros are pretty nice right well i'm also uh i forgot about this bit casting um which i think we probably mentioned in a previous episode but

uh to be able to tell people look you're using reinterpret cast wrong, and you actually have to use mem copy or whatever here and look, the compiler can optimize it away. But actually say here is a standard thing, bit cast, use it. Looking forward to that as well. Yeah. Okay, next thing is an announcement from the visual C++ blog, announcing C++ just my code stepping in Visual Studio. And this is something that, you know, I am really excited to have in my, you know, Visual Studio compiler coming up. Because it's really annoying when you're stepping into something where you, you know, calling into the standard library or something like that. And you F11 and go into standard library headers. You don't really want to be looking at that.

You just want to look into your code. And they have some ridiculous examples where you could be hitting F11 like 140 times, and now with this new feature enabled, it's just a single step in, and it does what you would expect it to do. Well, that 140 times is just for an any-of algorithm call. Yeah, yeah.

Do you use Visual Studio at all, Michael? I don't use Visual Studio. Very seldom do I actually fire this up. But I think if you remember at CPP Now this past year, Jeff Troll gave a talk about GDB and how to do this with some instrumentation that he had placed on there. He has a blog post about it, I think from April on his blog. And it's pretty cool. So this is a problem that I know I see a lot. I'm sure you see when you're doing training, people griping and complaining about stepping into things that

they didn't really mean to be in. So this is a wonderful feature for any debugger. Yeah, I was not aware that there was anything like this for GDB. I didn't see Jeff's talk. Jeff kind of made one of his own, so to speak. Right. With a little bit of Clang magic and a little bit of GDB magic and Python to glue it all together. Cool. clang magic and a little bit of gdb magic and python to glue it all together cool yeah the other thing worth mentioning is in addition to just automatically f11ing what you would kind of

normally expect stepping into what should do um if you right click in the you know debug menu that pops up uh there's a new option to do step into specific, which will give you options to step into some of the other functions that it's going to automatically skip over when you hit F11. Although I wonder if in this case that they show where it's stepping in 140 times with the algorithm, if you would have 140 different options in that context, that might be difficult to look at. That would definitely be difficult to look at.

Yeah. Yeah. Okay. Uh, Jason, did you want to talk about this next one? Um, uh,

uh, CMake release manager, AMA. Yeah. You know, it was, well, in my opinion,

shockingly civil, uh, discussion on Reddit of, uh, uh people just that was just as you said the cmake release manager didn't ask me anything and it's why i wanted to share it as you know a lot of us complain about cmake but you know getting some like appreciation for the real people behind the project and having them uh uh, you know, ask these or ask, you know, questions,

but it's immediately like seeing like people complaining about how easy it is to get to out of date documentation. And within like a couple of hours in the discussion, they're like, you're right. Uh, we really need to put a header that says this is the out of date documentation.

Click here to go to the most recent stuff. And it's already up and working. wow yeah so they they immediately improved their website a bunch of people were asking for feature stuff and it looks like there was some movement on some things i was pretty impressed with the whole conversation and i learned several things as well about cmake yeah i saw that the the top post is about is this complaint you said about the documentation i'm really happy to hear that they they have updated it that's great yeah i immediately uh improved it that's pretty cool i was just looking at it while preparing for today michael do you use cmake much uh we use cmake quite a bit because our clients primarily use CMake.

We use BoostBuild also internally quite a bit. So between the two of them, there are really two different ways about thinking about the problem. One thing that I can say is the more so-called modern CMake is palatable. You know, it's not so horrible with globals all over the place and whatnot. So it took a few different items, usage requirements and things like that from Boost Build, and those got moved in to CMake, and those types of features are really wonderful. I've been using a lot of CMake more recently myself.

I've got people on the team who are a lot better at CMake than I am, so they typically try to just keep me away from it. Keeping the boss away from a project, is that hard? No, I don't really want to work on build systems, so it's okay. Okay, and then this last thing we have that's mentioned is C++ on the C, which is a new conference in England that we talked about with Phil Nash maybe like two months ago. And they are having their call for speakers.

Yeah, and Phil, well, I asked Phil how the call for speakers was going, and he told me that they could still use always some more submissions so i thought we should give a shout out here yeah is there a cutoff date i don't see a cutoff date listed you should probably put some specific dates on here but um i i have submitted myself to do a training day and i don't't know, obviously, if that will be accepted or not, but hopefully it will be. Okay. And it seems like it's just a Google form to do your submissions.

Yeah, it's a pretty straightforward form. Oh, and on the topic of conferences, the announcements for CBPCon just went out this afternoon, so everyone should at some point shortly here have gotten their, whether or not their talks were accepted. Did you submit anything this year, Michael? I did. And just a few minutes ago, I received my acceptance. You were accepted? I just figured it was hidden.

A little unsure there. I actually got both of my docs accepted that I submitted. I wasn't sure if that would be the case or not this year. Awesome. We had quite a few submissions, and it's a lot of work going through each of those. Bryce does just a tremendous job reviewing every single one of them and then every single PC comment that's given. It's really great. They had just a ridiculous number of submissions, right?

I think there were about 220. If you don't mind, I'm going to pull up Bryce's most recent tweet here about how much we have going on so 137 talks accepted 72 rejected

118 content hours accepted for the conference it's going to be a full conference this year yeah and the lineup looks really good is there the full schedule out now or the full lineup i guess uh the schedule is definitely not out yet no he's just emailing people as far as i know okay okay well since we're talking about conferences um this year at c++ now mich, you were giving a talk about the current

state of modern C++ for embedded systems. What is the current state? What did you share with this talk? Yeah, so the current state, sadly, has not changed much. It's about the same as it always is. And that state is one in which chip vendors are not very supportive of C++. And so if you're trying to do embedded, especially on bare metal, it's very difficult to get everything from startup code and linker scripts and whatnot configured just right in order to try to use C++. And sometimes they even go through really hoops to try to make it so that you can't enable C++ in your project using the tools that they provide. It's hard, but if you watch my talk, I think I try to present it in such a way that it's worth it. It's going to be hard up front

to get it going, but in the long run, the benefits far outweigh the hassle that's up front. Generally speaking, these chip vendors are using GCC or Clang or some open source tool, right? Yeah, so they use something like that, and most of them will wrap an IDE over the top of it. And the IDE becomes important in the sense that there are special things sometimes in these chips in which they will produce a mapping file or whatnot in order to kind of glue some of the fabric together. Or they have specialty devices, specialty cores on the device, and those need to be programmed, especially IO and whatnot. And so they kind of almost try to lock you into

using their IDE and their tool set, which is really a wonderful tool set typically for what I call time to hello world. It's great for demoing. It's great for getting things up and going. You feel very confident about it, but they don't integrate into continuous integration systems. They don't work for large teams. There's just like a lot of downsides and problems for things that we would normally think of as common ways to develop software, best practices for developing software. Yeah, it does seem like that time to hello world is probably pretty important

when someone's deciding which chip vendor to go with when they're building a project. That's correct, yeah. And you're right. Most of them are built on open source tools. And so you could always just go, if it's an ARM type device, for example, you just go to the ARM website and get the bare bones ARM compiler. And then you have to fight a little bit with trying to get linker scripts and startup code going.

But you can usually start off with whatever the vendor has already supplied and make some modifications to that for your own use. Were you able to come to any conclusions as to why they seem to be going out of their way in some cases? Yeah. So I think this is an opinion. My opinion is that it's hard to support and they don't want to support it. So we've run into multiple problems along the way. I think this is an opinion. My opinion is that it's hard to support and they don't want to support it. So we've run into multiple problems along the way.

Tech support is typically pretty good about you send an email or you get them on the phone and they try to help you through things. And almost without question, it's always the don't use C++. Why are you trying to use C++? And there's this concept of C++ just being this big bloated language, you know, C with classes and a whole lot of extra bytes to come along the way for no gain. And I think you can see that as people use C++ inappropriately for small devices, as well as just the myth of C++ over the years. I know, Jason, when you were on Embedded FM, you could kind of hear that.

Like, we're not really sure about it. We're very cautious. We seem scary. Why would you go through that pain? And I think I hear that from tech support inside of chip vendors too. Probably a lot of bad experiences, and it's not worth it

just you see so the linker script is good for c but what doesn't have like the section set up for like rtti and exceptions and that kind of thing or yeah so that's the beginning of it rtti and exceptions but if you think about it it's even more than that it's just like static constructors destructors those that code has to go somewhere. And so the sections in general need to be reworked. That's why you don't use statics. Yeah, it could be why you don't use statics. Though in Embedded, you use static a lot in order to grab some memory right up front and use something for the lifetime of whatever this device thing does.

Right. So if you had, for example, a static thing that represents a circular buffer, right? A circular buffer is probably gonna be some static thing. You're not mallocing, there's no malloc. There's no memory allocation system. So you grab that memory up front, that static class or object of some sort that you're utilizing.

And unless you go into the linker script and fix some things up and fix up your startup code so it knows to initialize static objects, you're kind of lost. So there is a jump going from C to C++, but going to C++ is really worth it. In the end, there's just so many benefits to making quality code that you can reason about. Do you see this situation changing? I mean, I see lots of conference talks and articles being written to the C embedded developer, kind of trying to sell them on C++, showing it's not so scary. But as far as the hardware vendors go,

is there anything that can be done to make them embrace C++ a little bit more? Yeah, wonderful question. I think a lot of it has to do just with these old perceptions. So whether you're talking to a C-embedded individual or you're talking to somebody who is in the manufacturing world or the world of tools and trying to support these people it's education it's trying to show them what are the benefits and why why is this a good thing along the way there's a fairly large conference called DAC design automation conference that deals with this type of thing for the embedded world and and tool and whatnot. And they have recently started C++-type tracks at their conferences. And so that, I think, is good for helping educate.

I know I've been speaking over the last couple of years, I've been speaking at actually chip manufacturer locations as well as other design automation-type locations on, locations on site in the Bay Bay area, just trying to help educate them what is C++ and the whole idea of just like zero cost abstractions are both amazingly wonderful and incredibly scary to, to a standard C developer. So if we can get to a point where we can educate people a little bit better, I think, I think the world will be better.

I'm hoping the world will be better you know on the topic of um misconceptions i one of my most recent youtube videos for c++ weekly is um using a dos compiler for 16 bit 8086 and one of the comments on there was, just don't do this. It's not worth the overhead with all the V tables. And the example that I had had no virtual functions. There were no V tables anywhere in sight. I responded to it like, perhaps I'm missing something. But I don't think you were looking at the same code that I actually demonstrated.

Yeah, I think, and that's normal, right? In the sense that there is a whole body of fears that people have, legend that has moved along. And some of that even grows even more as we talk about it, and you trade ideas with people of why something's so horrible. And it started in the 90s with talking about there were a lot of horrible things in the 90s with people trying to put C++ on embedded systems. And I think a lot of those fears have never been alleviated. We program in a lot of different ways. And that's something that I think we appreciate for sure about C++, right?

Is that there's so many different idioms and ways that you can program with C++. C++, it's not just like this object-oriented mechanism or, you know, there are lots of ways the language enables. You just use the mechanism that makes sense, the idioms that make sense for whatever

it is that you're trying to target. Right. So in addition to all your work in Embedded C++, you've also been actively involved with C++ Now and BoostCon for a long time, right? Yeah, that's right. I think my first BoostCon conference was since 2009, which was the second conference. I missed the first one, but I've been involved with it since then.

It's a really enjoyable conference. And then, of course, I've been involved with the first conference with CPP Econ. I really enjoy the community. I think every time I end up at a conference, one of these two conferences, I'm just encouraged by the community that we're within and how people really support one another and are just striving constantly to figure out how to make the language better and more accessible. You mentioned in your bio, and I did not call it out then, that you said you have 28 years of experience with C++. So that kind of seems relevant to all of this. You've really watched things grow and change. Yes, I have.

When I started working with C++, I had the ARM, the Annotated Reference Manual. There wasn't actually a spec yet. And I think I had that thing memorized, sat by my desk constantly. I just loved it, right? But that is a lot of it is people who've grown up with the language as the STL was coming out and such, you were really tainted about a lot of different things early on. You know, the small talk people trying to do object-oriented in a way on C++ that didn't probably make sense. It wasn't a good fit. You know, we've got all the whole

boosh mechanisms or the Schleyer or the whatever, all these different ways of doing object-oriented that were just inundated in the 90s and now looking back, you're like, wow, what in the world were we thinking? There are such better ways to write software. At least that's my own personal opinion. And a lot of people are still stuck in that what we did in the 90s and see, I think, C++ as what evolved in the 90s. And it's just not that anymore. So our listener feedback was talking about the language moving too quickly.

And since you've kind of been there for the whole life of the language, effectively at this point, how do you feel about that? I'm excited about seeing it moving again. I really am. I do, though, have, you know, I agree with the feedback in the sense that there are some things that seem like they're released too soon. Maybe there's a better way to tease some things out. You know, library bits, I think, need to have more exposure. Obviously, I'm very involved in Boost, and I would love to see more things go through Boost,

but it doesn't have to be through Boost. It could be through some other mechanism where we can actually see users utilizing library features, kind of teasing them out, understanding if they make sense or not, what kind of modifications might be needed. We would never end up with standard async if we had done that, right? them out, understanding if they make sense or not, what kind of modifications might be needed. We would never end up with standard async if we had done that, right? I mean, just where did that come from, you know? So I think there are a lot of things that getting user exposure, we see and

understand sooner. So in some places, yeah, it'd be nice to see it slow down. In other places, or at least get tested out so that we're really seeing users apply and understand how things should work. I don't want to see it slow, though. I think the three-year relay cycle that we have right now is really wonderful. There might be fewer things in it, that's fine, but it's nice to have a relay cycle that we went so long without any.

Yeah, I wasn't paying so close attention but was on the outskirts during this whole lead-up to C++ 11 era and you're like okay let's go ahead and get this over with um you've mentioned now boost a couple of times you you are actively involved involved in boost as well yeah so i've been um i've been involved in Boost since, I guess I came in late to Boost, so to speak. I came in like in 2008 or so when I started really working with Boost in some manner. I've been on

the steering committee now for a while. Kira hosts a lot of the infrastructure and whatnot for Boost. I think Boost is a wonderful thing. It's changed quite a bit over the years, but I think my grounding in modern C++, and I use that like in the Andre mechanism of modernist, right? Just like this idea that the language could be something else and be so much more really came in through Boost and my exposure with

authors and other people involved in the community wanted to give up their time to to teach about things and so i i learned a ton about the language by being involved in the community so uh to clarify the name of your company how do you pronounce it again yeah it's kiera kiera and um yeah it's a latin word It means to put in motion or to conjure, to set forth. So kind of that idea of what we do with, hopefully, with software. So you said your company hosts a fair bit of the Boost infrastructure, that kind of thing. Is that right?

Yeah, the hosting is actually done through another... We help run it. Right. You don't actually have a bank of servers in your office. We don't have a bank of servers running it. No, those are elsewhere. Okay. But we use our IT department here to help with that.

It seems like it would be a big undertaking, the automated build environment for boost to test many many compilers right it does the the tests are actually ran by volunteers so people volunteer their own machines and um so the testing infrastructure is distributed throughout boost is kind of interesting in the sense that it was before GitHub. It was before all of these CI systems we have, right? There was really not a distribution mechanism for software back when Boost came around. You wanted C++ libraries. It was kind of like the place to go. It was hard to figure out how to get libraries any other way. And large testing infrastructures just didn't exist. And so they came up with a mechanism to have tests run.

You volunteer resources and machines and whatnot and run these scripts. And it runs the test and sends the results back off to some central server that then collates those back into the reports that you see. So anyone who's interested could just run the script on their machine and it would collect the appropriate data and send it off? Yeah, exactly. And so we're dependent upon the community. If you're interested in a compiler or a platform,

the way to be involved, one way to be involved is to run the tests on your platform and compiler that you're interested in so that authors can get feedback about how well it's working. Oh, okay. That makes sense. Interesting. I wanted to interrupt this discussion for just a moment to bring you a word from our sponsors. Backtrace is a debugging platform that improves software quality, reliability, and support by bringing deep introspection

and automation throughout the software error lifecycle. Spend less time debugging and reduce your mean time to resolution by using the first and only platform to combine symbolic debugging, error aggregation, and state analysis. At the time of error, Bactres jumps into action, capturing detailed dumps of application and environmental state. Bactres then performs automated analysis on process memory and executable code to classify errors and highlight important signals such as heap corruption, malware, and much more. This data is aggregated and archived in a centralized object store, Thank you. infrastructure it's free to try minutes to set up fully featured with no commitment necessary

check them out at backtrace.io cppcast one of the projects you manage boostash started as a c++ now librarian a week is that right it is yeah library in a week is by far my probably my favorite session at the conference um you know it's conference generally starts at nine for, for the talks. But if you were crazy enough to get up and be there at eight, you get to work with just some incredible people in the community trying to solve a problem. And, you know, you come together as a group trying to either write a library in a week, which is almost impossible, of course, or something or another.

So one year that I worked on things, it was converting libraries to C++11. And not knowing at all what I was thinking about, I picked BoostBind. And that was the one I was going to convert to C++11. I learned so much that year. That's like the most complicated piece of software ever written. I had no idea. I think this was in 2009, I believe, is when my first conference there. Yeah, it was wonderful, though.

There are techniques and such that you learn. There's so many people who are just really quite smart and think outside the box. And they show up at this library in the week, and exchange ideas and you try to work on something together whether it's through lunches or sometimes over dinners and you know throughout the conference you hope that you produce something towards the end and boostash was one of those where we had something somewhat working towards the end of the conference so we just kind of picked that up and continued to work with it so what is boost? So a lot of people are familiar with template type, like the web, from a web point of view, template processing programs where like Mustache, where you have a template, and there's going to be some things that are replaced in there based upon some syntax, like for mustache, it's double curly brackets or variable names, and it's going to get some data that will represent how to replace the items in there. And so it's a template engine. What's unique about it is that it has a variety of different front ends. So mustache is one of

them. It has a mustacheache front-end processor. And it takes that, reads it on in, creates an IR, because we can have multiple front-ends. So we have an internal representation that will then run through a virtual machine. And then on the data side, because I like TMP and things of that sort, we wanted to be able to allow the user to provide any data tree at all, not just JSON or not just, I'm going to tell you what your data should look like.

I just want you to be able to call it and pass in whatever data you already have in your program and have that fill into the template. And I've given a couple of different talks on how BoostDash works, but at compile time, basically, it runs through this AST that may be some recursive data type set that you have, and it builds itself and understands what to do,

like what to do if it's an iterable thing or what to do if it's a testable or if it's a printable thing or how to get variables out. And it categorizes your data types as it grovels through your thing at compile time. That sounds like something that you would have wanted reflection for. Yeah, potentially.

So it is a type of reflection that we do. Reflection would have been nice, perhaps, yeah. The key, I think, boost dash is a representation of a representation of what may not have been done perfectly, but the idea is that you think about what an interface to a library should look like, how I want to use it, and then you write that as the interface, and then create all the ugly whatever you have to do behind the scenes in order to make the user experience wonderful, easy to use, hard to misuse, and just be an elegant solution.

I think we've done a pretty good job of that, but I'm sure there'll be plenty of tweets that I get soon that tells me why it doesn't work well. Yes, the problem with open source projects is having users, basically. Yes, if I didn't have users, it would be a lot easier. We do use it internally, actually, for a couple of our projects. So it does have real commercial use.

Now, if I understand correctly, you have done efforts to mitigate the compile time issues with something this complicated that's template-y. Is that correct? Yes. is that correct um yes there there are a variety of different things that we do um to mitigate compile time i mean you have a and you're always gonna have an initial compile time hit right and this came out from working with spirit um one of the people that works with kiera is joel joel de guzman who's the author of spirit as well as a few other boost libraries and i mean we spend a lot of time with spirit as well as a few other Boost libraries. And we spend a lot of time with Spirit, as well as other things that are very heavy template. And I don't want to spend my

whole life recompiling template things that haven't changed, right? And going about it by creating these header-only whatevers, that's great. But for a particular application, I probably know what my instantiations are going to look like, and they're not going to be changing throughout the application. Or maybe I'll add another one later. But I'm going to use extern template, and I'm going to use explicit instantiation

inside of some CPP file, some compilation unit. And I'm going to compile it one time, right, for that particular version. And then I'm not going to have to take the hit every single time for the compilation. So that's one of the tricks that we might use. Xtern template was added in C++ 11, is that correct? It was added in 11. It's been supported for a long time by most compilers, but it was added officially in 11. So I've never actually used Xtern template. Can you describe?

You said you have an explicit instantiation and a CBP file, but then somehow you have to make this template available. Right. So what you do is inside of the extern template, you use extern template, and then what is the templated thing with all the parameters spelt out somewhere?

And the way the compiler looks at that is, hey, somewhere this is going to be completely defined. I probably know about it somewhere. Okay. And I can go look that up as opposed to instantiating one again right now. And so every single time that the compiler sees it, it doesn't need to reinstantiate it for the compilation unit.

It knows that there is one somewhere. It can go and take care of that. And something as simple as that can really dramatically speed up your compilation, especially for something like Spirit. But a concrete example would be, let's say you use vector of string. So you would do extern template vector string, and you'd have that inside of this header file,

in essence, right? And that'd get pulled in, and inside of some compilation unit, you would have the explicit instantiation of that, and the compiler can find that explicit instantiation without having to re-instantiate it

every single time that it encountered it. Now for vector string, not so important, but for a grammar that's in spirit or some of these other very heavy, you know, TMP type things that we end up doing in order to make life beautiful for users, it's a big deal. Even for boost dash,Dash, what are the types of things that are important? Well, your iterator types are going to be template parameters, but the reality is for your application, you probably end up with

one or two iterator types that you use for the whole thing. There's no reason to take the hit of recompiling it every single time. Go ahead and extern template that somewhere, and then go ahead and create your explicit instantiation, and just do it once, and from that point on, it looks like an object file that you're linking as opposed to the big hit so you don't have to uh like firewall the templates and from a header standpoint you can

have everything still visible as far as your user is concerned you're just pound including the normal thing but it's but the compiler sees the extern template and says, okay, gotcha, I'll look for this other instantiation. Yeah, so what we will typically do is we will create for an application that we're working on and include for that library. And let's say it's a grammar for a spirit thing that we're working on. And maybe that grammar is being used over and over again for different applications so what we'll do is we'll have one level of indirection of course and we'll include those grammars inside of that and within that same one level of abstraction header file we'll have then the extern template of the instantiations that we're going to create and use within our application. And so we just use that header file over and over again.

So in C++ 14 and 17, we can do so much with generic lambdas and constexpr, which is this, it's metaprogramming kind of things, but it doesn't look like templates anymore. Right. With a lot of, I mean, like, can we extern a constexpr function? I've never seen a way to do that, to try to get the same kind of thing you're talking about.

No, not that I know of. Yeah, I don't know a way to do that. Yeah. So, yeah, I don't think there's a way to do that. It seems like it could be handy this is one thing that in my opinion the only drawback to constexpr is the definition has to be available

but if there was some way to do this it's okay, trust me this one constexpr thing here is in a different compilation unit you can find it later that might be handy it's okay, trust me, this one constexpr thing here is in a different compilation unit. You can find it later. That might be handy.

Yeah. Every now and then it has to find it before it's used. Yeah. Since you've mentioned Kira consulting a few times, do you want to tell us more about the work you do there? Is it mostly embedded work? No, actually, funny enough, it runs in cycles. It's kind of all over the place. So right now we're doing a lot more embedded work again,

where it's everything from very small or smallish devices with no operating system, so bare metal. Perhaps that's with another system that's within a Yocto-based thing, so a small Linux-based system or still, again, a small ARM chip. But we do work at that level as well as things that might run on a standard laptop as well as lots of hundreds and hundreds of cores distributed in the cloud type work. So it's a little bit all over the place. Everything from turnkey projects for medical devices and scientific instrumentation, drones,

signal processing, consumer electronics, consumer products. I know it sounds kind of like cliche or something here, but we really just solve problems for people that's what we enjoy a lot of people have companies for making lots of money I actually have a company because I want to work on interesting projects with people I enjoy working with which is not maybe a great business plan but it's mine

well it seems to have been successful enough you've been in business for a while now yes it's been successful enough so far that's good well michael is there anything else you want to talk about before we let you go boy you know i think the only thing i'd like to mention since I have you here is we just started up a meetup this week. We're in California. It's the El Dorado Hills, Folsom, Sacramento area. And so we're pretty excited about having a C++ meetup.

Oh. And we'd love people to join. I'm kind of surprised that there wasn't already one wherever you happen to be in California, because it's California stuff. Yeah, there was not. At least not an active one. Where can listeners go to find this meetup? Is it on meetup.com? It is. It's on meetup.com slash edh dash cpp. And have you told Jens about it to make sure it's in the official meetup C++ list?

I tweeted it and noticed that Jens hit the like button, so I'm hoping... That means it's probably automatically in his list of things that are in the calendar now, then yes. Wonderful. Okay. Well, it's been great having you on the show today, Michael. Thank you for having me. It's been really wonderful being here. Yeah, 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.