Re: -Wclass-memaccess warning should be in -Wextra, not -Wall

[Jonathan Wakely <jwakely dot gcc at gmail dot com>]

On Tue, 10 Jul 2018, 02:22 Soul Studios wrote:
> My point to all of this (and I'm annoyed that I'm having to repeat it
> again, as it my first post wasn't clear enough - which it was) was that
> any programmer using memcpy/memmove/memset is going to know what they're
> getting into.


It was clear in your first post, but that doesn't make it correct. The
statement "any programmer [invoking undefined behaviour] is going to
know what they're getting into" is laughable.

A programmer doing something that causes undefined behaviour probably
doesn't know what they're doing, even if they think they do. And
that's when warnings are useful.

I've seen far more cases of assignment operators implemented with
memcpy that were wrong and broken and due to ignorance or incompetence
than I have seen them done by programmers who knew what they were
doing, or knew what they were getting into. There are programmers who
come from C, and don't realise that a std::string shouldn't be copied
with memcpy. There are programmers who are too lazy to write out
memberwise assignment for each member, so just want to save a few
lines of code by copying everything in one go with memcpy. There are
lots of other ways to do it wrong. Your statement is simply not based
in fact, it's more likely based on your limited experience, and
assumption that everybody is probably doing what you're doing.

If you want to rely on memcpy (and don't want to report
missed-optimization bugs so the compiler can do a better job of
optimizing the non-memcpy code) then you can usually create a
trivially-copyable struct hoding your data members, and then
encapsulate that in a higher-level abstraction which establishes and
enforces the class invariants. The higher-level type has non-trivial
constructors/destructor/whatever but can still just use memcpy on the
trivially-copyable subobject.