IMO there's not much reason to use vanilla C in 2k17 on anything but the smallest embedded projects, or where it's required for comparability reasons, or maybe when writing device drivers or some kind of kernel module, other than comfort/inertia. You lose a lot and don't gain very much in return.
What do you lose? Abstraction?
Most of our products are bare-metal ARM, often without DRAM. Realtime matters, so we don't want garbage collectors or mysterious library routines suspending our code randomly, and we don't want to run out of RAM... hence static allocation. If we're running something 200K times per second, we want every shot to run in guaranteed below 4 us.
Fortunately, my embedded programming guy dislikes abstraction almost as much as I do.
We do have a few Linux products that run on ZYNQ dual-core ARMs. We did some testing to see how much a tight loop might be suspended by the OS. Some functions that could have been software had to be done in the FPGA fabric.
-- John Larkin Highland Technology, Inc lunatic fringe electronics
Dropbox can be annoying. They change (break) things with the excuse that they are improving the user experience. I guess they learned that from Microsoft.
-- John Larkin Highland Technology, Inc lunatic fringe electronics
The usual FUD. C++ isn't in any way bloated or slow intrinsically. There isn't anything anywhere that says compile-time abstraction or OOP must lead to those consequences. The developers claim "Zero Overhead Abstraction" and the language more or less lives up to that promise.
Of course the actual bytecode has nothing to do with objects and is sequential, the question is why you think modern compilers are too stupid to take the abstraction you see in your IDE and smoosh that down into functionally equivalent asm that doesn't have any knowledge of abstraction or objects whatsoever, just produces equivalent output.
There are all sorts of convoluted abstract ways to write a recursive factorial function using fancy objects, but if the compiler notices that at the end of the day the only thing all that stuff is used for is to generate one output from an input known at compile time, it just compiles to a single load immediate of the required value.
Right, because the one systems programming task that it probably wouldn't be a good fit for is writing a kernel.
Also Linus is an old fuddy-duddy who dislikes C++ a lot for personal reasons rooted deep in the past. As if by virtue of only using C the Linux kernel has not historically also been riddled with bugs, some of which have taken years or decades to fix.
How come? Naive linked lists are like the bubble-sort of data structures. Awful insertion time compared to even a simple array using "shove-right-to-make-room" algorithm for data sizes much bigger than 50
Yes, abstraction is a big one. Modern compilers are so good that an enormous amount of SLOC often squashes down to a remarkably small amount of bytecode. ~1k SLOC for the thing I did that started the thread used only around 5.5 kB of Flash on an ATMega328; probably room for ten times as much compiled source depending on what you were doing. Ever tried to organize a straight C project consisting of 10 or 20 thousand lines of code?
It's fine for an embedded guy to dislike abstraction, but for any large project it would be important to make sure that he was the only person managing the project, forever. If the claim is that he's so 'leet that he writes large projects perfectly the first time and the codebase never would need to be revisited by someone ever again because it was perfect by design, well...
Since "that" happened a long time ago, the details have been expunged from my mind - only the lesson remains.
It wasn't an issue with the bog-standard libraries that are part of every distribution, rather several libraries from disparate sources. Hence the details would only generate heat, not light.
The key is, of course, to get the level of the abstractions right, and not to hide things that need to be visible.
Hence it is often valuable to raise the level of the abstraction in the code/design so that it matches the abstractions in the specification.
Hence where timing needs to be tight for correct operation, that should be exposed and visible. That's one reason I like the XMOS xCORE devices: the IDE examines the binaries' flow-graph so it can tell you exactly how many cycles the code will take to run.
It is certainly true that code isn't bloated /because/ of C++. People manage to create bloatware in any language :(
However, the C++ language itself is bloated and un-understandable and therefore annoying and dangerous.
Evidence: the C++ language /designers/ refused to conceive (let alone admit) one "entertaining" consequence of their proposals - until someone publicly rubbed their noses in it. Yes, Virginia, with a well-formed C++ program you can cause the /compiler/ to endlessly spit out the sequence of prime numbers during compilation.
Evidence: the C++ FQA, which really shouldn't be "necessary".
By way of example I looked through some of the .asm source of some of the projects Jan has listed on his page. I'm sure they work fine but I don't really understand the point of GPL-ing the source; the chances that anyone other than the author needing say a quadcopter control routine would either make use of or modify it I rank as pretty close to zero. By the time anyone understood it well enough to modify they could've probably written their own or found some other implementation more easy to do so, and if they're using anything other than a Microchip device they're out of luck.
Inline asm is great and I use it all the time, but there's no virtue in making an entire application "efficient." Most realtime applications spend about 90% of their time executing one lil section of code and pay visits to all the other sections of the codebase the equivalent of once a year.
One person's "bloated and un-understandable" is another person's "expressive, powerful, and flexible."
Not perfect by any means, sure. Sounds a lot like the argument is "Walking a tightrope with a net tends to makes you careless; better to remove the net entirely and just be really really careful as you do so." Errrm, I'm not really sold.
PS: somewhere around now in this game of "Yes, but..." someone is supposed to show up to be the "synthesis" mediator who says something in the vein of "I guess it depends on what you value and what your requirements are." Where are you, guy?
NO!
We use things called "design notes" and "comments" to remember what we did, and why. Hardware and software.
-- John Larkin Highland Technology, Inc lunatic fringe electronics
All of which sound to me like playing with the tools and not coding the application.
-- John Larkin Highland Technology, Inc lunatic fringe electronics
Lucky you! If you just need a blazing bare-metal processor to blast some ADC signal through a FFT as-fast-as-possible and move it out it makes life a bit easier, because DSP code usually ain't too many lines!
True, but in the case mentioned, even the expert *designers* didn't understand what they had wrought.
What chance have mere mortal users?
At the very least it smacks of building castles on sand.
The problem for C++, uniquely amongst languages, is that not only do users shoot themselves in the foot, but the *designers* shoot themselves in the foot. That's a big red flag.
Some of us have to live in a world where the customer is allowed to call up X months into the development process and say "Hey, you know that thing you did with the thing? Actually we saw how it looked with the thing, and decided we'd like this function to be removed, and this section to do something different, and maybe use a 4 line display instead of 2, and..."
Working with all that abstract/generic stuff can mean the difference between that being fairly straightforward and having to rewrite the whole application from scratch. In my experience if one can't offer some amount of RAD development hotness vs. rigid specs and "waterfall" a client won't take the onus upon themselves to get more certain, they'll just find someone who can.
Wish you'd be more specific as to what situations these are (aside from obscure compiler bugs unlikely to appear in real code) and what alternative solutions are more appropriate for embedded systems. So....just use C? Plain C is an ad-hoc mess!
In exchange for doing everything in an ad-hoc inflexible way it offers the _illusion_ that you're giving up all that for its simplicity, "reliability" and super-duper asm-like performance in every use-case. I tell ya it's not being honest with you...
We have considered DSPs (and soft cores) but the combination of an ARM or two, with a lot of FPGA fabric, has worked so far.
-- John Larkin Highland Technology, Inc lunatic fringe electronics
A very simple primitive pre-emptive kernel helps a lot organizing large projects..
If they were compiler "bugs", I would agree - but the issues mentioned are *designed* into the *language* itself. That's simply ridiculous.
The compiler-emitting-prime-numbers is a consequence of the specific template language features.
The points in the FQA only discuss the language, not compilers.
But those mis-features do indeed lead to subtle bugs embedded in applications. Unfortunately the manifestation of subtle bugs depends on compiler, compiler version, and compiler flags.
That's why many embedded projects subset the language and mandate a specific compiler version. That's remarkably brittle.
That's a separate question, and not easy to answer.
I have preferences which avoid some of the subtle technical nasties, but which introduce different (non-technical) problems.
Yes, and due to their co-development, C++ is also an ad-hoc mess.
Agreed.
Doubly so with C++.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.