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

Arguing is presenting your points and your view of things. How can you convince someone without arguing? If I want a c programmer to use c++, I can say "c++ is better. use that."
The other person says: "Nah, I'm good mate."
What now?
I can either say: "It's better because it's basically a superset of c and gives you more features while still compiling your c code. It also adds lots of nice features, none of them you are required to use, but would make your code faster, less buggy, safer and more portable, and quicker to write."
Or I can choose not to argue and drop the topic. Which do you think would convince the other person more? I don't know about the first option, but I know the second option has about 0%.

C++ sucks, C99 is superior one!

C++ is a garbage language -- its syntax is absolute garbage

Being a professional programmer in the embedded environment, unfortunately that trend that the c++ popularity goes down still is a thing

I have been working as an embedded software dev for 2 years. The reason I use c is because everyone else is using it. Legacy code is written in c. All the libraries are in C. And I had an argument with a c++ programmer about use of c++ in embedded and the reasoning he gave me was classes and all. Oops is great but I personally don't think it is that big of a deal as people make it to be and certainly not big enough to give up all the libraries and old code out there.
About the error message at compile time I totally agree I still mess up things specially strings.

I will always prefer C over C++. I want to think about a solution of my problem and not about the language I use.

Does the computer have the concept of a class?

PS: What I mean is that PCs work with binary, binary is equal to assembly, assembly are just instructions from an ISA.
C encapsulate assembly in a simple way (by modern standards), making it easier to work with PCs, being pretty much as fast as it gets if well optimized.
You can go beyond simple C with abstractions and yes, you can achieve the same performance (if you achieve good assembly), but stuff can go bad real soon.

For me the reason I prefer C is simple, with C it's easier to understand WHY something went wrong when it does go wrong, with C++ you have to dig into implementations, assembly, and sometimes confounding classes or syntax, for example what the hell was wrong with casting with something like (long) that you had to go and make a stupidly long & seemingly pointless name like reinterpret_cast<long>??? If a developer didn't understand what a cast was then get them the f**k out of your project because they're a landmine waiting to happen. I'll admit try/catch/finally, classes & templates are useful features I WISH were supported by C but not to the extent of the nightmare that is overloaded functions, weird ways to cast, innately incompatible with C returns, you HAD something good, then you ruined it

Super nice talk. Yes. This is one of the few that you save and need to watch it again.

I LOL'd at the line "You're coming from a culture dominated by double-Es and computer engineers whose instructor wasn't interested in teaching them programming. They gave them a copy of K&R and said 'Make those lights blink.'"

Those who know me know I've complained about "double-Es who think they can program." I've seen some amazing spaghetti code and some of the word software engineering practices ever from folks who have one or more EE degrees and are able to make a C compiler produce an executable once they've swatted down enough warnings and errors.

Put down the pitchforks. My own degree is BSEE. I have no formal training in computer science. My criticism comes from within the EE discipline. :-)

I was very fortunate to have a very forward thinking and rigorous professor that taught me C back in 1993, during my freshman year. He didn't just shove K&R in our hands and say "make those lights blink." He shoved K&R in our hands and taught us how to program. Or at least tried. (Yes, K&R 2nd Ed was actually the textbook for that class.) I don't know how well it took, though. From what I remember of the grade distribution, three of us were at the top (and I was in the three) and the rest of the grading curve was way below. At the time I took the course, I knew a half dozen BASIC dialects, assembly languages for three different architectures (TMS9900, 6502, 8086), and Pascal.

He switched to teaching C++ as the default within a year or two. Even before that he strongly encouraged me to take a look.

But, like Dan's comment just before that like said, you really do need a mentor to figure out how to use C++ properly. It wouldn't be until years later I was mature enough to seek out the advice I needed (through online resources, books, and so on) to properly switch gears.

I did it in three phases. Around 2006, I started using C++ in earnest as "Better C," with limited use of classes for interfaces, heavy use of inline and namespaces, and heavy reliance on compile time type checking.

Around 2008 or 2009, I started replacing macros with templates to get compile time evaluation. By 2010, I managed to put together some super-efficient code that (for many aspects, at least) compiler proved correct at compile time.

The most notable of those C++ projects were actually embedded projects that needed to run in extremely constrained environments. (Think "RTL simulation of a CPU that doesn't exist yet, running around 1kHz.") I wasn't constrained by memory capacity; rather, I was constrained by extremely low execution speed, including startup overhead.

In 2013, I was handed a project that needed rescuing. It was a 17 year old C++ codebase that had basically rotted from within. I decided to greenfield it in modern C++. I decided to "go native," and immersed myself in as much online training as I could. I had seen enough to know that I needed to truly open my mind to learn it properly.

BTW, I also laughed extremely knowingly at the whole discussion on the confusion between arrays and pointers in C. ZOMG some of what you had to say could have been lifted directly from answers I wrote on Quora or private discussion I had there. And I know it wasn't, because this talk was in 2016, and I wrote those answers later. I wish I'd seen this talk sooner. I would have linked to it so many times!

I don't know how I missed this talk back in 2016. I'll pin it on changing jobs in 2015 and being sucked back into an almost exclusively C environment. That kinda dampened my enthusiasm for watching CppCon videos. Turns out, I really missed out on some good material.

one perspective is that many embedded coders are from EE background without a full CS training, and it's much easier to hack on C instead of the heavy study on c++ for them

As someone who generally prefers C to C++, this talk really got me thinking about why that is. Part of it is just personal preference, but I think a significant part of it comes down to that although C++ enables you to write better code, it also enables you to write worse code, and we come back to the tendency to feel the losses more than the gains.

@world views: Yes psychology of communication between communities vs. individuals have complexer rules. The here shown diagram can help, but should not be misunderstood sorting peoples mindset in static categories like hierachical-egalitarian/individual-community. Peoples mindsets are not static and evolve over time and/or change depending on the view/perspective to a given problem, people are able to use a total different mindset compared to a different problem.

If I remember correctly, as a response to making players addicted, in World of Warcraft they once introduced a malus for playing for multiple hours in one session. Players hated it. Then, they went to a reward system, where if you did not play for some hours, your character is “refreshed” and “ready to take on challenges” which is expressed in a stats boost.

The main reason C dominates in the automotive sector is that the code generators (e.g. from Matlab/Simulink) produce C code...

Cpp is cool and all. Until the microprocessor only has a c compiler.

No I won't pay the C++ tax. C is fine, thank you.

People are ignoring C++ (due to misinformation) the same way that Fortran (2018) is ignored too (due to misinformation), which is also a modern language with OOP support. Let's not be very judgmental then. This was a fascinating talk.

im going to be honest, i think the thing that stops a lot of C programmers from using C++ is the weird syntax it has sometimes, it looks outright alien from the rest of the c++ and c language sometimes and its unironically really offputting.

I have seen so many people over the years programming embedded in C++ and thinking they're using C. No standard libraries, no heap allocation, classes are rare, instead using global variables and functions everywhere, file extensions don't really matter to the compiler, so you can call a c++ file *.c . Becomes hard to see whether it is C or C++. Some people call it C+. But you don't have to use every feature of C++ for it to be C++, just one that isn't in C. Almost always they've included a C++ class library somewhere and don't know it.

Wouldn't the examples he brings up be covered by a static analyzer/linter type of tool? The problem with introducing C++ is that it's like putting a naive person in the garden of Eden -- they'll bite off more than one can chew.

I much prefer C as I find it to be more 'solution focused,' in effect I've come to appreciate C's relative resistance to arbitrary increases in complexity, C++ almost encourages you to add incidental complexity in an attempt to meet some set of ideals that are often unrelated to directly implementing the solution

I always stand for both the languages. I believe that a C developer should acknowledge C++ and a C++ developer should acknowledge C. Whenever I get asked which language I code in, I say C/C++. C and C++ are like brothers. Stop the hate between the two languages.

People pay too much attention to whether languages are becoming more or less popular. I use C++ because I prefer it and I prefer working in the problem domain that C++ is well suited to. Do people care whether hammers and screw drivers are becoming less popular? They're all tools.

Compared with C++, C is (a) stable, (b) supported by more different vendors, (c) much better understood, (d) much less likely to have massive unsuspected overheads slip in. There are also some really good checking tools.

These days, I think it seems to be more like "Talking to C/C++ programmers about Rust"

There is a difference between interpreting policy-effect data in hindsight and a medical study. You can't be sure about the level of control, cultural significance, etc. That could explain part of the "misunderstands what they don't agree with" thesis

The thing that annoys me the most about C++ (and why I rarely use it), is that there are seemingly ten thousand ways to do nearly the same thing. The one thing he mentioned is Vectors vs Arrays. If vectors are so much better than arrays then why do arrays even exist? Why isn‘t an array just a vector?
Why do I know have to go out and try to find credible information that tells me when I should probably use one over the other?

It is even worse when it comes to ‚pointer like‘ things, especially function pointers where C++ seemingly has ten different concepts to pass function and all come with slightly different restrictions that aren‘t visible in code.
In C I decide and it is immediately visible through code with functions (pointers) can act on ‚objects‘ and which are common to some ‚class‘ or whatever restriction it has.

So for C++ I constantly have to check the wiki or Google to find some options that are similar to what I want to do, then I have to find out which restrictions these options have and then I have to find out which one would be ‚recommended‘ for my use case. And quite often the recommended way you find is presumably aimed at writing desktop applications and the library for it instantly fills all available storage on my embedded device, making it useless.

To me C just seems to be much more focused (it is meant to write really low level embedded code) while C++ tries to have a bit of everything for everyone which just ends up making the language and libraries really confusing.

As an EE I would be interested in modern C++ solutions applicable to the embedded domain. Are resources available (preferably implementing HW access and RTOS abstraction)? I think, the embedded C programmer's expectations are: tailored and proven solutions... Patterns. Does and don'ts.
My concerns: Portability of Cpp in embedded.
Welcomes: Built-in constructs for generalization and specialization on Structure + Behaviour while preserving type information and type checking.

Impressive talk. Also very interesting personal thoughts and ideas apart from the technical aspects.

My understanding about programming is that programming is about choosing the right tool for the job. After all, who uses the back of a screwdriver to drive a nail into the wall.

The failure of CPP in Embedded programming!! ... err What?...
That does not make sence.
What about the failure of diesel engines in motor sports such as Formula 1 or Nascar?
What about the failure of petrol engine in container ships, freight trains, or city wide metro trains?

Or "Identify factors that are inhibiting C programmers from moving to C++"!!

What if we change that to something like this.
Identify factors that are inhibiting the use of petrol engines in container ships?

The thing about programming is to stay open minded, after all. There must be a reason we don't use the same tool for all tasks. Just as petrol engines is not used for all applications. Too me programming languages is no difference from engine types, or different types of tools.
Hammers are normaly used to hammer nails, bu may sometimes be used to loosen a bolt or nut, however nobody uses a hammer to unscrew a bolt or nut.

I think the intricacies of C++ are daunting.

C++ has an insane cognitive load, with only marginal performance improvements vs C for the embedded world (~5% for the given benchmarks). It's obvious why the market moved towards C.

Wow. Very insightful.

I enjoy writing C more than C++, but this talk is a prime example of how fanboys will argue till their face is blue just to be right. Both languages are amazing tools and like any tool, your best results come when you understand the tool and use it in a way that is performant and sensible for the solution you’re trying to create.

I am not a programmer, yet. And now I am deciding which language to learn. One thing I noticed about this talk is that is very good talk and very well reasoned. But what interests me is when and who defined that those people who using C should be using C++? On what that statement is based?

one complaint i've heard about c++ is that "it does things behind one's back." The C coder hates constructors and destructors, and doesn't like operator overloading. Whatever the program is doing, he wants to see explicit lines of code for every action. Badically, he wants a portable assembly language, and c++ ain't it.

I'm not at all experienced with C, but I think the most alluring aspect is that the language is must smaller. C++ comes with a lot of different concepts and features, some which are discouraged, and many that are convoluted. The best argument for C++, I think, is that it's backwards compatible, so what is there to lose? If you don't like this or that, just don't use it. Eventually, you might change your mind once you've got the foot across the line.
There might also be some nostalgia involved. I've seen certain people being very elitist about mastering certain languages. Sure, their solution might be very smart and elegant, but honestly, it makes no real-world difference. Most of us really don't need to torture ourselves with that level of nitpicking and trickery. The standard library in C++ has you covered on so many problem areas. Why try to solve the same problems again? Listen to experience, and move on.

I really dislike the of taste of proselytism of the questions.

Please respect people have other beliefs than you, and please accept that you might be the one who is wrong.

Loved the talk but as always the speaker won't really answer the questions they are asked

I gradually switched from C++ to C a few years ago. Not persuaded by anyone - it happened by itself.

I like C++, but my primary concern is that it's extremely complicated. I understand C++ quite well, including concepts like move semantics, operator overloading, SFINAE, vtables in objects, iterators, exceptions, and so on. It's just that it's quite a cognitive load to hold in your mind, while you simultaneously are trying to solve a non-trivial problem. C lifts a huge chunk of that cognitive load, freeing mental resources, making it easier to reason about the actual problem you're trying to solve.

The fast and neverending adding and adding to the standard continues to make this problem worse. It's not true when Stroustrup claims that adding the new stuff makes the language simpler. When you add new stuff, you don't just have new stuff in your code base - you have a mix of new and old. Adding smart pointers don't make raw pointers go away. Adding modules don't make header files go away. It just means there eventually will be a million ways to do the same thing, and you should have a grasp of every technique, because you might encounter code doing things in another way.

Also, after I switched, I found out that the amount of work needed to do the manual stuff C is quite exaggrerated. For instance, making a C API with vector-like functionality is quick, easy and straightforward. I have had several eurekas like this already that making things in C isn't as slow and cumbersome as I thought.

Edit: On second thought - I think it was Herb Sutter, not Bjarne Stoustrup.

Probably only takes to convert one person..