On 07/05/2018 05:14 PM, Soul Studios wrote:
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.
Some classes have user-defined copy and default ctors with
the same effect as memcpy/memset. In modern C++ those ctors
should be defaulted (= default) and GCC should emit optimal
code for them. In fact, in loops they can result in more
efficient code than the equivalent memset/memcpy calls. In
any case, "native" operations lend themselves more readily
to code analysis than raw memory accesses and as a result
allow all compilers (not just GCC) do a better a job of
detecting bugs or performing interesting transformations
that they may not be able to do otherwise.
Having benchmarked the alternatives memcpy/memmove/memset definitely
makes a difference in various scenarios.
Please open bugs with small test cases showing
the inefficiencies so the optimizers can be improved.
Martin
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.
Therefore it makes no sense to penalize them by getting them to write
ugly, needless code - regardless of the surrounding politics/codewars.
Extra seems an amiable place to put this, All doesn't.
As for test cases, well, this is something I've benchmarked over a range
of scenarios in various projects over the past 3 years (mainly
plf::colony and plf::list).
If I have time I'll submit a sample.
