On Fri, 6 Jul 2018, Martin Sebor wrote:
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.
What if I want to memcpy a std::pair<int,int>?
Some classes may have several states, some that are memcpy-safe, and some
that are not. A user may know that at some point in their program, all the
objects in a given array are safe, and want to memcpy the whole array
somewhere.
memcpy can also be used to work around the lack of a destructive move in
C++. For instance, vector<vector<T>>::resize could safely use memcpy (and
skip destroy before deallocate). In this particular case, we could imagine
at some point in the future that the compiler would notice it is
equivalent to memcpy+bzero, and then that the bzero is dead, but there are
more complicated use cases for destructive move.
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.
Some already exist (PR 86024 seems related, there are probably some closer
matches), but indeed more would be helpful.
--
Marc Glisse
