CppCast - Embedded Development

Episode Date: October 27, 2016

Rob and Jason are joined by Dan Saks from Saks & Associates to discuss state of C++ in the embedded development industry. Dan Saks is the president of Saks & Associates, which offers training and consulting in C and C++ and their use in developing embedded systems. He has been a columnist for The C/C++ Users Journal, The C++ Report, Embedded Systems Design, embedded.com and several other publications. Dan served as the first secretary of the C++ Standards Committee and contributed to the CERT Secure Coding Standards for C and C++. News Jumping into C++ CppRestSDK 2.9.0 available on GitHub A note about the volatile keyword in C++ Woboq Code Browser: under the hood On the recent lambdas vs iterators paper Dan Saks Saks & Associates Links CppCon 2016: Dan Saks "extern c: Talking to C Programmers about C++" embedded.com Sponsor Backtrace

This episode of CppCast is sponsored by Backtrace, the turnkey debugging platform that helps you spend less time debugging and more time building. Get to the root cause quickly with detailed information at your fingertips. Start your free trial at backtrace.io slash cppcast. And by Meeting C++, the leading European C++ event for everyone in the programming community. Meeting C++ offers five tracks with seven sessions and two great keynotes. This year, the conference is on the 18th and 19th of November in Berlin. Episode 76 of CPP cast with SDK and the Volatile Keyword.

And we talked to Dan Sachs from Sachs & Associates. Dan talks to us about the state of C++ and the embedded development industry. Welcome to episode 76 of CppCast, the only podcast for C++ developers by C++ developers. I'm your host, Rob Irving, joined by my co-host, Jason Turner. Jason, how are you doing today? Doing all right, Rob. How about you? Doing pretty good. Getting ready for Halloween on Monday. How about you? Well, I'll be giving out candy, but we don't do a bunch of decorating or anything but the neighborhood we're in we expect at least 300 kids to come by

oh wow that does yes a lot of kids this is our first time doing halloween in the new neighborhood so i'm not really sure what to expect this year you have any neighbors you can ask or anything because yeah and and there's plenty of kids on the street and it's a fairly dense community so we probably could get a lot right yeah so yeah you know you said episode 76 and not to derail our intro too much here but i'm wondering what we're going to do for like our 100th episode spectacular i mean tv shows do that you're you're setting us up to do something big now um i don't know that's gonna be what like four months away four or five months is that right 24 24 whatever that is so that's that's six months i guess yeah six months away i don't know we have plenty of time to think about

it but we we should do something big yeah anyhow anyway uh at the top of every episode, I like to read a piece of feedback. This week, Matt wrote in with a suggestion. He writes in, a few shows ago, you wrote a piece of feedback from a listener who wanted more episodes about learning and or teaching C++. I believe you guys said you weren't sure how to do an episode along those lines. Perhaps you could get Alex Alleyne as a guest. He wrote a very popular book called Jumping Into C++. I believe it's based on his experience

being a teaching assistant for a C++ course at Harvard. So yeah, Matt, thank you for the suggestion. We'll definitely reach out and try to get in touch with Alex. I'm sure someone who wrote a book about getting started with C++ would be a great guest

for a show like that yeah and look at that Amazon link it's got a lot of really good reviews yeah and it's a fairly recent book I think it came out in 2013 yeah so we'll definitely have to reach out to Alex and try to get him on the show soon

anyway 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 cppcast.com. And don't forget to leave us reviews on iTunes. Joining us today is Dan Sachs. Dan is the president of Sachs & Associates, which offers training and consulting in C++ and C and their use in developing embedded systems. He has been a columnist for the C++ User's Journal, the C++ Report, Embedded Systems Design, Embedded.com, and several other publications.

Dan served as the first secretary of the C++ Standards Committee and contributed to the CERT Secure Coding Standards for C and C++. Dan, welcome to the show. Hi. Thank you. So I'm curious about this. You were the first secretary of the C++. Dan, welcome to the show. Hi, thank you. So I'm curious about this. You were the first secretary of the C++ Standards Committee, and the stories that we hear is, you know, back then the Standards Committee, you know, was moving very slowly, like it took forever to go from 1998 to 2011 standards. What was it like back then? Do you have any tales you can regale us with? Tales about the early standards committee.

Well, I'm being a little bit reticent because it wasn't always nice and a lot of the stories are sort of gossipy. I just as soon let that stuff go. The it took a little while for the dynamic of the group to gel, that people came from different backgrounds. Right. In particular, I think some of the people who arrived at the standards committee came from, a lot of them were from AT&T. At the time, they were involved in the development of the language itself. And the people who were from other organizations that were sort of like working on C compilers and wondering if they should be also interested in C++, they didn't always get along together. They looked at things differently.

And I think it took many years for some of the different viewpoints to stop being almost antagonistic. And that's what I recall early on is that, yeah, it was slow going. And part of it was the group dynamic had to form. Just out of curiosity, what years were you involved in the C++ committee, and are you still involved today? Well, the organizational meeting, which started the whole thing, was in December of 89. The first working meetings were in early 1990. I was on the committee then through 1997, I believe. This one stopped being active. So right up to the first standardization.

Yeah, I wasn't quite there for the ink to dry on me. So just out of curiosity, too, is there anyone who's still around who was on that original committee? Oh, yeah. Yep. Yeah. Well, yeah. OK. I would have to look at the roster to see. There were a number of people who were there within the first year who might not have been at the very first meeting. OK. But, yeah, there definitely are people from those early meetings that have been there the whole time. Be an interesting experience.

Oh, yeah. There are certainly elements of of those meetings that are very very interesting there's also a lot of minutiae which can sometimes you know they can test your patience sometimes right okay dan well we have a couple news articles to go through and then we'll start talking to you about uh embedded development in c++ okay yeah okay so this first one is from the visual c plus plus blog and they just released an update to the cpp rest sdk it's now version 2.9 and i guess it's been a while since they last updated this but it's nice to see and they fixed a bunch of issues specific to Android, Linux, and OSX. So it's nice to see that this REST library is not made just for Windows, but they're spending plenty of time supporting Android and Linux.

Yeah, I have to admit ignorance to this project. I don't think I even realized it existed. Yeah, it's not something I've tried, but it sounds like a good library. They're saying it has a nice asynchronous API, and it's used for both client and servers to use REST services. Yeah, I mean, it's one of those things that people complain about C++ not having. Right, right. Yeah, so if you're looking for a good REST API, this could be a good library for you.

So out of curiosity, Rob, did you look at the OSX fixes? No, I did not. What's going on in OSX? Both of them were the version of Clang on there complaining about returning by standard move. Okay. Which they probably shouldn't have been doing in the first place because they were returning local variables. So I just wanted to call that out. It's one of my pet peeves with people wanting to overuse standard move.

Right. Okay. This next one is a note about the volatile keyword in C++. And another good blog post using some GCC godbolts for the examples showing some of the differences between how Clang and GCC treat volatile. Yeah. Did you get a chance to look at this one, Dan? Yes, I did.

And immediately what came to mind is there's a gentleman named John Rieger, spelled R-E-G-E-H-R. Yes, I know him on Twitter. He's a professor at the University of Utah, I know him on Twitter. on the fact that volatile is often miscompiled. You can easily find that by just doing a web search for John Rieger volatile. It'll take you to his blog, and he has links from there to his paper. And he had follow-up blog posts several years later, and what he found was that most compilers at some point or another will miscompile the use of the word volatile by not translating the accesses properly. They'll squeeze in some optimizations that they ought not do.

And the net effect is that volatile isn't always trustworthy in most compilers. And I have not looked at his latest postings on that, but I know his follow-up said it still hasn't gotten better. And what this blog posting that you were referring to says, yeah, it's still not fixed, that you have to be on your toes when you're using volatile to get volatile semantics as opposed to atomic semantics, which they they say, yeah, you should be using standard atomic for that instead. But if you need to get volatile as a way of turning off the optimizations, you really have to look under the hood and make sure it's doing what you think it's doing. This is kind of important to you as an embedded developer, right? I mean, volatile? Yeah, it is. So it's just one of the things on your checklists that you have to do during code reviews is possibly look at the code that's actually being generated

to see if it's actually turning off the optimizations the way you want. And what it also says is that use of volatile should be confined to as small a space as possible because if you distribute the use of volatile widely in your code, you have an awful lot of stuff you have to check very carefully until you establish that your compiler is highly trustworthy. Interesting. Okay, this next one

is an article at WOBOQ and it's called Wobok, I guess, Wobok Code Browser and it's kind of giving an underhood look at what this code browser does and how it operates using Clang in order to parse the code.

And I haven't tried out this tool, but it seems to be another nice tool for browsing a code base online. You can click on a symbol and get navigated to that function or class or whatever. So it seems like a nice tool. What do you think about this one, Jason? Yeah, I mean, it looks pretty good. You know, we saw a lightning talk about a tool like this, and I don't recall if it was this tool or a different one.

I don't think it was this one. It was definitely one of the lightning talks that we discussed in our interview with Chandler Carruth, though. Okay. So one thing that I love about this is it does macro expansion. Anyhow, that looks pretty cool. And then there's a little note here.

Where is it? That makes a comment on NoSQL databases. Because NoSQL is trendy, we are using a well-known NoSQL database directly included in the kernel, the file system. Yeah, I chuckled a little bit at that one, too.

Okay, and the last one we have here is Vittorio Romeo wrote a blog post on this paper that was getting a lot of attention on Reddit last week. An empirical study on the impact of C++ lambdas and programmer experience. I did not read the whole paper, but the first thing I did was I read the comments on Reddit and immediately realized that the paper was probably not worth reading. Probably flawed, yeah.

Yeah, and Vittorio is basically going through the paper and doing a takedown of it on why it makes no sense. The paper is basically comparing lambdas against iterators and determining which one is more accessible and programmer-friendly. And it doesn't really make a lot of sense to be comparing lambdas against iterators. Right, Jason? Right. But I also wanted to say that Vittorio's article is very well written. Yes, very well written. Dan, do you have a chance to look at this one or the paper itself?

I didn't look at the paper. I did read the critique. And certainly the critique seemed credible. But you don't know until you actually read the paper yourself, at least portions thereof. What I would say is I think this kind of research is important. And the fact that this particular paper may have been done badly shouldn't be an indictment of this kind of research. You know, I think that more of this work is necessary because there are often claims of certain language features producing results of improved productivity for which we have very little scientific evidence, yay or nay. And this was at least an attempt to do it.

And the fact that it may have been done less than perfectly is, I say, shouldn't be an indictment of this kind of research. Yeah, that's definitely a good point. I'm not sure if that's the type of thing that the standards committee is really thinking about. I doubt they do any type of user testing or anything before committing to a new feature. Oh, I don't think they do this beforehand. This is often an afterthought. Right. afterthought. I do wonder though, maybe if companies like Microsoft that are building some of the major compilers might be thinking

about things like this. I don't know. Okay, well Dan, let's start talking to you about embedded development. Maybe to start off, you gave a great keynote at CppCon this year. Do you want to tell us a little bit

about the keynote and the type of feedback you've gotten since then? Well, basically, the keynote was intended to explain what I think is possibly a problem for the C++ community, which is that many of us believe that we have a tool which is a superior tool for doing an awful lot of things that used to be done with C. Now, I'm not making a comparison between C++ and any other language besides C. We have this situation that just about everything you want that's in C is available just as well in C++. There's very little that you lose. And I would think that given how easy it is to take existing C code and simply recompile it as C++ and then continue to use the C++ compiler to largely compile C. You'd think, well, what's to lose?

And now I've got all of these additional tools sitting in my tool chest, some of which might be useful for making my life better. And what I'm seeing is an awful lot of people in the embedded community who are saying, I want no part of this. I'm highly suspicious of C++. I'm afraid that if I switch over to it, I will lose all kinds of performance, lose all kinds of portability, whatever it is that they're concerned about, and I'll gain very little. And it'll open up this Pandora's box of features that will lure us into doing all these horrible things.

And that seems to be not for everybody, but I hear it enough that I thought I should say something to the C++ community and say, well, maybe the manner in which we are presenting this language to a large audience of potential users, maybe we should rethink our approach. So I'm curious, if that is the attitude that you have seen in the embedded community, have you ever seen any justification to it? Like, have there been cases where they have lost something by moving to a C++ compiler? Well, I ask for those details, and it's often, well, I didn't try it myself, but my buddy told me, and I place a lot of stock in what my buddy said. For example, somebody will say that I hear there are all these performance gains and what we should be doing is identifying a subset of C++ that is safe and efficient to use. And I say, well, can you give me a specific? And at that point, the conversation kind of breaks down with, no, I can't give you specifics. I didn't experience it myself.

But I've heard all these horror stories, and people find this credible. And these stories flourish. It's interesting. That's what I often encounter. It reminds me of Miodrog's talk on moving MAME from C to C++ that he also gave at CBPCon. And he seems to say that simply recompiling the C with a C++ compiler exposed and helped them catch a lot of type kind of errors in their C code. Yep. And yeah, that's usually what it does. It exposes latent possible bugs,

narrowing conversions or things like that, that you'd like to get rid of. And C compilers would never notice, basically? Well, if you're using a C compiler with a good static analyzer, the transition from C to C++ is very painless. The only thing you have to worry about is things like the use of a C++ keyword to name an identifier. You know, somebody in their C code had named something a boolean

called public you know or something like that right right that has to be changed um the other thing is that the treatment of enumeration types but even there if you're using a static analyzer and say treat all my enumerations as distinct types, when you port that to C++, there's almost nothing to change. The treatment of void star is a little different. You might find that conversions that even a static analyzer for C might look the other way. A C++ compiler might complain because, you know, the conversions in C are bidirectional. You can go into or out of void star to any pointer type without any casting. And in C++, you can only go into void star and out of void star.

So you get little changes in rules like that. But that's the level of the difficulty that you encounter when you convert from C to C++. So I found that you can convert large swaths of C into C++ at the rate of thousands of lines per hour. That sounds pretty efficient. Well-written C, yeah. That's why the bar is so low. But the concern that I hear is people say, yeah, but once I could compile with a C++, I have no control over my programmers. They're going to start using partial specializations that I don't understand.

And then I'll have all this write-only code. Nobody else will be able to maintain it. And sometimes those problems are legit, but I think that the amount of fear associated with that is pretty high sometimes. When you talk about, it sounds like someone maybe at the head of the development at some embedded software company saying, oh, I don't want to make this conversion. I'm afraid of what my programmers will do. Is it somewhat of a generational change that needs to occur where C developers just aren't ready to move over to C++,

but maybe as younger developers start getting more control, they might be more willing to? That's a good question. And I'm not sure about the answer because I think that there probably is a generational thing where you find that this resistance to change is a little higher among people more my age than yours. But there are a lot of people who go through undergraduate degrees in electrical engineering and then get thrown into software development and doing embedded development. And some of them appear to be as leery of C++ as some of their elders. At the beginning of your talk, you showed this graph of C++ usage in the embedded industry and how over the past 10 years it's gone slightly in a downward direction as C++ usage has increased. Do you have any idea what may have began that trend?

And was it ever a more positive trend for C++ in the embedded industry? Well, as I mentioned early in that talk, it may have been just a throwaway line. I didn't have a graphic for it. But the publication for which I had been writing Embedded Systems was called Embedded Systems Programming, and it remained Embedded Systems Design, and then it went out of print. And what's left is Embedded.com, the website. But back as early as, I think, 94, 95, they were doing surveys in which they were asking people about what tools they were using. And the manner in which they phrased the question in the 90s was, tell us all the languages you're using. And around 2004, 2005, they changed the

question to simply say, which language are you using the most? And that coincided with the bend in the curve. So it is possible that simply changing the way they asked the question altered the way the data was collected. But the problem is that we've seen now, I guess it was from 2005 through 2014 is the data that I have. And the direction of the line in both the case of C and C++ is that the percentage of projects for which C is the dominant language has inched up over that period and the percentage of projects for which C++ is the dominant language has actually gone down. And that's almost a decade of repeated experience for this direction that it's hard to ignore it. Is it possible that rephrasing the question would change that?

Yes, but that's not the data that I have. So I just have to go with what I have. Now, by the way, this is not the sample is based on the readership of this one publication. It is a I believe, a publication with the largest circulation in that industry. But, you know, you always have to be a little reluctant to place too much stock in one sample like that. But it's all we got. And so the question I was asking was, do we in the C++ community care? Should we investigate this further and look at those results and decide to take some action?

Maybe change the way in which we are presenting C++ to the larger embedded community. So I guess then, have you come to a conclusion in the last month about whether or not we should care or maybe what kind of feedback have you gotten from people about whether or not we should care well interestingly um you know they that particular talk was a mix of technical and less technical there was uh psychology and uh you know the what those of us who practice engineering for a living think of as the soft sciences. Physics is a science. Psychology is a pretend science. But the the reactions that I got were more about that portion of the talk than about the other technical issues that I was raising. I was mostly using in that talk programming examples to try to illustrate ways of presenting

C++ differently to make it to shed it in a more positive light to certain users. And I wasn't saying these are the definitive approaches. I was just saying we should be thinking along these lines, trying to present the virtues of C++ to C programmers in a slightly different way. Actually, one could argue it might be a dramatically different way. And I think a lot of people thought that those insights were interesting, even though that they didn't entirely agree with me. Most of the feedback I received was just by reading the comments that were posted on the YouTube page. But I received a dozen or more fairly lengthy letters from people who wanted to engage me in some personal exchanges. Most of them were saying this is interesting. They were questioning. You really think it's like this? And there were one or two people who were saying, no, I don't buy what you're saying. Here's why. But the overall

impression I got was that people, it made them think, which is the point of a keynote. 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, Bactrace jumps into action, capturing detailed dumps of application and environmental state. Bactrace 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, providing your team

a single system to investigate errors across your environments. Join industry leaders like Fastly, Message Systems, and AppNexus that use Backtrace to modernize their debugging infrastructure. It's free to try, minutes to set up, fully featured with no commitment necessary. Check them out at backtrace.io slash cppcast. It seems like, in addition to your keynote, that there were a lot of talks at CppCon this year that might be of interest to the embedded community.

There was also Jason's talk, plenary talk, which, although you're not an embedded developer, Jason, I think that talk would definitely appeal to embedded C++ developers, right? And the idea is for it to have some appeal. Yeah. In fact, I will tell you that they specifically arranged my talk to be before Jason's, thinking it was a good lead-in. Sure.

And indeed, I heard from John Kalb, the conference organizer, and some people as they were leaving Jason's talk said, this was a great follow-on to Dan's talk. Yeah, I was under the impression that I was supposed to be a good follow-up to you, not that you were supposed to be a good lead-in for me. Well, do you think this will have an effect on the embedded community? Do you think they might take notice of what was going on at CppCon this year and maybe have more interest in C++ because of that?

I don't know. I really don't. Part of the problem is that the embedded community exists in little pockets that don't necessarily interact with each other. And one of the comments that I made in my keynote was that after many years of writing for Embedded.com, I didn't realize just how much people in the C++ community weren't paying any attention to what I was doing. And it was only when some of my stuff got published in Dr. Dobbs' journal that people were saying, oh, hey, look what Dan's doing. And they weren't noticing embedded.com. And I think that a lot of people who read embedded.com don't go and read things like, they don't check isocpp.org and see what's going

on there and the hope is that we'll gradually get a little more cross-pollination and maybe again as a follow-on to my keynote maybe the community will say yeah we should be doing more things on the C++ Foundation's website to link to things in the embedded community and encourage them to link to us. But we'll see. So I'm kind of curious, since you've mentioned writing for these magazines and websites for a while, how did you end up getting started writing for magazines? Oh, well, one thing is that this is a very interesting cultural difference between the computing environment today and the way it was back when I started doing this around the 1990s was that I can remember throughout the 1980s this growing business in tech publications.

You could go into brick-and-mortar bookstores. You know what those are? And there would be a shelf full of magazines like Byte Magazine and PC Tech Journal and things like that. And this was how many of us kept up with the field in those days by reading print publications. And, you know, there was no there was no web then. And the this as I'm saying this, I'm remembering the first time my son asked me, so, Dad, when you were a kid, what was your favorite video game? And I said there were no video games when I was a kid. I had to pick his jaw off the floor.

And so we say there was no web. There were no blogs in those days, which provided was print publications. And so and there were lots of lots and lots of filling up shelves in, you know, there would be a an entire shelf of these things next to the fashion magazines in a typical brick and mortar bookstore. And so so I read a lot of these and I would often then get these glossy brochures in the mail announcing some conference conferences like CPPCon used to make themselves known by direct mail. And so I would look in the direct mail and see the kinds of talks that were being given and who was giving them. And I simply said, you know, that looks like a nice way to make a living, to be doing that kind of on-site training and consulting.

And how do I get there and the answer was start writing for these trade publications and start showing up at these conferences and so I actually the way I got started with my first article was that I saw that also many of the people who were appearing at these conferences and writing for these journals were participating in some standards activities. And so it's actually my getting involved in the C standard. I found out how easy it was to get onto a standards committee and I attended the first several meetings and I learned an immense amount. I thought I knew C. And in those first two or three meetings, wading through the standard, the draft standard was a really enlightening experience. And the first conference that I went to, it turned out the publisher of the C-Users Journal was starting a new magazine. And about it was called Tech Specialist, which was a pretty obscure name.

It was a PC centric tech publication. And he said we were thinking of starting a column on programming style and i said oh i could write that and it he had already seen some of my writing from some of the articles he had accepted in the cdu and he said okay i'll give you a shot and it was serendipitous really that i was at that conference when he announced in his booth that he was starting a new column and when i asked him about the the publisher i asked him about what are you doing for the that conference when he announced in his booth that he was starting a new column. And when I asked him about the publisher, I asked him about, what are you doing for the programming style column? He said, I'm not sure.

And I said, give it to me. And he bought it. And that's how I got started. That's cool. You just mentioned pre-standard C, which I'm just curious, is that 1989 when C was standardized? The first standard? Yes. standardized? The first standard? Yes, the first standard was 89.

The Standards Committee started working around 83 and took about six years. Wow. Seems like a long time also. What, six years? Yes. Yeah. Well, see, what happens is that every so often there are surprises in the case of the C standard. My understanding was that sometime around 1986 or 87, they thought they were getting close to closing it out.

But there was increasing involvement from the international community. And they the participants from abroad looked at the standard and said you know this is very american english centric you know there are functions like the the ask time asc time function which would produce dates and times in a character string. And for some reason or another, the months would always be spelled in English. And the month would appear before the numeric value of the day. Right. You know, it would be July 4, not 4 July. And the people from abroad said, you know, not everybody does it the way Americans do it.

That may come as a surprise to you Yanks, but that's, and so that kind of stuff prompted the committee to say, gee, maybe we should be including some of this. And that caused a delay. And that's sort of analogous to the C plus plus standards committee started in 90.

And by 93, 94, they thought, Hey, we're closing in on this. And then somebody said, you know, there's this guy at HP named Alex Stepanoff, and he's got this really cool library. They call the standard template library. Maybe you should find out about this. And adding the STL to the standard injected a three, four year delay.

But the decision of the standards committee was it's worth it. It has such an impact on the functionality of templates. It's like such a good testing ground for testing templates. There was this back and forth improvement in the STL and templates that took a while to stabilize. In fact, continue to take a while even after the first standard, as we have seen how much those facilities of the language in the library have changed. Right. And so it just became a point. We got to wrap this up and ship something. But the judgment of the committee, my recollection was that, yeah, adding the STL is going to delay

the standard, but it's going to be worth it. So I wanted to ask a little bit about what the trend of the embedded industry is like today. You primarily go and consult with embedded developers that are interested in C++, right? So are they using kind of the newer modern C++ features? No, actually, a surprising number of my, maybe I shouldn't say surprising, simply a number of my clients are still telling me, we would like the C++03 version of your course. Oh, wow. That we're not up to using C++11. And that's often driven by the tool chains they're using. My understanding is that

there is a lag, a bigger lag in the embedded tool development between the time that something is added to the front end and the time that they get all the back end tools to support that facility. The embedded tool chains are much more reliant on interaction with things like debuggers and other kinds of analysis tools, and getting all of those things to be able to handle the symbolic names that arise, for example, from templates and namespaces and those complexities,

that chore is harder than it is for the desktop tools. It's also that the economies of scale aren't there. Whereas Microsoft has a huge code base, user base, I should say, for Visual Studio, a lot of these other vendors in the embedded space have a much smaller client base. The compilers sell for more money. They sell fewer of them and to fewer people. And so they will listen more to the client saying, well, you know, we really need this facility in the debugger. We really need this other capability in the loader that comes with this or the tools that are used for burning things into ROM, that kind of stuff.

And there's a lot more emphasis on that kind of stuff in the embedded community. So as I mentioned in my keynote, just in preparation for my keynote, I downloaded some of the free versions of the tool chains for some components like by AR, who's a player in the embedded tool space. Their latest compiler doesn't support any C++ 11. Wow. And you wonder, what are these people doing? And the answer is they're working on the other tools. That's what their users want. And so then I go off to my clients,

and it turns out that my embedded clients are working with a half a dozen different tool chains, two of which have C++11 and four of which don't. And so they say, okay, we've got to write for the least common denominator, which is C plus plus three. Now, that creates a real dilemma for me in teaching, because, for example, if I want to show people the use of function objects, I have to show them this and say, I want to lay the groundwork for your use of lambdas, but I can't show you lambdas. Or I can show it as a teaser maybe you know i may start show doing that it's just having one slide that says and here's what's coming down the pike but i can't spend a lot of time on showing them this stuff because too many of their tool chains don't

handle it so then the question is should i still be showing them that if you create function objects they should be derived from unary function or binary function, which are deprecated. Right. Right. What's the proper style? See, because they may be looking at legacy code. I may be telling them, I would not encourage you to derive from unary function or binary function anymore because they're deprecated. But you're still going to see stuff in your code base that's derived from that so you have to know about it so you know when we talk about embedded it seems like we're talking about everything from tiny microcontrollers with no memory management unit with with proprietary compilers all the way up to like full arm systems

basically that just happen to be really small, and you can use a modern clang or GCC with that. Do you deal with the whole spectrum, it sounds like? Yeah, well, bear in mind, I do not actively do development. I consult with people. So they just tell me what they're confronted with, and I take my best shot at telling them how I would approach the problem. I would tell them, I'd look at this aspect, I'd look at that aspect, but they have to go off and solve the problem. But yeah, my clients are at all those ranges.

They tend to be more at the high end than at the low end. It seems like the embrace of C++ is more at the end of the spectrum where people are dealing with those complexities, and the use of the abstraction facilities of C++ start to really shine. The people at the low end who are still writing microcontroller applications with extremely limited RAM, they do not see the same kind of benefits from using C++ that people at the high end would see. And they also have more limitations from their compiler vendors. Yeah. It sounds like.

Yeah. In some case, the platform they're using doesn't even have a C++ compiler. That's less and less frequent, but that certainly was the case just a few years ago that people say, yeah, we chose a processor and it doesn't. The only possible C++ compiler we could use would be a port of the GNU toolchain. There are no other commercial products available. Right.

Jason, you have any other questions? No, I think that wraps it up for me. Okay, Dan, where can people go and find you online? Obviously, we'll be pointing them towards your talk, but where can they find you online to get more information or maybe look into your consulting? Oh, dansax.com. I'll say KS.

When people tell me, if I couldn't find you on the web, I say, you know, you didn't try. There are a lot of other Dan Saxes, but I've got dansax.com. One of the other Dan Sachses, if you Google, he's a rock musician. That's obviously not the one I'm looking for. Okay, well, definitely encourage everyone to go and watch your CppCon talk. It was definitely very interesting and has plenty of things that C++ developers should be thinking about.

Yeah. Yeah. Okay. Thank you so much for your time today. Well, you're welcome. Thanks. Take care. Bye.

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.