On Fri, Dec 1, 2023 at 10:43 AM David Brown wrote:
>
> How can I put this diplomatically? Your attitude here is just /wrong/.
> Completely and utterly /wrong/. Nothing you have said would be
> acceptable as "best practice" in embedded development.


I'm listening . . .


> To be fair, not all embedded development is done as "best practice".
> And sometimes even when developers know better, there are other
> pressures - time, money and management - forcing shortcuts and hacks to
> be taken.


Unfortunately I've had to take more shortcuts since my workload
increased greatly on account of a sudden unexpected departure from the
company (and he was in the job for 25+ years).


> But no, you never "discard" or "drop" a bus. If you have something you
> want to shut down, and the "normal" shutdown procedure can't work, you
> support an "abnormal" shutdown procedure.


Yeah if ya wanna go opening up the proprietary header files for the
Bus class and also run the object files through a decompiler.


> If you have an object whose lifetime ends, and you want to avoid running
> the destructor, then your architecture is borked. Your design is
> broken. It is not the network connection that has failed, it is the
> software designer that has failed.


Or maybe I just haven't got a week to spend reverse-engineering
someone else's code or debugging a device driver that was written in
Taiwan 13 years ago by a person who retired 3 years ago.


> Maybe the TCP/IP connection has had trouble, and you can't wait for the
> various retries and timeouts for a proper close before starting again.
> Fair enough - but you don't just scrub out some bits of the connection
> and hope for the best! You handle it properly - you move the connection
> to a side object that will deal with the timeouts and closure, while you
> open your new connection.


Sometimes you call a non-blocking function and it blocks. It's not
supposed to, but sometimes it does depending upon the kernel, a device
driver (or a combination of device drivers), the virtual machine
software, the SSH tunnelling software . . .

Sometimes non-blocking functions block.


> Maybe that's hard to do. Maybe it's hard to test. Maybe you need a
> proxy class between your std::optional<> and the original T, with a
> destructor to handle the situation. But that's your job. Stop shirking
> your responsibilities.


I'm the guy who gets work done and meets deadlines -- you must be the other guy.


> Stop claiming everyone else writes buggy code,
> so you want the C++ standard to make it easier for /you/ to write buggy
> code. Stop tarring a whole industry as incompetent just because /you/
> refuse to do a good job.


If I were to adopt your way of thinking, I would think that a watchdog
timer is a pathetic and bad practise to cover up dodgy coding.


> And, in general, stop making claims about
> "embedded developers" or "in the real world". You don't speak for
> embedded developers, and you don't speak for "the real world".


I breed axolotls so I can speak for axolotl breeders -- but that isn't
to say that I'm the sole worldwide authority on breeding axolotls, but
I can at least share my views from my experience breeding axolotls.


> As an embedded developer who wants good, clean, working code, your attitude
> represents the worst we see.


So _you're_ allowed to use the pronoun, 'we', but I'm not.


> I don't want the C++ standards to change here - I want your attitude to change!


Irony. I was reading through your post and then thought, "hang on a
second, who is this?", and then I scrolled up and saw 'David Brown'
and thought "oh of course". Comp.lang.c++ wouldn't be half as colorful
without you.