▲ 49 points
back
28 comments
It is very interesting because directly states that for C++ to be as efficient you need to have the optimizer on. Now for most scenarios that makes perfect sense but for aerospace we need to be able to match the code directly between the assembly and C code. Without this it is incredibly difficult to do full verification.
That’s true but for the most part such optimisations happen very predictably (and are extensively verified when applicable). This isn’t a case of writing some very abstract code and hoping that the compiler will sort it. Rather, you use abstractions that have been carefully designed and implemented (probably by you) to result in predictable machine code (another comment links to a good example of this by James Turner; the key here is that this example is obviously chosen for illustration purposes, but can be generalised). C++ does not relieve you of the responsibility to understand the abstractions you’re using, but it does make it possible to write such abstractions; for example, writing an iterator over a complex container type that, when used with a range-for loop, compiles down to a single inc/cmp/jne (this is in fact what a range-for loop over a `std::vector` does).
Optimisations in C++ (those that are relevant here, anyway) are something that need to be relied on to write efficient code, but they also can be relied on.
>Without this it is incredibly difficult to do full verification.
You can verify the optimizations on their own. Example: https://www.cs.utah.edu/~regehr/papers/pldi15.pdf
In the framework of safety-critical software correctness of the compiler is a prerequisite, but not seen as sufficient to prove the correctness of the actual translation.
Why?
Because the compiler is only correct if its execution environment is also correct. This cannot be guaranteed.
And also because the relevant standards say so.
Can you point me to these standards?
I do research in this field and it would be helpful to refer to such standards in papers.
For traceability you would need to look at Do-178C. I am currently not aware that ISO 61508 (general functional safety) and ISO 26262 (automotive functional safety) require traceability between source code and executable machine code.
All standards specify different levels of safety. Lower levels come with fewer requirements and are easier to implement, but are recognized as less reliable and therefore limited to less critical applications.
Around the 30 minute-mark, I noticed some weird syntax that I've never seen before. I dabble in C++ at my job, so I'm not a total newbie. But what do those braces mean on 'weekday'? Is that some kind of class constructor or something?
Code in question was:
cout << weekday{October/19/2017} << '\n';It's an example of uniform initialization syntax that was brought into the language in C++11. It simplifies some things (no narrowing conversions allowed) but also complicates things (if any constructor takes in an initialize-list, it gets priority). In this case, the code is constructing an object of type weekday from an expression that represents that particular date.
It's "aggregate initialization" [0]
struct S {
int x;
struct Foo {
int i;
int j;
int a[3];
} b;
};
S s1 = { 1, { 2, 3, {4, 5, 6} } };
I don't think that is what is going on, this is invoking the constructor for the weekday class with the "modern" uniform initilization syntax. This solves the old C++ most vexing parse problem.
https://en.wikipedia.org/wiki/Most_vexing_parse
It seems like this is the C++ class in question: https://howardhinnant.github.io/date/iso_week.html
When many of these low power chips have less than 64K of RAM, C++ is a terrible mistake. Once the program reaches even a modest level of complexity, expect blown stacks left and right.
I have had to clean-up so many of these things! And the guy who insisted on using C++ in the first place is always like, "I'll just change the compiler flags, and then it'll be OK." And that never fixes it.
If we are speaking about something like a PIC with 8 KB I agree, for anything else comparable with a C64 or better, it is quite doable.
CppCon 2016: Jason Turner “Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17”
Turner obviously understands his tools, and exercised a lot of discipline with them to write pong within a resource budget.
The systems that I have encountered professionally have been uniformly more complicated, and written with less discipline, than Jason Turner's pong.
And that is not to say that the people who wrote the original programs were bad programmers. In business, you're trying to beat the other companies to the finish line, so a lot of siegeworks engineering happens out of necessity. Turner had the luxury of taking his time.
The point of a language like C++ is to build the abstractions that make it possible to quickly deploy something efficient and robust. Yes, that takes some time up front, but so does designing a board!
The abstractions are not free. The cost is negligible when working with megabytes. The cost is immense when working with kilobytes.
If you're doing something more complicated than toggling LEDs with one of these low-energy chips, C++ is a false economy--rapid progress in the beginning, and a slog of memory budgeting in the end.
Believe me I am used to programming machines with a KB of RAM, or even less, and small amounts of bank-switched program memory. I've been a compiler and RTOS developer, and have worked on telecom, avionics, automotive control, power generation, and instrumentation.
Certainly the abstractions can be free (at runtime -- may require the compiler to do hard work, but that's what it's for). A struct that allocates some of its instance variables into memory-mapped IO space and the other ones in regular ram can reduce errors that appear from splitting representations and/or doing explicit pointer arithmetic.
Can people write shitty code? Of course they can. Can you use your tools to reduce the chance that that will happen? Sure, sometimes.
Let's be realistic: while some of the very best programmers I've worked on have developed high-performance embedded systems, those are very few and far between. Most people writing embedded code have low status (this is the case in Japan and China in particular) so are often not the best developers, or are hardware engineers who figure writing some code isn't all that hard (isn't necessarily, but often leads to spaghetti) or are non-embedded programmers who figure "how hard can this be?" Another commenter's reference to hearing, "well it works when the optimizer is on" is a symptom of this.
Sure, people who fling around the STL on a small resource machine will rapidly suffer. But those people will fail regardless. I have built code that takes up less space with a C++ compiler than the C version.
Yes, yes. Since you are so experienced, and everyone else is "low status," riddle me this:
If C++ is so great, why does every joint turning out even halfway decent C++ have to subset the bejesus out of it? Even in game dev, where resources are plenty, they still subset it.
Could it be that maybe, maybe, someone discovered that even competent devs do better work when a few pieces of duct tape are stuck over the sharper, rustier edges of C++.
On low RAM devices, I'd subset it all the way down to plain C. Fellow low status developer Linus Torvalds would do that at the outset for any device.
It sounds like you have more of a problem with poorly written code than C++. The motto of C++ is to not pay for what you don't use. The rub is using abstractions doesn't absolve you of efficiency and design constraints.
I'm currently writing a hobby project in c++ for esp8266. I'm using about 35% DATA and 40% PROGRAM according to the compiler... seems to be ok so far (though my application does not need to allocate arbitrary memory right now, almost all is determined by initialisation).
On the other hand I'm trying to export some data at work from a web app... Firefox grows to 8.9GB ram usage then reports "uncaught exception: out of memory" :(
I used C for my last ESP8266 project, which seemed mostly okay. It did involve a fair amount of HTTP request/response and parsing, where I was just careful to do things incrementally. I don't think I ever considered C++ for the project. (The most annoying thing was probably the large number of callbacks I had to track state across for anything involving a TCP socket.)
For my current project, I moved onto the ESP32, where I'm also sticking with C. On this project, there's a lot less network code. Now the annoying part is the lack of built-in data structures in C. I'm making up for it with the uthash project, but I really wish it wasn't something where every project had to "roll their own" (or pull in some macro library, none of which seem to be "the standard everyone uses")
C++ would definitely make the code look a lot prettier, even if only for the sake of organization. I still just hesitate, because I'd then be tempted to wrap all the C framework APIs in C++ classes which would only add to the bloat.