CppCon 2016: Dan Saks “extern c: Talking to C Programmers about C++”


Presentation Slides, PDFs, Source Code and other presenter materials are available at:

Most of us have heard this story. We’ve even told it ourselves…

C++ is nearly all of C, plus a whole lot more. Migrating code from C to C++ is pretty easy. Moreover, the migration itself can yield immediate benefits by exposing questionable type conversions that can be sources of latent bugs. After migration, the code performs as well in C++ as in the original C. And now that it’s C++, you have ready access to a wealth of advanced features you can (but don’t have to) use to implement enhancements.

Who wouldn’t want that? Legions of C programmers, apparently.

Despite the success of C++ in numerous application domains, C remains considerably more popular, especially in embedded, automotive, and aerospace applications. In many cases, projects resist C++ because their managers think the risks outweigh the benefits. In other cases, the resistance comes from programmers who persist in believing bad things about C++, even when those things aren’t true.

What can the C++ community do to overcome this resistance? Drawing on lessons from cognitive science, linguistics and psychology, and (of course) computer science, this talk offers suggestions about how to make the case for C++ more persuasive to C programmers.

Dan Saks is the president of Saks & Associates, which offers training and consulting in C and C++ and their use in developing embedded systems. Dan used to write the “Programming Pointers” column for embedded.com online. He has also written columns for numerous print publications including The C/C++ Users Journal, The C++ Report, Software Development, and Embedded Systems Design. With Thomas Plum, he wrote C++ Programming Guidelines, which won a 1992 Computer Language Magazine Productivity Award. Dan has taught C and C++ to thousands of programmers around the world. He has presented at conferences such as Software Development, Embedded Systems, and C++ World. He has served on the advisory boards of the Embedded Systems and Software Development conferences. Dan served as secretary of the ANSI and ISO C++ Standards committees and as a member of the ANSI C Standards committee. More recently, he contributed to the CERT Secure C Coding Standard and the CERT Secure C++ Coding Standard.

Videos Filmed & Edited by Bash Films:



  1. Very interesting presentation.
    But I don't get the idea.

    I use C. It has a crappy type system and offers no help with memory corruption, memory leaks, or race conditions in threads. It is at least simple to reason about.
    You want me to replace that with C++. Which has a crappy type system and offers no help with memory corruption, memory leaks, or race conditions in threads. And on top of that is so mind bendingly big and complex a language that no single human being understands all its parts or how they work together.
    Get out of here.

    Call me when you have something that actually helps solve my problems.
    Whichever way you want to "frame" it C++ is C with classes. It does nothing to help make reliable software.

  2. The answer is simple: take a well written code in C and show how it can be made better in C++. By better, I mean easier to understand and debug. Programming languages are an interface between people and the computer. As Scott Meyers said: interfaces should be easy to use correctly, and hard to use incorrectly. C++ will gain following when it is clear that programs are easier to write, understand and debug when using C++ versus C. If that is not the case, then why should people adopt C++?

  3. People live in camps and they'll staunchly defend their positions at all costs.
    This talk is interesting but not for any of the reasons described.

  4. Would using C as a method of generating dna sequences for drug discovery based on very specific criteria be considered embedded software?

  5. I'm an embedded programmer that has done a fair bit of C++ programming but chooses C for my professional projects. Even if not more rational than others, I like to think of us embedded programmers as pragmatic people;

    What's to gain from using C++? More bugs caught at compile-time. Marginally faster execution apparently. Expressing some intent through code instead of comments. Objects.

    What's the cost of moving to C++? For one thing, for every extra feature of C++, I'd need to consider the effect on code size and RAM use and determine a policy whether and how to use it. Not just for myself, but for anyone touching the codebase. How well does my toolchain support C++? If I develop a library, how well is C++ supported by other's toolchains, and can they use my C++ code from C? Elaborate abstractions, dynamic memory, streams, exceptions, standard library, Boost, etc — I would use nothing of this when I have 8-32 KB of RAM. The HAL is written in C anyway.

    There may be advantages of C++ but the Pandoras box of risks are too great. For all I know, moving to Rust could be equally attractive as C++.

    Dan Saks touts information hiding as a virtue. I think a handfull of stack overflow debugging sessions shifts one opinion on that.

  6. The argument that convinced me when I was talking to a friend wasn't "it's c with classes" but "it's c with strings" and if you've been dealing with strings in C you know how much of a pain it is. Yeah… That's what got me here. strings.

  7. The table metrics at 16:00 is slightly confusing at first sight, it took me a while to understand that "1.95 x fastest" is actually slowest.

  8. Hmm. I would add that if you're using the word, "should", which implies judgment, you're losing. Use suggest ot recommend and don't leave it to the audience to determine why. Tell them why!

    Also, you can use function pointers in C easily, you know, and even polymorphism, if necessary.

    Lastly, although he established successfully that C++ is a viable option for embedded programming, he conspicuously did NOT explain why C++ had a slight performance advantage over C in his test results, and because it appears to be counterintuitive, he has a responsibility to explain why. I suspect that he knew that the C community would cry foul and would respond by showing how minor legitimate adjustments in the C code might enable it to match or exceed the performance of C++. Consequently, he loses most of the C audience.

  9. I have to Programm in C++ because it makes more sense for desktop applications. But I still love C and prefers it’s syntax and much more beginner friendliness.

  10. My experience is kind of the opposite. Many programmers are using C++ only because the job requires, but they are still writing C.

  11. For anyone who wants to know the difference between polystate and monostate (bundled monostate and unbundled monostate), the difference is in the Monostate Pattern private variables within the struct are `static`. Polystate is a normal struct, ie without static private variables.

    The difference between bundled and unbundled is a bundled monostate is a nested struct, a registers struct. The nested registers struct is static itself, instead of every variable within it static. An unbundled monostate is where there is no nesting and every private variable is static.

  12. As a preferred C programmer (and other old stuff like Perl/bash/etc) you got me when you said "coming from a culture dominated by EEs". At my first job, they had a preference for EE's over CS/Math majors most of the time because they had a large C base and worked with very primitive goals (software modems, voip, DSPs, embedded hardware etc) that the "higher language" people had trouble coping with.

  13. So many bad advises in this talk…Using streams? That part of C++ is so brain-damaged it should not be used in any non-trivial project. Specifically error handling…

  14. It’s interesting. I worked with C++ for a decade or more. Over time I started to appreciate C more, not less. C++ tends to make the problem at hand overly complex.

  15. "std::vectors are too hard, tell C programmers to write a function template that gets a reference to array and deduces the size instead. Also stick a static_assert in there for when this simplistic approach inevitably fails"


  16. The egalitarian appeals to our reason and emotion to show the unwashed masses of C coders that they are, in fact, beneath him!

    This entire talk is so jewy that it is difficult to bear.

  17. I think the biggest problem with C++, from my experience over the last 15 years, is having been crushed by two or three truly horrible C++ implementations that nearly killed projects. The three that crushed me were all headed by C++ zealots that created 'platforms' instead of 'solutions'. It made my life hell, and convinced me that I never wanted to be dragged into C++ again. It wasn't the language itself, it was the people, and how they chose to use the language, and how they chose to show everyone how smart they were by using every possible feature of the language to its largest extent possible. It was awful. I have seen good C++ and I have seen bad ANSI C, but the worst ANSI C I have encountered was easier to fix than the worst C++ I have encountered, by an order of magnitude.

    So the problem wasn't technical, it was human. But the tool basically enabled that bad behavior.

    BTW: Dan Saks is awesome. He really is.

  18. Socialists, communists, fascists, nazis, and other collectivists totally misunderstand individualism–the need for individuals to learn from each other in a free society. Theirs is always an elitist, condescending, utopian attitude. He does not understand why 80+% of embedded programmers are using C because it communicates instructions more clearly to the next programmer than C++ does. Like many other Democrats, he automatically assumes that he's right without bothering to listen. The whole speech fails because he never asks C programmers which so many of us choose C with abundant knowledge of both languages.

  19. He starts talking about programming about 40 minutes in. Before that it's a lot of what I found to be rather boring platitudes.

  20. Some interesting moments but waaaay too long. And the true promoters of stupid old C are embedded systems industry managers who (at best) learned C in university and never improved their technical skills beyond that. And software companies that created their bloated, expensive and "safe" ecosystems ("model driven" blah blah) and those companies prefer to use plain C as the intermediate language, because that's the perfect way to make it look kinda usable and neutral and still appear versatile enough for extensions, and on the other hand keep the real knowledge (business logic) in the data model driven by their tools (basically a vendor lock-in). And C is great for another thing, there is lots of boilerplate code which is obviously easy to auto-test, which makes the managers go wild because the "line coverage" KPIs look so great and so easy to achieve.

    Another reason are bloody expensive compilers for some embedded devices, highly proprietary, and the compiler feature development is creepy slow. And they want a major update for every little feature bump. Imagine you have to buy a new copy in 2011, in 2014, in 2017 and then in 2020, that might be a little car you cannot afford each time.

    However, what really bothers me is that there is no C++11 version of Embedded C++. You are stuck with the language (sub) standard from the last millennium although many comfortable features of C++11 would be very useful and maybe even allow better optimization for code size.

  21. this is actually interesting but for most of the he use psychology to as a proof of his vision while actually it can be used to support other vision (that he is wrong and he believes in some imagine truth).
    actually in safety systems like airbags controller C is used only as C (without std library) and because C is very simple to debug. Embedded world is completely different than ordinary computer world and something like this need to be emphasize. I sometimes get in touch with java or some frontend developers and this are completely different world. They do not understand C and I do not expect they ever will. Embedded world is more about assembler and understanding how everything work in systems and from that point of view C is just simply well suited to do the job. C has very simple structure and if you use some MISRA rules or something similar you never made something wrong. While using C in the end it's very simple to find any data in memory and in map file. Because everything is about some numbers put somewhere in the memory. That way we do not loose understanding of this. Only by strong work on hard embedded systems we can understand that. And I do not expect that normal computer system programmers would catch that difference.

  22. C++ becomes more and more like all the other object oriented languages like Java and C#. So nobody in our company is programming in C++ anymore. Most projects switched to Java. People learn Java at the university. Also the combination of Python an pure C (for the time consuming functions) is often used, especially in the whole big data segment. C++ brings more problems than it solves. As a programmer, I want to solve my current problems, and I don't want to spend hours in understanding cryptic template constructions or never needed rvalue references.

  23. The problem with the example of the men coy without size argument is you and your C++ friends try to solve problems which are only problems for you in fact. It’s totally useless.

  24. He found out that people who do embedded systems prefer C, and instead of trying to find out why he just assumed they're all misinformed. Isn't that exactly how Democrats lost in 2016?

  25. I was looking in hurry for something on Youtube, then I found this video by coincidence and I just could not stop watching it! Really good talk!

  26. If you are arguing and win the argument, you aren't losing.
    What do you care what language they are using?
    They are programming with the dinasours, not you.

  27. The issue is that for smaller systems there is 1. Fewer off the shelf C++ compilers, 2. When you use C++ you have to strip it down to something approaching pure C and 3. Any benefit of C++ over C creates code bloat due to some type of automisation that should be left in the hands of the programmer not the compiler. Above all C maps more closely to the assembly than C++ when you use features like templates – that's not a good thing.

    Of course talks such as this one isolate things down to the most favourable cases but in the main there is no gain in moving to C++ only a lot of superfluous and redundant features. It has been tried and it just doesn't fit as well as C – there's no conspiracy!

    Also your approach is assumes that C++ is the right choice – again that is your perspective it doesn't make you right. I think the main issue here though, and it is clear from your talk, is that you're living in a echo chamber.


Please enter your comment!
Please enter your name here