> And hopefully you had a test suite that proved the maximums could be handled gracefully. It scares me a little that C was considered safer for avionics, but it makes an interesting point.

That is considered an upgrade from FORTRAN, aviation is conservative, airplanes are still running a lot of software originally written in the 80's.
Suggesting to re-write software that has been running for decades without issue in a "modern language", incurring the risk of introducing critical bugs in the process, spend millions having to re-audit, re-test, and re-certify isn't exactly winning you a promotion around the office.
But that's not the point, the point is the practices that have been adopted around the need to ensure safety. And the practice of baking in all your limitations upfront helps ensure you don't violate those limitations.

> What we used to do was use the std library for building memory images that would be loaded into the runtime. If you are running command line tools then you can replace global new and delete with a simple stack allocator that only increments a pointer and doesn't ever reclaim memory. Then the process just exits and that is how resources are reclaimed. This saves you 30% CPU.

But then how do you prove that you can't blow up the stack?
I'm not saying that these practices were used universally everywhere, it is something I noticed and they seem the reasonable approach for the domain.
And that of course will color my perception of what would be considered a "safe alternative" to the standard constructs. I.e. not custom stack allocators, it's the ability to use no allocators at all.

________________________________
From: ajohnston54637_at_[hidden] <ajohnston54637_at_[hidden]> on behalf of Adrian Johnston <ajohnston4536_at_[hidden]>
Sent: Saturday, May 30, 2026 11:04:04 PM
To: Tiago Freire <tmiguelf_at_[hidden]>
Cc: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Subject: Re: [std-proposals] What a non-reallocating version of the standard would look like.


>> Let's say you had to track a dynamic set of other entities (clouds, aircraft, navigation stations) you had to
>> decide how many of those you could track at maximum at any given time and if the maximum is reached
>> then only keep the most relevant and it wouldn't be able to track more;

And hopefully you had a test suite that proved the maximums could be handled gracefully. It scares me a little that C was considered safer for avionics, but it makes an interesting point.

>> If you need to use C++, if that was ever a practice (instead of the current just use C), a large chunk of
>> the std library would be straight out off limits to use.

What we used to do was use the std library for building memory images that would be loaded into the runtime. If you are running command line tools then you can replace global new and delete with a simple stack allocator that only increments a pointer and doesn't ever reclaim memory. Then the process just exits and that is how resources are reclaimed. This saves you 30% CPU.

And then we were not allowed to use the std library at runtime. All you really need is an array class. Once you start really optimizing it is all Structures of Arrays (SoA) and Arrays of Structures (AoS) because you are doing hot and cold sorting for cache coherency. But it is nice having a real container library for large embedded projects.