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.
That is a problem with the people writing the code, not the language. I have seen a lot of horrible Fortran, Algo, B and C code (and some other) - the "best" was imo a student-project at my university............... a web-based service for searching and rating hotels. The userfront was in html, created by a c++backend, that communicated MySql DB and used a java-process for datamanipulation. everything in the c++ domain was cast into some horrible c-style structs with void* and unions. I have seen lectures about program-design that made the simplest digital watch into a 15 class behemoth - just a watch, no stopwatch or moon-cycles or anything else, just counting the seconds, minutes and hours. On the other hand i have seen some nice C++code for embedded Systems were the complexity of setting up all the bells and whistles was neatly hidden under some classes that neatly improved the performance of the old C Code it was replacing as the compiler was a lot better at noticing what needed to be done to the bits than the old programmers with their bithacking trickery. It is neat if you know how you can theoretically swap the content of 2 variables without a temporary - but with a normal tmp the compiler sees that it is only used for swapping and will just use an extra register which is a lot faster than an extra memory access.
I simply love how simple C is, it simply makes sense. I have seen so many horrible C++ github projects with tons of classes when you could do the same in less lines of code with a single class or a struct. I have also seen great C++ projects which amaze me. They are things I wouldn't be capable of do myself. But the projects far outnumber the good ones. I simply prefer the C way, the syntax is better in my opinion. EDIT: I still use python and other languages for things that require string manipulation and hash tables though
Wow I've always thought something similar too.I think its a bad idea to use every single feature in C++. Its tempting sure, but more often than not, theres always a simpler way to do it using just C. Hearing the same from an experienced dev is reassuring
Stroustrup's comment, "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off," is as true as ever. I've seen projects hamstrung by a pet idea whose consequences weren't entirely understood by its author. Sometimes the author lacks adequate understanding of the language feature, or object model feature, on which the idea depends. Motivation to learn on the job, whether it be for resume padding or to satisfy curiosity, is hard to resist, particularly if you don't expect to be around when the technical debt comes due. A concrete example of this is given at 1h22m04s, when a participant mentions misuse of smart pointers, which led to the rejection of C++ in that case. (I've seen misuse of smart pointers in C++ projects as well, for the same reasons, and with similar consequences.) Even the language contains ill-considered features, such as throw(), that were ill-considered and were eventually deprecated (C++17) and removed (C++20). That C is relatively simple and static, and thus less susceptible to unintended consequences, makes it an attractive to the risk-averse.
@@jmdavison62 A scalpel can do a lot of damage but If I require surgery, I don't want the surgeon using a blunt bread and butter knife. Never understould the mindset of protecting the programmer from the language.
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.
This is a really interesting point. I'm a C guy. I have tons of experience in OOP, and understand concepts like encapsulation and inheritance and what have you, I've seen it in practice, I've done it a lot in languages like C# and PHP, but I prefer procedural programming. I like to let data be data and actions be actions, and never to force them together. The more I've learned C, the more I've realized that's why I love it. But even so, strings were a big draw for me too... and "vectors" (dynamic arrays! Wait, no malloc & free?!)... and lists... and those other things like associative arrays in PHP or dictionaries in Python (key-value pairs, kind of like structs)... if it represented DATA, I was interested. And though my preference is still C (for totally unrelated reasons), I absolutely love how C++ makes it possible to have data types that work more like other languages.
@@miguel0n338 They are called hashtables and it should be a shame C does not even have generic dynamic arrays. Hashtables are incredibly useful and must be in every self respecting language. C is ancient and not enjoyable. But I'm still writing C, to write a compiler for a diferent language. Lol
@@miguel0n338 Don't C++ dynamic arrays also allocate memory on the heap? Also while using C I learnt that you don't need dynamic arrays nearly as much as you think. There are of course still necessary in tons of situations but I don't find it as painful to allocate && free memory on those cases. I haven't been using C for long so maybe that's why.
@@cynicist8114 Managing memory is tricky, but that's just another way of saying that it's best done *right*. You can leave solving the problem up to the language implementation, but that doesn't mean that the problem goes away. In fact, the language may introduce additional problems that are harder to solve than managing memory was. C++ is complex, for example. I find that it is very flexible in allowing the user to choose how to solve a problem, but it unfortunately obfuscates the tools to implement those solutions under a very unintuitive and non-orthogonal interface -- "barnacles", as Bjarne Stroustroup puts it. C's interface to memory management is a dumpster fire, and the only thing it does right is be small and understandable, as was mentioned in the talk, but that's not enough. Ultimately, the onus of memory management comes down to the designer of the program. It's an architectural problem, to be solved in one's own understanding of the data the system needs to do its job, and where it's going to come from. The code used to implement the system is just an accessory. C and C++ both get this right, but it's no wonder they're hated for so many for exactly the same thing. Memory management could not look uglier, yet it's their greatest feature compared to other languages.
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.
It is wrong mind... the whole "If you're arguing, you're losing" concept. He says it multiple times because it's the technique used to make information sink in, thus it's something you'll believe without evidence. Still when you enter into an Argument, it's better to keep in mind that "You will not convince the individual(s) you're arguing against but the Observers of said Argument." The reason for this is simple, when you're engaged in a conversation you're too close to properly see the entire Frame of the Discussion taking place as such you're realistically focused on a very narrow (and often self-interested) aspect of what is being discussed. Like viewing a large picture from a foot away. Others however are several steps back and see the precise parts that each individual in the argument are actually showcasing and thus it broadens their interpretation of the picture; assuming you've made an argument that sounds appealing to them. • C++ unfortunately is no longer strictly a superset of C and instead has branched into it's own linguistic sphere. This ends up a problem because this means that today you're EITHER working in C or C++ and this is how it is often framed as well. Yet, people see the value in something the more they SEE and EXPERIENCE the benefits as opposed to merely HEARING and READING about them. It's about the practicality of the situation, where if you want your team to switch over to C++... well use a C/C++ Language (like MSVC, which supports C > C++ > C.99), instead of teaching them or telling them why C++ is better. Rather what they'll see while working with the C++ programmer is how they approach a problem, they'll see the applicable benefits from their approaches and become curious. You've switched them from a Defensive Position to a position where now they actively seek Information and believe the idea to switch is their own (which technically speaking it was; but it wasn't without said external influence in that direction) The only other option is essentially brow-beating until information is unquestionable or you push good people out of teams due to incompatibility. While none of this is rocket science (as it were), it isn't immediately intuitive.
I'm a mostly self-taught C++ programmer, and I also have, I think, a C-style way of doing some things. Once I learned what new and delete were, I quit using malloc, but I still use C-style arrays way more than standard containers, just because often they're easier, and more fun.
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.
@@kenneth_romero EE means Electrical Engineering. A 4 - 6 degree in applied Electrodynamics. If I had a few more Intelligence Points I could of been one.
I have used C++ in a embedded domain only once in my entire 25-year career. Interestingly enough it was in the beginning of my career, back in 1994 in my native Brazil. The project was a bedside vital parameter monitor , the DX2010. Not only the GUI was written using C++ (it used the Zinc Applications Framework), but also the acquisition modules, based in the Intel 80186 micro-controller were written in C++.
I am looking at C++ again. The C++ 14 standard seems to address most of the concerns and there are many more guidelines on how to avoid unnecessary complexity.
That was pretty deep and introspective. I would add that a major issue is that particularly during the late 90s and 00s, C++ was inextricably linked to deep, unnecessary inheritance hierarchies, pointer spaghetti, hidden side effects, data structures based around a conceptual metaphor rather than actual usage, and the various other things that were considered “better” according to the prevailing understanding of Object Oriented Programming at the time. Over time these have become generally accepted as being almost as bad as not attempting to structure code at all. Sure, there was nothing in the language that forced people to write code in that way (and indeed C++98 was remarkably unsuitable for such things) but still, it’s fair to say that most of the people most vocally pushing C++ at the time probably had something resembling that in mind. It’s important to clearly express what one isn’t advocating, lest a straw man be built around you in other’s understanding.
Even worse than that was using C++ in the early to mid 90s. That turned me off from C++ and back to C until after Java 1.0 was released in Jan 96. People who don't understand why Java took off should learn the landscape of software dev and OSes and the Web in the mid-90s.
Simply putting the measured times would've been simpler but his approach hides unnecessary units and fractions by just showing a relative difference instead.
I just found myself cancelling rather than posting a comment on our internal bug tracker while muttering to myself, "If you're arguing, you're losing." Mr. Saks would be proud.
@@MatthewChaplain I decided years ago not to have arguments on the internet. Sometimes I fail, but it helps - life is less frustrating and just as or more productive.
The biggest problem with selling C++ to the embedded world is possibly that many of them are thinking in assembly but enjoy not having to write register management code themselves. In this case, they may be thinking more about "I know roughly what this code will do in assembly" than "I want to abstract over the lower-level algorithms [thus making them invisible] and give the compiler freedom to optimize them [thus giving up control]." Also, in the case of (e.g.) the airline industry, debug mode is probably going to be on in production because changing the binary requires redoing the cert process.
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.
Nice talk. I think it's especially important to emphasize as he did that C++ is based on C and you can convert slowly into idiomatic C++ without ever being forced into it. At one job I happily implemented C bindings for C++ library functions because I wanted them to be used in many existing C programs without actually forcing them to be rewritten gratuitously. C++ does not have to be some monstrous thing and it's totally fine to use C libraries.
41:06 okay you're right that we happily accept weak typing (because weak typing is flexible typing), but you're wrong about the mindset. A competent C programmer will do their due diligence in learning about undefined behavior, and taking care to read documentation so that they can properly use the functions and APIs provided. I've been writing C for almost a decade and my debugging sessions are short and far between because I know the pitfalls. I write unit tests and write my code in an agile, modular, data-oriented fashion. I compile with debug flags and strict warnings and sanity check my runtime against valgrind. The payoff is that I actually _don't_ spend a bunch of time debugging or hammering at code until it "manages to compile". I get it right the first time, and when there's warnings or errors, I read and address them before testing the program.
I would also appreciate if someone would stop censoring me. Somebody's deleting my comments and that's creating a very one-sided discussion. I'm not here to fight.
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.
I don't understand why having lots of options would be a reason to not use any of them. I just use the features I like or need. I've never used smart pointers. I've never used lambdas. I rarely use exceptions handling because the 30 year old code base was originally all C code and isn't set up for exceptions. I often mix C and C++ methodologies within the same code. I ignore the language lawyers. I'm a pragmatist.
I started programming in C in the early 80's. When the first commercial C++ compilers came out in the late 80's I was instantly hooked. I saw the potential for far fewer bugs but still having the speed. I learned on my own how to map a C++ class into C which meant there was no mystery to the new fangled world of C++. I've never understood why anyone would choose C over C++.
Because of truly horrible experiences with C++ compilers. (I still remember one project, fortunately not mine, where the companies involved had such bad experiences with C++ that they agreed to develop a new OO language of their own.) Because my old C code still compiles (with appropriate flags) but none of my old C++ code still compile. Because of an industrial project run by a famous person in the OO world that after several years of work and a truckload of money FAILED, whereas a much smaller team using a non-OO language succeeded in less than a year.
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.
Incredible talk!. I watched the whole thing. I would be completely on board with replacing C with C++ if it weren't for: 1. C is our only standard ABI. We need standard exception handling and a standard ABI, even if the compiler we are using supports compiling to a custom ABI for particular use cases 2. C compilers are much easier to implement than C++ ones, so they can be made available for a platform more easily. I guess this could be remedied by encouraging the use of clang++ as a front-end 3. C++ code compiles to a considerably bigger binary than C code, due to static initialization in the implementation of the object model. We need compiler options to generate small, light-weight binaries. On a different note, I also agree that modern c++ doesn't mandate the use of streams, vectors, and strings. We need to make it obvious that you can write minimal, basic ZCAs in C++ and still be writing good C++; that is, if you can't get the performance you want the things you find in the standard library, feel free to use C-style code that is necessary to get the job done.
3 is, at least, solveable. One of the previous C++ conferences had a video on just that subject. The bigger binary is largely due to the inclusion of iostreams in the binary. This can be removed.
I also moved from Java to C++, but because I was tired of things like JRE. It added a level of abstraction that made it difficult for me to peek at the hardware. I found myself wishing I was modifying the JRE, not the bytecode itself. C was out of the question for me coming from an OO language like Java, but C++ made a lot of sense.
Same. Whenever I try to start writing a C++ thing, I find myself spending more time browsing documentation than actually coding, and thinking "wow I could have done this using this fancy language feature" instead of actually working. Maybe I am letting perfectionism take over too much, or I am misunderstanding the language as a whole.
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.
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.
I've used C, C++ and Rust. I still enjoy and use C and Rust extensibly. But C++ is something I use very sparringly. My issue with the language is not really the losses vs gains, but how the language just keeps getting bigger, there's an aversion to deprecation and stuff keeps being slapped on top of it and the STL is a mess, unless you're a template ninja understanding it takes a lot of mental effort. That being said sometimes I'm writing something and the best library for it is in C++ or there will be too many allocations and stuff and I just want to use some C libraries and have C++ manage the memory for me.
I suppose there is a reason people do not like to use C++ and if I would have to guess, I would say mainly because the code does not look nice (or can be confusing -> I am thinking of operator overloading). From personal experience I can say that I like to think of programming as an enjoyable act of making art in a sense of creating a nicely structured, understandable and effective code. I kinda feel that C++ doesn't fill this need (at least for me). There is also just too much tricky details to know before you can be "good" C++ programmer. And even then, any "standard" programmer reading the code after you will probably have some hard time. For most of the projects I suppose these reasons just outweigh the possible performance gains.
TomQue0 Yes. Maybe in short: do not underestimate the fact hat C++ simply looks ugly. 😬 it’s very useful and often a reasonable thing to do but it’s not easy to learn it’s features even for people with other OOP background and it’s really ugly.
1) Hiding details is not primarily a concern of debugging but of certification. When certifying your code for medical or aviation you often have to trace the written code to the assembly. This is magnitudes more difficult in c++. 2) When writing bare metal code for a small microcontroller the amount of assembly and startup code and the resulting startup code size needed to initiate a working c environment is a fraction of getting a c++ environment up and running.
Could you point me to which regulations for medical devices require you to trace code to the assembly? I am not aware of that in medical nor automotive. Perhaps I misunderstood what you meant by "trace the written code". I am somewhat familiar with EU and USA regulations for different safety classes and I can't think of anything that matches. Code coverage kind of springs to mind but still II can't see how that would be different between C and C++. The comment is 3 years old but I still hope someone can shed some light on the matter here. Thanks.
The best way to make C programmers “see the light” is to develop something in C++ that is very widely used or very popular. Recently Jason Turner ported the Doom source code from C to C++ and the resulting binary was not only faster but also smaller. Imagine if someone developed an OS that is as good as Linux or Windows completely in C++. Or if some device driver developer starts beating all competitors by shipping C++ code that is not only faster to develop, but also more performant and safer. Odin Holmes as shown that this is possible.
that brings up a few questions. You said he ported Doom's C code to C++. What C standard was the C code and what standard was the C++ code? Also, did he change any internal code architectures or did he use the same architecture and patterns as the C code version? How was it determined that it was faster and smaller? What compilers were used and what versions?
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.
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
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.
A huge issue is that the vast majority of C++ programmers have an extremely poor understanding of assembly language. If you don't understand the core tool of your debugger then you're placing far, far too much blind faith in your compiler.
I’m OK with constructors and destructors but I hate caring about calloc/free which I absolutely need on the memory-limited platform I’m using to implement anything interactive and dynamic. But probably using vectors could solve most of difficulties with memory allocation. The only thing that bothers me is that I can’t do much hacking with objects which I didn’t mapped and allocated on my own, knowing exact continuity, size, location, etc etc etc. I’m I kind of a crazy guy treating arrays as pointers, mapping custom structures to register files, uniting different structures and operating pointers to functions.
What a great talk. The questions at the end fell apart a little bit, but I was surprised that the final question - off-topic as it was - turned out to be so informative. The "embedded course in a box" which Dan brought up looks incredibly useful (albeit expensive).
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.
1:17:00 C++ is more complex necessarily because its features are (almost) a superset of C’s features. However, as a C programmer, you already know most of the basics so that you’re in the “roam freely” domain of learning. You learn what interests you or serves your needs. You don’t need to know about the other stuff.
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.
I think C usage going up and C++ going down probably has more to do with the change in the readership of the magazine than anything else. Older people are more likely to be set in their ways, using C and subscribing to print magazines. Younger people probably use more C++, but they don't care about print magazines. As the magazine slowly dies, the old guard sticks around the longest.
To Rajendra - I think that applies to newbies more than to experienced C programmers. Newbies to programming will bounce off C++ hard if they'll be taught at the beginning of it as if it's C - with raw arrays, raw pointers, null-terminated strings, printf/scanf formatting codes, manual memory allocation, off-by-one errors all over the place, "voodoo" programming (slapping & or * at things to make pointers work), etc. There's a great talk about it at CppCon 2016 titled "Stop Teaching C" - which is of course about teaching C++ as if it's C. ;)
i did not really bounced off but i have to agree, it took me longt to get familliar with the strict concepts of several aspects, my first question about the most functions was "whats the main purpose for?" i had to get it by myself, and yes it makes it harder to go forward, becaus u have to build up a fundament of knowledge before u can even imagine those mainpurposes or even own ideas
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
It's interesting to look back on the state of the embedded world only 4 years ago. The rise of the Arduino platform has turned it upside down, since it's main programming language is C++ (albeit with some behind the scenes preprocessing). It's important because kids are growing up with Arduino and thus are being exposed to C++ without "knowing any better".
A strong argument IMO should be that sorting in C++ (with std::sort) is usually more than twice as fast as sorting in C (with qsort). Speed and efficiency should appeal to C programmers.
>I think C++ does have a place in embedded, but you'll have to use a completely different base library, one that doesn't rely on heap allocation or exceptions. Well, you can always roll out your own custom allocators that use placement new, though getting C programmers to do this would be nearly impossible. Unfortunately I really don't see how to put this sort of thing in a library though, because the question of where the placement new should place the newly allocated objects seems to me very dependent on the target environment. I have next to zero experience with embedded though, so if I'm talking out of my ass please correct me. ", at least more so than trying to shame people into using C++ by comparing C users to Republicans" Yeah the whole framing (heh) of the conversation was quite ridiculous. I'm not sure why I should listen to someone's thoughts about persuasion when most of their core argument is a haphazard combination of pseudoscience and actively trying to piss people off.
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.
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.
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
This makes me feel better about learning cpp as a first lang. I'm doing mostly embedded applications. The line graph shown is actually showing a shift TO CPP; a slow shift. Both languages are in flux right now, just waiting for a shift in either direction.
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.
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.
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??? 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
Excellent talk! Embedded systems is the one area where I had thought C was the superior solution. I am pleasantly surprised to see C++ performance even in this domain.
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.
Look at the paper by Bjarne Stroustrup called "Software Development for Infrastructure". You can find the PDF on his website. It's a little old but maybe a good place to start.
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.
C++ can be just as easy to debug - it is your choice how complicated you make your code. Same as C can be one horrible mess that you have nearly no hope of understanding, once you dive into the dark-ends with hundreds or thousands of lines of macros only. If you think C++ is too complex in that regards then it simply means it is a language not suited for you.
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.
For an outsider, this is hilarious. It sounds a little like Star Wars. These are our brothers taken by the dark energy C, we can bring them back, but we have to be careful that they don't fall deeper.
I don't think it's just the compiler problem. In C++ you can give more hints to a compiler through a type system, than you can in C. C compiler can't make as many assumptions as C++ one because of that, hence C generates usually less efficient code. The famous std::sort() which can be 2.5x faster than equivalent qsort() in C.
The problem with this guy's arguments is that he uses C++, written like C, to defend C++ usage. The fact of the matter is that actual C++ code (in practice) takes far longer to write, is tightly coupled, and is much more difficult to test and debug (especially memory usage). When you use the standard library, it screws up things like internationalization and the containers aren't suited for anything outside of the most basic of uses. Ultimately, what you find is that for every problem C++ sorta-solves, it tosses 3 more problems into your lap. Using C allows you to reason about your code. I can use static declarations for encapsulation and opaque structures for data hiding. I can use function pointers and tagged unions for polymorphism. Considering the fact that I would avoid using RAII, exceptions, and templates in C++ anyhow, C++ doesn't have a single feature that I don't already have. It just increases friction and makes me unproductive. I personally don't appreciate the 30min lecture trying to psychologically dissect and discredit any opinions of C++ being a bad choice as irrational.
No but he didn't show the C code in full. Be wary the guy is religious about C++. "university course who used C++ as C with classes" You mean structures with methods.
@LunacyStudy I would think you'd want to take advantage of templates if you are using polymorphism. Static interfaces are super powerful and efficient, and honestly provide better compile time checking than almost anything C has to offer. There are some risks associated with code size on embedded systems, but the speed and safety of templates are worth the extra effort needed to reduce the size. Runtime polymorphism using virtual functions usually leads to situations where I am on the phone with a customer or applications engineer trying to solve bugs after hours.
The problem i see with using C++ is that every microcontroller vendor i have used provides libraries in C and not C++ classes so i would have to rewrite thousands of lines of drivers just for the sake of getting "the same" performance, if thats the case its pointless. I would switch when performances is heaps and abounds better and not "the same" as C lol
Why I prefer C over C++: C++ isn't as portable or universal as C. If I want to use rust or whatever I would need to make a C header before I can make any rust bindings. It's especially bad if the header has templates or any sort of "modern" C++. C++ programmers act as if it's the centre of the universe, because C is popular and it supports C plus a lot of other features. If you don't want those features, they act as if I have any control in what is going to be used in a shared codebase. I don't, and once one of those problems caused by C++ starts to get in the way, it's too late. it fucked everything is touched and fixing it is as much work as rewriting it. It's technical debt++. There are features that I would really appreciate, but the presence of the unwanted catastrophic features are a deterrent. Nein danke.
As a career C programmer this talk is a complete nonsense. There are real practical reasons preventing the uptake of C++ in its present form but these are disappearing as processors gain more memory. The STL it pretty brilliant. Wish I could use Vectors and queues, let alone objects, but I can't. There is not enough RAM. IF you declare everything static you are going to immediately double the amount of typing for every single method or member. Yay, hold me back. This is just the C assembler argument from 2 decades ago. The HAL etc industry wide are written in C. The small O/S api's are C. The memory on most systems is pityful, everything has to be static. Every benefit you get form C++ is lost due to the shortage of RAM. Show us how. Build the STL to handle static data types. C programmers have short time to market. We need to put a physical thing in the customer's hand before the next guy. It's really really NOT what this Dsn is going on about. Bottom line: Arduino. Get it working there. There's your "IN" BTW: If you could be bothered to argue with an engineer, you probably don't believe what you're saying.
You may look at boost::static_vector. It basically has the same interface as std::vector but you limit its size statically. Similar thing could be done with strings and other containers
I don't think that's a good argument. You don't have to use dynamic memory allocation. It has nothing to do with c++. Where c++ really shows in embedded are other things like designing hard-to-use-wrong interfaces, constexpr and operator overloading. This even makes your code faster than c code
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.
While I agree in theory that C++ has a lot to bring to the embedded world, it is not clear to me that C++ is a valid alternative to C for embedded in practice. If one only has old non modern non compliant c++ compilers and toolchain, lack of libraries, why bother ? So before thinking about how to talk to C users, the C++ foundation/community may want to appraise the situation & see whether it is possible to get embedded compiler writers to provide a decent, modern c++ toolchain.
Silmarieni C, I think that’s the main reason why c++ is not so used in embedded programming. Most toolchains provided by microcontroller manufacturers don’t have good c++ support, so you use c, as it is what your tools support (even if the provided tools don’t usually provide fully compliant iso c libraries either)
Take this with a grain of salt, because I realize it's probably biased. But I do embedded C++ programming every day for my job. We are forced to consider the available compilers when we design the hardware (for better or worse). But I think it's just ultimately something that you/your team should be considering in embedded applications. Ultimately, what matters is that your system performs the way you've designed it, and the compiler is a larger variable in that equation than a lot of people like to admit.
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?
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.
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.
Maybe the trends could be explained by looking at what is currently called "embedded." If you are developing in Linux or Android, you may be doing the same kind of products, but might not call it embedded.
@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.
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.
" 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" Templates are there to make your life easier. Don't like them, don't use them. " or never needed rvalue references." Rvalue references are an optimization. Don't want them, don't use them. I fail to see how tying your hands behind your back and forbidding yourself from ever using rvalue references or templates helps you as a programmer.
"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" Wat.jpg
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++?
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.
Not sure that saying "C++ is better C" is enough to convince C programmers to make such a leap. It's not until you get into using pattern-based programming with C++11+ that it delivers real tangible benefits. I believe a lot of library writers think in terms of "write in C, can be used by C and C++". One example that particularly sticks in my mind is the protobuf C implementation, which uses an utterly vile nested macro arrangement to provide a tree (IIRC - may have been a map). In C++11 using trees and maps is a doddle. I believe that in about 5 years from now the C++ language and build systems such as CMake will have overcome most of the remaining idiosyncrasies they are still experiencing today.
Jonathan Cast for me. Learning C was much easier and it I felt like I got a good overview of the ideas of the language designer. In C++ and even after reading Biarne S. books I still think C++ is full of good ideas but it’s ugly, inconsistent and has lots of features no one can fully use in the way they were designed.
at 18:20: nope, they're not arguing that "using C++ for writing lightweight classes is not an appropriate use of the language". They are arguing that this is a microbenchmark, and not a big production system. And indeed, microbenchmarks often have very different results and outcomes than real-life scenarios, even if said big real-life project is composed of simple and small classes.
I would define it a bit more generically without mentioning 'memory' or 'size', something like this: an information pattern that provides a uniformal interface for performing a set of operations.
@@PutBoy This is not true. Types are all about what you see and what operations you can perform on what you see. Even in C/C++, which are low level "close to the metal" languages. For example they have an "int" type. That "int" type says nothing about how big an item is, could be 16, 32 or even 64 bits for example. That "int" type says nothing about how an integer is represented in memory. Could be two's complement, could be sign-magnitude, or anything else. For this reason neither C or C++ specify what happens when an addition of ints overflows. Moving up a notch, in Rust the types not only define operations, they encode when you are allowed to perform those operations. Types have lifetimes. Further up Javascript has "numbers", you have no way to see how they are stored. Could be as 64 bit floating point could be 32 bit integer, as the run-time sees fit. Or what about integers in Python? Which can be of arbitrary size ?
C++ might be faster (in some cases), but it's too complex to even try to bother getting that out of it. On the other hand C is simple, you don't have to worry about the language, only about coding right.
Different problems need different solutions and thus different languages. You won't use Python where you need C. So another problem preventing C++ to get in to the embedded world is that most C++ programmers are very bad C and Assembly programmers and thus they can't implement a good solution or even effectively debug a problem.
It is common to write C extensions to Python in domain that require performance. You have TensorFlow that is basically C++ lib but with Python API that is most commonly used. C++ is both too much and too little. It is too much because there is plenty of features that you would need to avoid if you want to have performance comparable to C. You would you need to be expert C++ programmer to know with things and when you can use. In the same time it is too little, it is not much better than C in terms of module system, standard library or portability.
The same applies in the other direction - most C programmers don't know how to program in C++, so they end up with C code compiled with C++ compiler. With a couple of classes perhaps.
