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.
