Date: Wed, 3 Jun 2026 00:40:05 +0100
On 02/06/2026 08:03, Tiago Freire via Std-Proposals wrote:
>
>
>> Alternately, "hard real-time" is defined as a situation where a response is required within some number of milliseconds or machinery will be ruined or lives lost. And there is no tolerance of intermittently missing the deadline. In that case I might want to have multiple identical processes "locked" to multiple cores that are never shared. Each process tries to perform the same calculations. And then have a very simple arbitration system in place that can compare results for being identical and can handle if one process dies due to malfunction. That way I can reject the kind of mistake that could cause an industrial accident without causing delays.
>
>
>
>
>
> Things that are operating at that level of risk are usually small by design, almost certainly not multi-threaded, and they won’t be complex enough to be able to run 2 different processes that cross-check each other, there’s probably not even going to have a discernable OS there capable of ejecting your application. Now it is very normal to have 2 distinct devices to do that job, but it’s for very different reasons. If 2 redundant devices do the same computation and are supposed to arrive at the same result, if there is a software issue where 1 of them fails, then you should not be surprised that both of them are expected to fail (because they are doing the same thing).
>
Ideally separate manufactures of each distinct device (and ideally not using the same CPU core...)
>
> Likely what happens in those devices when a critical error occurs is that it keeps running regardless because stopping is worse, it may go into a failure mode, it may try to reset things and recover from the error while trying to keep whatever device it is controlling in a safe state as best as possible, maybe it has to trigger an alarm and request human intervention right now, but it can never stop.
>
>
>
> You can’t just say “I’m merely confident that this part can’t go wrong, but if it does we just assert it and catch it in development”, because the consequence of the code failing is people die. You can’t just “assert”, if there is one then that’s proof that your code isn’t safe. You put it there because you know bad things could happen if it were in that state but you can’t prove it can’t be in that state, and if it is in that state and you just assert it shows that you didn’t plan for that problem and just gave up. When a plane is 35K feet in the air, there won’t be a developer there to debug it and fix it.
>
> If it could go wrong, then plan for it, something must happen if it does go wrong, and that can’t be “I just gave up”.
>
> That’s why C++ is generally viewed as even more dangerous than C in safety critical application, because failing constructors/destructors don’t have good return paths to handle errors, and this is a feature of the language that you can’t fix, not to mention the amount of hidden consequences and UB that each operation can have.
>
>
>
> If you want more safety in C++ then you should go in the direction of “std::inplace_vector::try_push_back”, because there’s no UB and it acknowledges that it can fail and gives you the opportunity to handle that failure gracefully, “std::inplace_vector::assert_push_back” just kills people.
std::inplace_vector::try_push_back() requires programmer to check for nullptr failure case, which might be missed.
The alternative is to check there is space before push_back(), and compile_assert() to check it does, that guarantees functional safety.
Regards, Jonathan
>
>
>
>
>
>
>
> *From:*Std-Proposals <std-proposals-bounces_at_[hidden]> *On Behalf Of *Adrian Johnston via Std-Proposals
> *Sent:* Tuesday, June 2, 2026 04:12
> *To:* Jonathan Grant <jgrantonline_at_[hidden]>
> *Cc:* Adrian Johnston <ajohnston4536_at_[hidden]>; std-proposals_at_[hidden]
> *Subject:* Re: [std-proposals] What a non-reallocating version of the standard would look like.
>
>
>
> Sorry guys.
>
>
> />> What way would you handle an issue identified by library hardening?/
>
>
>
> There are a lot of contexts:
>
>
>
> In finance I would not want to submit a stock trade or other financial transaction. In that case I might want to restart the program.
>
>
>
> Alternately, "hard real-time" is defined as a situation where a response is required within some number of milliseconds or machinery will be ruined or lives lost. And there is no tolerance of intermittently missing the deadline. In that case I might want to have multiple identical processes "locked" to multiple cores that are never shared. Each process tries to perform the same calculations. And then have a very simple arbitration system in place that can compare results for being identical and can handle if one process dies due to malfunction. That way I can reject the kind of mistake that could cause an industrial accident without causing delays.
>
>
>
> On a desktop app I might want to try to save my current state and restart. There is a list of text editors that keep their current state mapped to disk with mmap() and can recover from a crash by mapping their working memory right back in again after a restart.
>
>
>
>
>
>
>
>
>> Alternately, "hard real-time" is defined as a situation where a response is required within some number of milliseconds or machinery will be ruined or lives lost. And there is no tolerance of intermittently missing the deadline. In that case I might want to have multiple identical processes "locked" to multiple cores that are never shared. Each process tries to perform the same calculations. And then have a very simple arbitration system in place that can compare results for being identical and can handle if one process dies due to malfunction. That way I can reject the kind of mistake that could cause an industrial accident without causing delays.
>
>
>
>
>
> Things that are operating at that level of risk are usually small by design, almost certainly not multi-threaded, and they won’t be complex enough to be able to run 2 different processes that cross-check each other, there’s probably not even going to have a discernable OS there capable of ejecting your application. Now it is very normal to have 2 distinct devices to do that job, but it’s for very different reasons. If 2 redundant devices do the same computation and are supposed to arrive at the same result, if there is a software issue where 1 of them fails, then you should not be surprised that both of them are expected to fail (because they are doing the same thing).
>
Ideally separate manufactures of each distinct device (and ideally not using the same CPU core...)
>
> Likely what happens in those devices when a critical error occurs is that it keeps running regardless because stopping is worse, it may go into a failure mode, it may try to reset things and recover from the error while trying to keep whatever device it is controlling in a safe state as best as possible, maybe it has to trigger an alarm and request human intervention right now, but it can never stop.
>
>
>
> You can’t just say “I’m merely confident that this part can’t go wrong, but if it does we just assert it and catch it in development”, because the consequence of the code failing is people die. You can’t just “assert”, if there is one then that’s proof that your code isn’t safe. You put it there because you know bad things could happen if it were in that state but you can’t prove it can’t be in that state, and if it is in that state and you just assert it shows that you didn’t plan for that problem and just gave up. When a plane is 35K feet in the air, there won’t be a developer there to debug it and fix it.
>
> If it could go wrong, then plan for it, something must happen if it does go wrong, and that can’t be “I just gave up”.
>
> That’s why C++ is generally viewed as even more dangerous than C in safety critical application, because failing constructors/destructors don’t have good return paths to handle errors, and this is a feature of the language that you can’t fix, not to mention the amount of hidden consequences and UB that each operation can have.
>
>
>
> If you want more safety in C++ then you should go in the direction of “std::inplace_vector::try_push_back”, because there’s no UB and it acknowledges that it can fail and gives you the opportunity to handle that failure gracefully, “std::inplace_vector::assert_push_back” just kills people.
std::inplace_vector::try_push_back() requires programmer to check for nullptr failure case, which might be missed.
The alternative is to check there is space before push_back(), and compile_assert() to check it does, that guarantees functional safety.
Regards, Jonathan
>
>
>
>
>
>
>
> *From:*Std-Proposals <std-proposals-bounces_at_[hidden]> *On Behalf Of *Adrian Johnston via Std-Proposals
> *Sent:* Tuesday, June 2, 2026 04:12
> *To:* Jonathan Grant <jgrantonline_at_[hidden]>
> *Cc:* Adrian Johnston <ajohnston4536_at_[hidden]>; std-proposals_at_[hidden]
> *Subject:* Re: [std-proposals] What a non-reallocating version of the standard would look like.
>
>
>
> Sorry guys.
>
>
> />> What way would you handle an issue identified by library hardening?/
>
>
>
> There are a lot of contexts:
>
>
>
> In finance I would not want to submit a stock trade or other financial transaction. In that case I might want to restart the program.
>
>
>
> Alternately, "hard real-time" is defined as a situation where a response is required within some number of milliseconds or machinery will be ruined or lives lost. And there is no tolerance of intermittently missing the deadline. In that case I might want to have multiple identical processes "locked" to multiple cores that are never shared. Each process tries to perform the same calculations. And then have a very simple arbitration system in place that can compare results for being identical and can handle if one process dies due to malfunction. That way I can reject the kind of mistake that could cause an industrial accident without causing delays.
>
>
>
> On a desktop app I might want to try to save my current state and restart. There is a list of text editors that keep their current state mapped to disk with mmap() and can recover from a crash by mapping their working memory right back in again after a restart.
>
>
>
>
>
>
Received on 2026-06-02 23:40:09