>
> Maybe, maybe not. In small embedded systems, you usually have a much
> clearer idea of what errors can occur - and what errors cannot. And you
> frequently have very limited options for dealing with errors - just
> silently dropping any overflow characters can be a perfectly good strategy.
>

Not to digress too far from the topic, but absolutely. Then there's dealing
with stateful controllers...
On the topic of Arduinos (a Due in this case): A big problem I ran into was
making a 1m stretch of shielded SPI connection "stable", which essentially
meant a complete reset of the controller whenever a CRC check failed. There
was room for QoS overhead and a master-slave reset handshake, and it
worked, but this reset happened quite a lot so it was replaced with CAN.
The lesson: A Due does not make a good SPI slave.

On Mon, Nov 6, 2023 at 9:36 AM David Brown via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On 06/11/2023 17:25, Chris Gary via Std-Proposals wrote:
> > I'm not sure if someone's already mentioned this, but is there anything
> > wrong with making this into a "while"?
>
> Yes, it has been mentioned. Certainly IMHO the code was crying out for
> a "while" rather than a badly organised "for", and I can't understand
> why anyone would want a new unusual syntax for this special case.
>
> >
> > I'm aware of the limitations of embedded environments like an Arduino,
> > and so understandably there should really be more error handling to do
> > with the buffer filling up and other things.
>
> Maybe, maybe not. In small embedded systems, you usually have a much
> clearer idea of what errors can occur - and what errors cannot. And you
> frequently have very limited options for dealing with errors - just
> silently dropping any overflow characters can be a perfectly good strategy.
>
> >
> > I've often found myself in need of some way to break out of nested
> > loops, or break from a loop within a switch statement, but then later
> > found it could be refactored into something more readable.
>
> Options include refactoring into functions with early returns, or extra
> flag variables - these are free (assuming a half-decent compiler),
> giving you the run-time effect of gotos or multi-level break/continue
> statements, and with good names their function is clear.
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>