Date: Sun, 3 Dec 2023 16:19:03 -0300
It was just a joke.
By the way, the no_unique_address annotation didn't bring the concept of
overlapping objects. It already existed.
https://en.cppreference.com/w/cpp/language/ebo
Em dom., 3 de dez. de 2023 14:55, Frederick Virchanza Gotham via
Std-Proposals <std-proposals_at_[hidden]> escreveu:
> 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++.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
By the way, the no_unique_address annotation didn't bring the concept of
overlapping objects. It already existed.
https://en.cppreference.com/w/cpp/language/ebo
Em dom., 3 de dez. de 2023 14:55, Frederick Virchanza Gotham via
Std-Proposals <std-proposals_at_[hidden]> escreveu:
> 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++.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2023-12-03 19:20:03