C++20 Is Feature Complete; Here’s What Changes Are Coming

If you have an opinion about C++, chances are you either love it for its extensiveness and versatility, or you hate it for its bloated complexity and would rather stick to alternative languages on both sides of the spectrum. Either way, here’s your chance to form a new opinion about the language. The C++ standard committee has recently gathered to work on finalizing the language standard’s newest revision, C++20, deciding on all the new features that will come to C++’s next major release.

After C++17, this will be the sixth revision of the C++ standard, and the language has come a long way from its “being a superset of C” times. Frankly, when it comes to loving or hating the language, I haven’t fully made up my own mind about it yet. My biggest issue with it is that “programming in C++” can just mean so many different things nowadays, from a trivial “C with classes” style to writing code that will make Perl look like prose. C++ has become such a feature-rich and downright overwhelming language over all these years, and with all the additions coming with C++20, things won’t get easier. Although, they also won’t get harder. Well, at least not necessarily. I guess? Well, it’s complex, but that’s simply the nature of the language.

Anyway, the list of new features is long, combining all the specification proposals is even longer, and each and every one of these additions could fill its own, full-blown article. But to get a rough idea about what’s going to come to C++ next year, let’s have a condensed look at some of these major new features, changes, and additions that will await us in C++20. From better type checking and compiler errors messages to Python-like string handling and plans to replace the #include system, there’s a lot at play here!

Continue reading “C++20 Is Feature Complete; Here’s What Changes Are Coming”

Drifting Instrument Presents Opportunity To Learn About Crystal Oscillators

Sure, we all love fixing stuff, but there’s often a fine line between something that’s worth repairing and something that’s cheaper in the long run to just replace. That line gets blurred, though, when there’s something to be learned from a repair.

This wonky temperature-compensated crystal oscillator is a good example of leaning toward repair just for the opportunity to peek inside. [Kerry Wong] identified it as the problem behind a programmable frequency counter reading significantly low. A TCXO is supposed to output a fixed frequency signal that stays stable over a range of temperatures by using a temperature sensor to adjust a voltage-controlled oscillator that corrects for the crystal’s natural tendency to vary its frequency as it gets hotter or colder. But this TCXO was pretty old, and even the trimmer capacitor provided was no longer enough to nudge it back in range. [Kerry] did some Dremel surgery on the case and came to the conclusion that adding another trim cap between one of the crystal’s leads and ground would help. This gave him a much wider adjustment range and let him zero in on the correct 10-MHz setting. [Mr. Murphy] still runs the show, though – after he got the TCXO buttoned up with the new trimmer inaccessible, he found that the frequency was not quite right. But going from 2 kHz off to only 2 Hz is still pretty good.

Whether it’s the weird world of microwave electronics or building a whole-house battery bank, it’s always fun to watch [Kerry]’s videos, and we usually end up learning a thing or two.

Continue reading “Drifting Instrument Presents Opportunity To Learn About Crystal Oscillators”

Specifications You Should Read: The NASA Workmanship Standards

"This is reflective of the typically idiosyncratic way engineer's of this era explored the human condition. The purple and shitty gradient show's the artists deep struggle with deadlines and his personal philosophy on the tyranny of the bourgeois. " - A segment from a confused student's art history paper
“Reflective of the typically idiosyncratic way engineers of this era explored the human condition. The shitty gradient show’s the deep struggle with deadlines and their personal philosophy on the tyranny of the bourgeois. ” – An excerpt from a confused student’s art history paper after the standard is installed in the Louvre.

The NASA workmanship standards are absolutely beautiful. I mean that in the fullest extent of the word. If I had any say in the art that goes up in the Louvre, I’d put them up right beside Mona. They’re a model of what a standard should be. A clear instruction for construction, design, and inspection all at once. They’re written in clear language and contain all the vernacular one needs to interpret them. They’re unassuming. The illustrations are perfectly communicative.  It’s a monument to the engineer’s art.

Around five years ago I had a problem to solve. Every time a device went into the field happily transmitting magic through its myriad connectors, it would inevitably come back red tagged, dusty, and sad. It needed to stop. I dutifully traced the problem to a connector, and I found the problem. A previous engineer had informed everyone that it was perfectly okay to solder a connector after crimping. This instruction was added because, previously, the crimps were performed with a regular pair of needle nose pliers and they came undone… a lot. Needless to say, the solder also interfered with their reliable operation, though less obviously. Stress failures and intermittent contact was common.

Continue reading “Specifications You Should Read: The NASA Workmanship Standards”

Toyota’s Code Didn’t Meet Standards And Might Have Led To Death

We were initially skeptical of this article by [Aleksey Statsenko] as it read a bit conspiratorially. However, he proved the rule by citing his sources and we could easily check for ourselves and reach our own conclusions. There were fatal crashes in Toyota cars due to a sudden unexpected acceleration. The court thought that the code might be to blame, two engineers spent a long time looking at the code, and it did not meet common industry standards. Past that there’s not a definite public conclusion.

[Aleksey] has a tendency to imply that normal legal proceedings and recalls for design defects are a sign of a sinister and collaborative darker undercurrent in the world. However, this article does shine a light on an actual dark undercurrent. More and more things rely on software than ever before. Now, especially for safety critical code, there are some standards. NASA has one and in the pertinent case of cars, there is the Motor Industry Software Reliability Association C Standard (MISRA C). Are these standards any good? Are they realistic? If they are, can they even be met?

When two engineers sat down, rather dramatically in a secret hotel room, they looked through Toyota’s code and found that it didn’t even come close to meeting these standards. Toyota insisted that it met their internal standards, and further that the incidents were to be blamed on user error, not the car.

So the questions remain. If they didn’t meet the standard why didn’t Toyota get VW’d out of the market? Adherence to the MIRSA C standard entirely voluntary, but should common rules to ensure code quality be made mandatory? Is it a sign that people still don’t take software seriously? What does the future look like? Either way, browsing through [Aleksey]’s article and sources puts a fresh and very real perspective on the problem. When it’s NASA’s bajillion dollar firework exploding a satellite it’s one thing, when it’s a car any of us can own it becomes very real.