On Sun, Dec 3, 2023 at 5:39 PM Breno Guimarães wrote:
>
> What if someone memsets the content of the T inside the optional using the size of the T?
> Some people do that even though not always needed, but because paranoia is good :D


My deliberate paranoia has saved my @$$ a few times . . . most
likely many more times than I know about. There's probably a few
emails that never got sent to my boss because I put some deliberate
paranoia in the code. I mean, when programming a microcontroller to
turn off a laser that's fed by two input pins, I set both pins low
(even though I only need to set one of the pins low) and also set the
pin to the MOSFET low that's providing power. Taking a belt and braces
approach to life is beneficial most of the time unless you're doing
extreme optimisation. Malcom In The Middle's older brother said it
better than I ever could: "Always build redundancy into the system".

I wasn't around in the 1970's but I probably would have invented the
watchdog timer in tandem with the actual inventor . . . it would have
been my style.

Using 'memset' to bulldoze memory can be useful for debugging, and
also for limiting the catastrophe caused by a future yet-to-be-written
bug. It's much easier to debug the dereferencing of a nullptr than the
dereferencing of a pointer to a block of memory that got deallocated 4
minutes ago.

I didn't know about the existence of no_unique_address until a few
days ago, and so now I'll be more careful with 'memset' and 'memcpy'.
The whole idea of 'potentially-overlapping objects' is a bit mad and I
would imagine that a few people were hesitant to bring it into C++.