Not sure how kosher it is to address several replies in one email, but
I'm going to attempt it as there are overlapping topics:
Martin:
Simply because a struct has a constructor does not mean it isn't a
viable target/source for use with memcpy/memmove/memset.
As the documentation that Segher quoted explains, it does
mean exactly that.
I just thought I'd go back and address this, because it doesn't; you can
have a struct with a basic constructor that is just a convenience
function (or an optimization to avoid default type assignment), but all
the types are POD. This is an obvious viable target for memcpy/memmove.
Please open bugs with small test cases showing
the inefficiencies so the optimizers can be improved.
I've done one today (86471), I may not have time to do more. In
particular I've found GCC to generate less-optimal code for Core2
processors as opposed to the i3 and upwards range, when avoiding memcpy.
No, programmers don't always know that. In fact, it's easy even
for an expert programmer to make the mistake that what looks like
a POD struct can safely be cleared by memset or copied by memcpy
when doing so is undefined because one of the struct members is
of a non-trivial type (such a container like string).
I'm not sure that that would be 'easy' for an expert to make that
mistake (Marc's example aside), but okay.
I'm coming from the understanding that the orthodox approach (and the
one currently being taught in schools/universities) is to use the C++
templated functions as opposed to the older C-style functions, and this
is the avenue that the majority of novice C++ programmers will be coming
from.
Quite a lot of thought and discussion went into the design and
implementation of the warning, so venting your frustrations or
insulting those of us involved in the process is unlikely to
help you effect a change. To make a compelling argument you
Where did I insult you? I didn't. And expressing (not venting)
frustration is fine if I feel people are not accurately reading what
I've written I think. Don't take too much offence.
Jonathan:
> 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.
I didn't say [invoking undefined behaviour]. I said using
memset/memcpy/memmove on the structs/classes-with-constructors-etc where
it is viable to do so. And that may not be invoking undefined behaviour,
as above-
> 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.
Fair enough, if that's your experience, it's fine. My assumption was
that the orthodox (as above) approach is currently
pretty-well-propagated on the internet-and-academia, and that anyone not
doing that would have their reasons. But, thank you for actually
addressing my post's point and not simply dancing around the edge of it.
There are other non-lazy performance reasons to use these, even for
assignment, but it depends on the situation. I don't say this not having
benchmarked it extensively, and correctly, in my own code.
M@
