CppCast - C++ on a Watch

Episode Date: February 13, 2020

Brad started programming in BASIC when he was 9, primarily on the Apple IIe, transitioning to QBASIC in high school. He graduated from Kansas State University in 2005 with a BS in Computer Science and a minor in Embedded Systems. While at K-State he enjoyed working on the solar car racing team, which built and raced a vehicle across the US and Canada. After graduating in 2005, Brad started work at Garmin, where he has worked on a variety of projects including Palm PDAs, Brew phone platforms, Android, iOS, and Automotive devices. He currently leads a team focused on bike computers and fitness watches. In his free time Brad enjoys working on home improvement projects, spending time with his wife and their 5 kids, and hobby programming. News Developer Ecosystem Survey Five Awesome C++ Papers for the Prague ISO Meeting Core C++ Announcement Links Garmin Connect IQ SDK Sponsors Write the hashtag #cppcast when requesting the license here One Day from PVS-Studio User Support

Episode 234 of CppCast with guest Brad Larson recorded February 12, 2020. 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 some of the papers being presented at Prague. Then we talk to Brad Larson from Garmin. Brad talks to us about his work running C++ on watches C++ developers. I'm your host, Rob Irving, joined by my co-host, Jason Turner. Jason, how are you doing today? I'm doing all right, Rob. How are you doing?

I'm doing just fine. Don't have too much news to discuss. You got any updates or announcements? No, nothing new. I mean, we mentioned the class that I'm going to be doing in Stuttgart. You got much interest in that yet? Apparently, a few students have already signed up for it, yeah. Awesome.

Sorry, not late August. That's late September. I have a different thing in late august nothing it's not ready to be announced yet no not yet okay well at the top there was sort of like a piece of feedback uh this week we got this tweet um from victor zverevich who uh is the one who put out the uh c++ freestyle rap video which we discussed last week and he just sent out this tweet when some people were talking about it um saying i very much hope that john lakos expressed his response in the form of a freestyle rap um john definitely enjoyed the video but unfortunately uh did not respond with his own freestyle rap although i wouldn't be

surprised if he's capable of one yeah i mean you know who knows yeah he you know seems like a very capable guy who knows what what else he can do i would not uh personally you know do my own freestyle rap i don't think i definitely don't think i could do that yeah no well we'd love to hear your thoughts about the show you can always reach out to us on facebook twitter 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 Brad Larson. Brad started programming in BASIC when he was nine, primarily on the Apple IIe, transitioning to QBASIC in high school. He graduated from Kansas State University in 2005 with a BS in computer science and a minor in embedded systems. While at K-State, he enjoyed working on the solar car racing team, which built and raced a vehicle

across the U.S. and Canada. After graduating in 2005, Brad started working at Garmin, where he worked on a variety of products, including Palm PDAs, brew phone platforms, Android, iOS, and automotive devices. He currently leads a team focused on bike computers and fitness watches. In his free time, Brad enjoys working on home improvement projects, spending time with his wife and their five kids, and hobby programming. Brad, welcome to the show. Hi, thanks so much. I'm really excited to be here. Brad, I feel like something in your timeline doesn't quite add up. Because if you graduated in 2005, that makes you about five years younger than I am, so I'm surprised that you started programming on an Apple IIe.

Well, yeah, I was trying to think. I think it was an Apple IIe. We had a few in grade school. And yeah, they eventually picked up. I figured out how to get into BASIC on them. And yeah, I thought it was a IIe, but I don't know. That was so long ago, I could be misremembering. Oh, no, very well. May have been. Those things stayed in schools forever. Yeah, yeah, very well may have been. Those things stayed in schools forever. Yeah, yeah, yeah. But 2GS in sixth grade was the fanciest Apple II series that I ever saw in a school. Yeah, I think that was sixth grade for me. So, I mean, it was presumably already a relatively old system anyhow.

It probably was, yeah. And I think I found a few books at the public library that talked about BASIC on them and just kind of went from there. Just for the record, I wasn't trying to say that you had made up a story here. I was just trying to get a deeper story. I don't think there's

too much extra to it. Just some BASIC programming on apples. Well, Brad, we've got a couple news articles to discuss. Feel free to comment on any of these, and we'll start talking more about what you're doing at Garmin, okay? Great. Okay, so this first one,

we have a developer ecosystem survey from JetBrains. We've talked about these before and talked about the results, which are always interesting, so I definitely would encourage anyone listening to go and click on the link and go through the survey um one thing which i don't recall seeing before is that they are uh doing some raffle prizes with the survey so it's worth pointing out you can win a macbook pro 300 amazon gift card or a jetbrain surprise gift pack not sure what that is but it might consist of jetbra an item. It might consist of JetBrains products. It might. It might.

But, I mean, those are three great prizes. Oh, yeah, one of those is worth considerably more than the other two, I'm guessing. Yeah, MacBook Pro is... It'll start at like $35,000 or something, right? I'm sorry, I just don't know Apple prices very well. I don't know either, but I believe that. What did you say, Brad? $3, but I believe that. $3,500. What did you say, Brad? $3,500. Oh, $3,500.

That's off by order of magnitude, my mistake. So yeah, it only takes about 20 minutes to do the survey, and we'll put the link in the show notes so you can definitely go take a look. Next thing we have is from Bartek's coding blog, and this is five awesome C++ papers from the Prague ISO

meeting and C++20 status and the Prague meeting is going on right now. I don't think we will hear any news from it until the meeting is over. Right. But this highlights a couple papers that are being presented in the mailing.

There's one we kind of talked about recently, which is don't con sex for all the things, which, uh, is a paper, uh, that, you know, references circle a lot, which we talked a lot about, I think three episodes ago. Uh, yeah, that sounds right. Yeah. Were there any other, any other, uh, papers from these five you wanted to highlight Jason? Uh, for me, I mean, well, I could say something about just about every one of them because they're things that I wasn't aware of. The heterogeneous erasure overloads for associative containers. I mean, just the is transparent and heterogeneous key lookup stuff

for associative containers, which basically allows you to say if you've got a container of strings, you can pass in a const character pointer without having to first create a string of that and it can have significant performance impact uh it's interesting to me that they want to add the same set of overloads to erase um and then i find this guaranteed copy elision for named returned objects interesting i'm going to have to actually read the paper on that because there has to be at least five caveats to say exactly what situations where this would occur. Right. I thought that was interesting too, because we've had a lot of discussions about, should we rely on copulation in some of these cases or not? And should we have our coding standard permit or encourage just returning your object and rely on copulation or what the best option is.

And in VRO was kind of the biggest wrinkle in all that. Yeah. I mean, I will just say for the, for the sake of the record here on the show, if you limit the scope of the object that you are returning as much as possible, then you're almost guaranteed return value optimization. If you have a bunch of objects in scope and you're trying to decide which one to return, then you're not going to get it. And just to mention the other two, one of them is debugging C++ coroutines. And I haven't read the actual paper, but it sounds like someone went through and implemented, I think, a WebSocket server using code routines and just talked about the difficulties with debugging their code and is putting some recommendations for compiler vendors

to make debugging easier. That sounds important. Yeah, it does. Definitely does. And then the last one was mitigating Spectre attacks in C++. Yes. Yeah, which is definitely important. And one solution that's mentioned here is that we could maybe add C++ attributes. We're seeing lots of new attributes being added to the language,

and that attribute could be translated into something like a fence because the different compilers, I think, implement those differently. Yeah? Yeah. I don't know how I feel about an attribute that is speculative load hardening true because it just seems very wordy. But I guess it probably makes sense

for at least some areas. Yeah. Anything else you wanted to mention, Brad? I mean, I do feel the pain of, I haven't worked with coroutines, but I feel this author's pain that sometimes these new features are really tricky to debug.

We might get into that later, but we've ran into problems with lambdas that at first blush might look correct, but then you realize you're capturing something by reference that goes out of scope. It's been painful for us at times to debug some features like that and just waiting for debug tools to kind of catch up. So yeah, I feel this pain. Yeah.

Okay. And then the last thing we have is an announcement from the CoreCPP conference in Israel. And this is that they're thrilled to announce that their first keynote speaker for CoreC++ 2020 will be Bjarne Stroustrup. So yeah, it's very exciting. Pretty big news for a relatively small conference. Yeah, definitely. so yeah it's very exciting pretty big news for a relatively small conference yeah definitely and again this is uh early bird tickets are open february 15th and do we know what the date is offhand uh for the 25th yeah conference is may 25th 27th yep yes it's exactly over my anniversary

i will not be going to core c++ this year Right Okay, so Brad We talked a little bit about The type of work you do at Garmin What types of devices are you working on today? Yeah, so I'm on the fitness team And on fitness we have two main Categories of devices One is watches

Smart watches Or fitness watches, triathlete watches, things like that. The other is bike computers. For Garmin, that's our Edge line, the product line. For those who are listening, Brad actually just showed us these on the camera if you happen to go

to YouTube to watch it. That's not helpful for the 99% of your viewers or audience that listens to the podcast. But, yeah, I can hold them up real quick. But, yeah, so those are the two main product categories. My team focuses mostly on the watches, but we help out with my computers as well. And, yeah, lots of features that we try to fit into as small of a space as possible,

from, you know, lots of GPS tracking, recording your speed and distance and position and stuff like that when you're out for a jog or a walk or a bike ride, things like that. We do smart notifications over Bluetooth, BLE. We talk to a lot of wireless sensors over a different protocol called ANT, which is very similar to BLE. So we can talk to a wireless heart rate strap if optical heart rate on your wrist isn't accurate enough. We talk to wireless power meters on your bike or foot pods on your, you can attach to your shoe to kind of get an accurate, if you're running on a treadmill or something like that, we can still get pretty accurate distances and step counts and things. So yeah, lots of fun, interesting

challenges. So all of those things talk to the devices you just described, either the watch or the trip computer? Yep, yep. The watch or the bike computer, it's got a file system on there. So it records all that data, stores it to the file system. When you're done with your activity, Garmin has a website called Garmin Connect where you can upload those files to. You can attach it through USB. You can sync it over Bluetooth to your phone. Some devices have built-in Wi-Fi, so they can sync it over Wi-Fi standalone up to our website. And on the website, then, you can see a map of where you went.

You can see graphs of your elevation over time, your heart rate over time, all sorts of stuff like that. You can, you know, be social and share it with your friends or if you have a running coach or things like that, you can, you know, share your activities and get feedback and stuff like that. So just out of curiosity, didn't these devices have cellular antennas as well, since you mentioned Wi-Fi and Bluetooth? Yeah, good question. We do have one device out now, the Vivoactive 3, which is, it's not focused as much on fitness. It's more of a smartwatch category, but it does certainly support a lot of the fitness features we do. And it has a variant of that that does do LTE, yes. That's fascinating to me. I mean, that was the future, and now it's normal. Yeah, yeah. The future is now. Yeah, yeah. I still don't have a flying car, though.

I just don't think Armin's going to make those. Yeah, it's not our market. What does software look like on the watch? I mean, are you basing this on a Linux system or Android, or is it a custom OS, or is it a pure embedded system? Yeah, yeah, good question. We are full custom. Especially on the watch

side, they are such... It's always a trade-off. We really want a small watch, small form factor. We want great battery life and then we see what performance we can get out of the platform that we're given.

And so we do a full custom OS, and OS is almost stretching it because it doesn't support multiple processes. It does threading and memory management and stuff like that, but it doesn't support multiprocess type stuff. But that's what's necessary. And so, yeah, most of our code base is still in C. So a lot of our OS libraries and things like that, they're all written in C or GPS code and file system code, stuff like that.

But more recently, the past few years, we've been experimenting and pushing really hard to change out our UI framework that sits on top of everything to be C++. And that's gone really well. And so an interesting thing that kind of helped us kick it off is actually Jason did a talk on running C++ 17 on the Commodore 64, which hopefully most of your listeners have heard that talk by now. But if not, you should definitely go check that out.

But that was a really fun talk because that was right as I was working on getting C++ stuff running on a watch. And as he was going, Jason kept having, you know, kind of, you know, side discussions on, you know, now, you know, memory on desktop, you know, you got plenty of memory, but on the Commodore 64, you only have, what was it, 256k of RAM or something like that. 64k. 64k. So I was like, well, gosh, our platform only has 256K of memory. And then later on you're talking about colors and you're like, no, on the Commodore 64 there's only 16 colors. Well, on our watch there's only 16 colors. And so it was neat. There's so many parallels and you still had very good luck running lots of

advanced C++17 features on a very low-end platform. And so, yeah, it was fun to watch that as we were trying to solve some of the same problems. So you did just tell us like 16 colors, 256k of RAM. Are there other details

that you are allowed to tell us anyhow about what the hardware is on these things? Sure, yeah. And those numbers are somewhat dated. Those were the uh watch i was working on you know when you were giving that talk so um so so since then we do have i i don't know if i can say the number we have more memory available now we've started to put on board maps on the on some of the higher end watches and also also we do um music you know we'll stream music on the higher-end watches. Also, we do music. We'll stream music on the higher-end watches. Those two features require

a fair amount more RAM. We're into the single-digit megabytes now of RAM. It's a whole new world. On the ROM size, we're in also the single-digit megabytes of

ROM. Other than that, I don't know if there's any other statistics you'd be curious about. Can you tell us what architecture it is? Yeah. So we, it's all ARM stuff. The watches are a Cortex-M series processor. And those run just thumb instructions. So it's a pretty small subset of ARM.

Oh, it's a thumb only processor. Yeah. Oh, it's a thumb-only processor. Yeah. Interesting. I believe, I don't know, I might be wrong on some of the details there, but I believe Cortex-M is thumb-only. That sounds believable, but I haven't spent a lot of time with that.

Yeah, I work mostly on the UI side of things, and so I would have to reference one of the device driver engineers that we work with. But, but yeah, on the bike computer side that there, you know, there's not as many trade-offs that can fit much beefier processors with much more memory and stuff like that on those. So it's, it's more of the watch side that we're very limited and we have to get pretty creative on how to, how to cram features in with, with a very small amount of memory. And so you're managing a Bluetooth receiver, you said, wifi in some devices, GPS, heart rate monitor.

Yep. What else? Step counter. Yeah. Lots of, yeah, we do onboard step counting. We do on wrist, wrist heart rate. We can talk to lots of different wireless sensors in the ant ecosystem. So there's, you there's power meters.

There's a neat, you can get some glasses that have a display built into them. So if you didn't want to look down at your watch, you can look at what's being displayed on those glasses. Yeah, a step counter that you can put in your shoe. We've got temperature sensors and all sorts of stuff, yeah. I can have glasses that talk to my watch and show me what's on the watch currently so I don't even have to look at the watch. That's interesting. I might have to add something to my Christmas list here.

We'll see. One question I have is does your team make all the apps that go on the watch or is there a SDK for third-party developers? Yeah, so starting a few, I don't know, three or four years ago, Garmin did announce an SDK. So it's called Connect IQ. We do allow third-party developers to write different types of content for our watches and for our edge bike computers.

Four main types of apps you can do. Watch faces, widgets, which just kind of give you information at a glance, like, you know, sports scores or stock prices or things like that. Full apps. So, you know, at that point you take full control of the device and you can, you know, react to any button press and do whatever you want to as an app. And then the last one is data fields, which are popular when you're going out for a jog or on a bike ride.

Most of your interaction with the watch is looking at a screen of data fields. And so you might have two to four data fields on a page. And one of the ones that third-party developers have really flourished with is creating their own custom data fields. And so it can be as simple as a Hello World-type example as you can have a data field that shows you how many cookies you've burned off or things like that as you're on your jog to very complicated data fields that are talking to proprietary wireless sensors or things of that nature. So, yeah, it's been a very successful third-party SDK for Garmin that users have really embraced and leveraged. Okay.

And I think you said that you work on the UI side, and it's a C++ UI widget tool. Is that what SDK developers use, too? Are they writing everything in C++? Yeah. It's actually not. So we considered a lot of options for how can we get third-party content, third-party software onto our watches. C or C++ would be nice.

The biggest problem we have with those is, with us, I mentioned earlier, our OS situation, it's a very bare-bones, bare-metal OS. It would be very difficult for us to sandbox those third-party apps. And so if someone did something as innocent as a divide by zero, even preventing that from shutting down the watch, that would be solvable, but we certainly don't have the concept of a user space versus kernel space or things like that.

And so for those reasons, C and C++ just did not seem very feasible. And so we looked at some other options. Python or scripting languages just use way too much memory for a device that's got 256K of RAM. That's not a good option at all. Right. And the other popular option that, you know, might have worked was Java. But we kind of scuttled that because of the legal situation that Java's in.

If you look at, you know, Google and Android and, you know, and Oracle and stuff, it just didn't seem like something we wanted to mess with. It was a little too risky. So instead we went with just writing our own language, our own virtual machine, our own compiler, the whole stack. And it was a lot to bite off at first. I wasn't involved with any of that effort, so I can't claim any credit. But now that, yeah, a friend of mine at work started writing his own compiler and virtual machine. And a few months later, we could run custom content on our watches and not use much memory at all. And so, yeah, we've got a language called Monkey C,

and it's not that different from like a Java or Python or C++ syntax, and it's not too hard to pick up and start writing content. It's a funny pun built in there, I guess. Yeah, that team is very pun-friendly, I guess. They've got Monkey C as the language, and then at one point the compiler might have been called Monkey Do. I would imagine. Yeah, there's lots of fun pun opportunities

when you have your language like that. So you mentioned that you've been involved directly in the move from C to C++ for the UI. What has that experience been like? Overall, we've been very happy. There's two sides to that question. I guess the technical side and then the person side on reception. But focusing more on the technical side, it's gone

really well. Modern C++ has made this probably feasible in general. I don't know that we could have pulled this off with C++03 or not. It would have been a much more difficult challenge. Constexpr especially has been really helpful. And so the way we leverage that there is stealing some ideas from iOS and Android development. We can specify page layouts in XML with our system. And then we have a compile time tool that goes through and takes those XML layouts and converts them into C++ code that just get compiled in there.

And so that works really well. The pages get converted into constexpr structs, which is important for us because we don't have much memory, so we need everything to live in ROM as possible. And so the fact that we can compile those data into constexpr structs that are guaranteed to live in ROM and not go into RAM at all, that's been really helpful. And then also the fact that now we can call functions and stuff in our XML layouts

you can say hey the X position of this equals do some math because on a round display sometimes you need to do some math, some trigonometry and stuff to find the best X position or X Y position so we can put stuff in there and as long as it's constexpr functions

then it gets handled at compile time and it's just a binary number that ends up in that struct and then if it's not a constexpr function then we get a compile time error that says you know oh this is not going to work as a constexpr struct you need to go you know find a way to do this at compile time um so that's been good um, smart pointers have been really helpful. We use unique pointer everywhere. We've seen our stability go up somewhat, and I think smart pointers have actually been a fair amount of that. I'm actually kind of surprised you're allowed to do dynamic allocations.

Oh, yeah, yeah. We're kind of careful about it, but yeah. We certainly have malloc and new and uh calling up the stack yeah okay that that leads me to another interesting question because uh generally the answer is that it's basically impossible to handle amount an out of memory error but do you handle out of memory errors how does that work no no we we reset the we reset the watch okay It frees up a lot of memory. No, we don't handle a lot of memory. I mean, we do have a few cases where we can say, you know, hey, Malik's on memory,

and then, you know, let me know if there's not enough available. And, you know, if we're wanting to do buffers for, you know for specific situations, we can gracefully fail. But in general, no. We have not taken the time to add null checks to all of our malloc returns and stuff like that. So sorry to interrupt you. You were saying unique pointers you think have helped the stability of the watch a lot.

Yeah, unique pointers have helped the stability quite a bit. Other than that, yeah, basic UI. Getting a basic UI up and running with object oriented languages is a lot easier than you might think. So we've got our page stack is just a vector of base page objects and

each page object, it just has a vector of, we call them widgets or fields or views or whatever your UI framework wants to call them. Those just go into a widget. You've just got a base widget class, and it's got an X, a Y, a width, and a height, and some basic methods on it,

and then you can just kind of extend it from there. And I can almost hear Sean Perrin yelling, no, inheritance is the base class of evil. And he's got good points about that, but it worked really well for our needs and it got us up and running pretty quickly and when you start to do the more finer details of how do you handle touch inputs

and page transition animations and stuff like that there are more difficult wrinkles you have to work out but overall you can get up and running pretty quickly with an object oriented language like C++ for UI frameworks. And you said as much as possible is calculated at compile time. Yeah, that's very important to us.

You can still runtime change the position of a widget or things like that or resize widgets on the page and stuff. So you can still call setters and stuff but by default it all just lives in ROM and a widget on a page and stuff. So you can still call setters and stuff, but by default, it all just lives in ROM and a widget on a page takes up, you know, four bytes or something like that of actual RAM space. Basically a pointer. Yeah, just a pointer to that ROM. And then if you need to

call setters, then we can move it in RAM and start changing values. But for most of our UI layouts anyways, you anyways, things are pretty static. We show data, but we don't move it around and resize that data and stuff too much. And so that's worked out really well for us to avoid taking any RAM usage that we can avoid. Have you been able to quantify that? And have you seen smaller binary sizes or anything moving to C++ with these techniques? Yeah, it turns out measuring that stuff is really tricky, especially the RAM usage stuff. And it's also hard to be apples to apples, because the UI framework I'm comparing it to is our C UI framework, which is a good UI framework. And it's probably the same UI framework you or I would have written

if we wrote a CUI framework from scratch in the early 90s or so. But, you know, I think understandings of how to write good UI frameworks have changed a lot since then or have improved. So comparing it to our previous UI framework, we are seeing less allocations and small, you know, less need for memory allocations in general. But, you know, potentially if we started from scratch with a CUI framework, maybe you could do as good or close to as good. It's hard to know. Right. On the ROM side, similarly, yeah, we're in the same ballpark. Sometimes we're a little bit smaller on ROM for,

you know, particular page implementation. Sometimes we're a little bit smaller on ROM for particular page implementation. Sometimes we're a little bit bigger, but it's all been the same ballpark. So we've been very happy. The main reason we wanted to switch to C++ was really just to get rid of boilerplate. With our CUI framework, if you wanted to make a blank page

as a starting point, a blank page alone was, I think, about 350 lines of code or so, something like that. And so now you can just, you know, you can extend a base page object. And that's all you need for a blank page. And it's like, you know, five lines of code or something. So we've definitely succeeded in improving boilerplate. And after that, you know, if our RAM and ROM was at least ballpark the same, then we were satisfied. And we definitely are ballpark the same.

And in some cases, we're significantly better. So it sounds like you are then using some virtual function call in your interfaces. Oh, yeah. Yeah, we use virtual tables and stuff quite a bit. Okay. Yeah, and that hasn't been a problem. It hasn't slowed us down on anything. The one modern C++ feature that's been a little bit tricky has been std function.

So we use lambda as a fair amount, which are great. And we've got an API that will say, you know, hey, run this lambda in three seconds or something like that. Or run this lambda every one second. And, you know, that might go, you know, check, you know, your distance and And then that might go check your distance and update the data field that shows your distance or something like that, which has been really helpful. But the fact that we then have to store those Lambdas as std functions, that has been pretty heavy on the ROM side. So every time we have a std function that we store,

it takes up, I don't know, close to a K of ROM or something like that, which, you know, if you're doing desktop work, you're probably laughing and saying, you know, a K of ROM, who cares? But no, when we're on a small embedded device, that can add up pretty quick. And so we still use std functions where they make sense or store lambdas as std functions. Other times we'll say you know uh you know our use cases here are sufficient that we can just store a function pointer instead of a stood

function we don't need to worry about capturing or or things like that so you take advantage of the implicit conversion from lambda to stood to a function pointer yeah yeah we might do that at times yeah or other times we just you know have to have a static function somewhere that we pass in as the callback. So now I'm curious because I have, you know, showing examples of std function in my classes and talks and something I do often. And I've noticed that the compilers keep getting better and better. So like two years ago, I could be like, avoid function C,

and I put a slide up and it's got like, you know, 10,000 instructions generated. And today, it's not surprising if the compilers can see completely through that and completely eliminate the virtual functions and the small object optimization and everything and it all just goes away. So what compilers are you able to use? and are you on an upward path, I guess, to being able to upgrade your compiler? Yeah, we definitely have been. I can't take credit, but the low-level engineers that maintain our compiler and stuff have done a very good job of keeping us up to date. So we use GCC for our hardware builds, and then we also have a Windows simulator and that's Visual Studio and so we're up to Visual Studio 2017 right now and we'll probably upgrade to 2019 or sometime in the next year

and then GCC, I can't I should know which version we're on but we upgraded to close to tips of GCC a year or two ago and that's a good point it probably is. Seven sounds right.

I'm sorry. I wish I knew better. That's all right. But yeah. So that is a good point, though, that my statistics for how expensive std function is, those are a few years old. That's probably more on GCC 6. And so, yeah, that could be improved by now.

I should actually go back and double check that maybe but if you have code that works that's using the function pointer conversions or whatever it's still an extra layer of indirection that you're not using if you don't have standard function in there

I'm sorry if you already said this but what version of C++ are you currently able to use? Yeah so right now we're targeting C++ 14. And we'd like to, or personally, I'd like to start using some features in 17. And I tried to turn on 17 a couple weeks ago, and evidently some of our mid-level code that I never touch was still using a std auto pointer, which is now removed in 17. So I'm like, oh, man, I've got to go back and fix

that, which wouldn't normally be that difficult, but I want to change it to be a unique pointer, but we've got some other products, not in the fitness space, but in other departments at Garmin. They're not compiling with C++11 yet, and so it's kind of finding the

right balance. I think we finally negotiated that they would change it to a Boost smart pointer for now and we'll work around it that way. And then at least I can upgrade my stuff to be C++17 and start using some of the new features we're excited about. Yeah, don't tell anyone else this, but every compiler does have a pound to find that you can give to re-enable auto-pointer

in C++17 mode. That's a good point. I hadn't really thought about that. But I don't know. Just personally, I feel a lot better just getting rid of that auto pointer. I agree, yes. But, you know, I would just say from my experience of interacting with people doing embedded devices, I'm impressed that you are staying on top of compilers and moving forward with things.

So you don't tend to see that very often. Yeah. Yeah. It's, it's sometimes it's an uphill struggle. Um, just that, uh,

the biggest problem is that, you know, we've still got the teams that are stuck pre C++ 11. They're using compilers that, um, haven't been updated, you know, ever.

Um, but, but they, uh, they've got assembly to, you know, do device driver stuff that only works with that compiler. And so that was something the fitness team went through a while ago.

A lot of our device driver stuff that was in assembly had to be rewritten to work with GCC's assembly syntax. Right. And so that's the biggest pain point we have right now. Some device drivers that are in assembly that have to be rewritten from scratch, not necessarily from scratch, but rewritten to support the different syntax from a different compiler. Now, I might be going a little off topic here, but you said that your UI framework, the C version of it, was state-of-the-art in the 90s uh effectively is this the ui framework that you're working on does it have its history in the old standalone garmin gps that

i have in my parts bin right there that's from like year 2000 yeah yeah yeah those probably are very similar ui frameworks and it would be the the same you know operating system c code base the same you know gps GPS interfaces and stuff like that. Garmin does a very good job at sharing code across a very diverse set of products. It's been very helpful, generally helpful. Sometimes there's always pain points with that, but it's worked out very well for us. Wow, that's cool. That actually reminds me, Rob, I think in one of the very early episodes of CPPcast,

you mentioned that you used to work for Navigon, one of our competitors. Not Navigon. I used to work for a company called ALK, which makes Copilot, which is another navigation software. Okay. So long ago, I guess I got confused, but yeah, that's cool. Go ahead, Jason. Well, I was going to ask if there's any... You said std function has been a pain point for you, but are there any core language features

that you can't use for whatever reason? Nothing I've ran across. Nothing I'm aware of right off. I mentioned at the start, we have at times really struggled with some bugs inside of Lambdas that have just been really tough to debug. So yeah, and that same interface I mentioned, and we use it a lot to say, hey, go run this every second or something like that, run this Lambda.

And if that Lambda happens to capture something by reference that then goes out of scope, it's really tricky to debug those situations. Visual Studio is actually pretty decent at helping us debug them. So if we can reproduce the bug in our simulator, then that's okay. But if it's on hardware with a JTAG debugger and stuff, it's been kind of tricky to figure out, you know, how did we get off in the weeds and what's going on and stuff. And that's just kind of been a learning experience.

We've gotten a lot better at looking for those sorts of things in code review and stuff. That's just kind of been a learning experience. We've gotten a lot better at looking for those sorts of things in code review and stuff, and so it hasn't been terrible. But for a period of time, that was causing us quite a bit of headaches. A product that was needing to go out, and we ended up finding at least two or three of those types of situations that were causing some crashes that were really tricky

to track down. An argument pro moving to Visual Studio 2019 is what we covered this on the channel a few weeks ago uh visual studio 2019 now has address sanitizer support that could help make tracking down those things a lot easier as well yeah that's a good point yeah and uh yeah i've also been meaning to look and if there's any other static code analysis tools that i would catch that sort of thing um i wasn't aware of visual studio 2019 doing it, but that's good to hear. Yeah.

ClangTidy will catch some of them today. It's still not great at it. Yeah, and we do use ClangTidy some, and ClangTidy's been great. I was kind of frustrated that ClangTidy now, I just upgraded ClangTidy, or our team did, and it recommends we convert all of our functions to use the trailing return type.

It just disabled that, yeah. Yeah, we did just disable that. We're like, oh, that can't be good advice, can it? I mean, does anyone really think that you should go through and change all your functions to a trailing return type? I don't know. I'm not serious. Yeah, and I'm also, I will like every other function signature I write. Sometimes I'll use trailing, and sometimes I won't.

That's the worst of both worlds, so you should probably pick a style. And that kind of goes to the other aspect of how is switching over to C++ gone, which is the human aspect. It's gone pretty well, but

we've definitely struggled at times with the language just getting more and more complicated. And trailing return types is a small example, but it's hard to keep up, especially for C engineers that have just been doing C programming for 10, 15, 20 years. Modern C++ is great, but I'm hopeful that Herb will have luck in his goal

to simplify the language. I think it's becoming more and more needed. Right. I wanted to interrupt the discussion for just a moment to talk about the sponsor of this episode of CppCast, the PVS Studio team. The team promotes the practice of writing high-quality code, as well as the methodology of static code analysis. In their blog, you'll find many articles on programming, code security, checks of open source projects, and much more. For example, they've recently posted an article which demonstrates not in theory, but in practice, that many pull requests on GitHub related to bug fixing could have been avoided if code authors regularly use static code

analysis. Speaking of which, another recent article shows how to set up regular runs of the PVS Studio Static Code Analyzer on Travisvis ci links to these publications are in the show notes for this episode try pvs studio the tool will help you find bugs and potential vulnerabilities in the code of programs written in c c++ c sharp and java is there anything in particular you're looking forward to i mean i know you need to resolve the auto-planter situation and get up to SuperPulse 17, but is there anything you're looking forward to with 20? 20, that's a good question.

I haven't followed code routines close enough to see if that's something I could really leverage too much or not, or same with modules. So I need to go back and watch a couple more presentations on those to see where things are at. On 17, I know it's a small thing, but I'm excited to switch to std optional because right now we've got some code that uses boost optional.

And, you know, just any time I can switch, nothing against boost, but any time I can switch to stuff that's built into the standard, then that always gives me some warm fuzzies. I don't know. Also, in 17, it's silly, but I'm excited for, what do they even call it, the nested namespaces or listing out namespaces. Yeah.

In some cases, nested namespaces can be very helpful. Yeah, so I'm excited for that. Our coding guidelines right now say that inside of a namespace, they want us to tab in, and so that really discourages doing too much nesting of namespaces. So once we can put all those on one line, that'll clean that up quite a bit

and make people more willing to nest namespaces as deep as they want to. The only problem then is the whitespace diffs when you're ready to push it all back up to source control. Yeah, yeah. But hopefully it's just a one-commit, one painful commit type thing, and we'll be all good. I don't know.

Are you able to use exceptions? Yeah, that's a good question. We do compile with exception support, but we... Fascinating. And more recently, I have found some places where RTTI has been really helpful. But we don't actually throw or catch any exceptions at this point.

So RTTI and exceptions, we saw about a 10% increase in our ROM size on the subsection of our code C++. And for some of the potential benefits, we figured 10% was an acceptable tradeoff. And again, I'm really excited for Herb's work on making exceptions significantly lightweight. Static exceptions. So that's just really exciting.

So I hope to, I don't know, I was joking with some coworkers that that's going to be so far off, but I'm going to go buy a digital countdown clock for our hallway. Exceptions will be nine years until exceptions are really cool to use. I'm excited for the future there. It's a very exciting time to be working in C++.

Especially, Herb's recent keynote was hitting on all the points that we struggle with on language complexity and exceptions and RTTI being expensive and stuff. So yeah, we do compile with exceptions, but we haven't really found a place that really needs them.

In the future, I'm hopeful that more of our mid-level code will also consider switching to C++ and rewriting their current C stuff as C++. And people have expressed some interest there as well. And there, I think it makes more sense to use exceptions. That's where you might have more exceptional situations of, you know, the Bluetooth connection was dropped or something like that.

When we're doing most UI stuff, there's not a lot of things that have, in my mind, been exceptional where we would need to throw an exception. I think that comes in more in the mid-level code where if we have file system errors or things like that, then exceptions make more sense. I think it's most interesting, maybe from the point of our listeners, I would think that you don't just systematically disable them because you have calculated that the small price that you pay

is worth it for what features you are getting currently. Yeah, and RTTI especially. Recently we added some debugging tools that in our simulator you can open up a window and it'll give you a dump of the full page stack, which is cool, but then also we can tell you the class name of every page on the page stack, which is super helpful on, you know, I don't have to go and add, you know, text names to every page to get that debug output.

I can just use the RGTI to get the type ID name field. And, yeah, it's, you know, it's not as amazing as some of the, you know, features that we're looking at for C++ 20 and 23 and stuff. But some basic information about, you know, class names and stuff like that. That's cool. Yeah. I want to go back to something that was mentioned in your bio for a minute. You mentioned this solar car driving across the U.S. and Canada.

Can you tell us a little bit more about that? Oh, yeah. Yeah. Yeah. this solar car driving across the US and Canada. Can you tell us a little bit more about that? It sounds interesting. Yeah, so that was a very fun project back in college. Back then there was the American Solar Car Challenge, and it since has kind of died away. The Department of Energy was the big sponsor of it, and I think

they eventually moved on. But yeah, several different colleges, I think it was about 20, 25 colleges that had built a solar-powered car and race it. Yeah, I was on the more – we had mechanical and electrical teams, so I was more on the electrical team. But, yeah, we built a lithium-ion battery pack, a solar array, and then, yeah, we used low-end PIC microcontrollers to talk to everything. So we'd have to talk to a motor controller over serial,

and we had a driver display, like an LCD. I don't know, it was like a four-line by 20-character display or something like that. Oh, yeah, yeah. Talk to that over, I think that was UART or SPI or something. And then, yeah, have to do a lot of ADC work to monitor the battery pack and make sure we weren't overcharging or undercharging our battery cells and stuff like that yeah it was very fun also i guess we talked to a over serial port to a a radio that could send telemetry data to a to a team laptop that was following in a chase

vehicle um and so yeah yeah you just you'd built the car uh it was in our case it's mostly like kevlar and carbon fiber vehicle and stuff. And then we'd race it on mostly highways. We tried to stay off the interstates too much because the cars, they certainly can go 70, 80 miles an hour. But most of the time, you're cruising more like 40, 50, maybe 60 miles an hour. And also the smaller highways are good because they occasionally do media stops, two or three media stops a day in the small towns along the race route, and people would come out and see the cars and stuff like that. So part of the event was just to kind of gain recognition of alternative energy, solar power, stuff like that.

So it was a very fun engineering challenge, yeah. How did you place? So we did two races. One was, and they would do it every other year so it take you know a good two years to build a vehicle um so with the one we did in 2003 it was from chicago to la uh mostly long route 66 so that was really fun um oh wow yeah i cannot remember um i don't know i think we're in you know I can't remember if we were in the top. I think we were somewhere in the top 10.

I don't know. And then the second race, it was from, where did we start? Somewhere down in Texas. And then it went up to Canada and then across to Calgary. Wow. And, yeah, that one was really fun. Those are long trips. It was very, yeah.

And also being, you know, in a solar car, you only really drive when it's sunny out. So, yeah, you drive from like 8 a.m. to 5 p.m. or so, and then you'd kind of pull off and charge or try to angle the solar array up at the sun as it sets and stuff and try to charge your batteries as much as you can. So, yeah, so the overall trip would be about 10 days or so, something like that, for the full race. They'd have a couple of points where they'd you know let everyone catch back up so they'd say you know for this second leg we will stop it i think one of them might have been raleigh missouri and uh you know if you got there early enough you'd have a full day there and otherwise you might only be

there for you know a few hours or something to get caught up but but yeah yeah it was a very very fun experience i'm glad i had that opportunity how much could it charge itself while like okay what am i trying to say if you had a perfect sun was it enough solar power to drive the car or were you still draining the batteries during that time yeah no in perfect sun um you could charge a little bit while you're driving yeah depending on your charge. Yeah, depending on your speed and if you're going up a hill or something like that. But yeah, perfect sun. And also, a lot

of it depends on the quality of your solar array. Good quality space-grade solar cells are really expensive. And so, depending on how many sponsors you could find for your team and stuff like that, then yeah, you might have more or less success at charging while you're driving. But, yeah, and also it really depends on the time of the day.

So at noon where the sun is straight overhead, and depending on the direction of your travel, north, south, or east, west, or such, if the sun's straight overhead, then you're generating more power than 8 in the morning, 5 at night where the sun's off at a 20 degree angle or something like that. Then you're not generating nearly as much power. There's lots of factors to it.

Is there anything else you wanted to go over today, Brad, before we let you go? I don't think there's a whole lot else to chat about. Garmin, I'll give the usual plug that my team's not hiring right now, but Garmin is a company, is a big company we're always hiring. And we've got, you know, a lot of our work is done in the Kansas City area, but we have got branch offices globally through, you know, lots of places internationally.

So if these sorts of problems sound interesting to you, then certainly, you know, pull up Garmin's webpage and look around. I have a lot of fun working on these problems, especially seeing how much we can fit into a very small amount of memory. But if that doesn't sound fun to you, we also do automotive devices and marine devices and aviation devices. Garmin's a very diverse company, and those don't always have the same trying to fit things in problem. They have other problems of lots of fun stuff to work on.

I'd imagine an aviation or marine device, it's practically a PC compared to what you're working on. It absolutely is. Basically a PC. Aviation is interesting too. They were similar to fitness for a while that they are all,

I believe they're all C, but for different reasons. Fitness was all C historically because of all of our RAM and ROM limitations and concerns. But on the aviation side, they have to do

a lot of FAA certification type stuff. And I'm not familiar with that, but my understanding is that it's a lot easier to get certified in C where you can very easily tie a

line of code to assembly that gets generated. Whereas in C++, you might not realize that you're calling implicit constructors and stuff that are generating thousands of lines of assembly for you under the covers. And so I think it's just interesting. I think aviation is still pretty strictly a C shop as well. Interesting. Okay. Well, it's been great having you on the show today, Brad. Yeah, it's been great chatting with you guys.

Thanks so much. Thanks for coming on. 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 help

support the show through Patreon. If you'd like to support us on patreon you can do so at patreon.com cppcast and of course you can find all that info and the