I think going the bit_cast way would be the best because it enables the optimization for many more classes including common wrappers like optional, variant, pair, tuple and std::array.
Regards, Maciej Cencora czw., 27 cze 2024 o 14:57 Maciej Cencora <m.cenc...@gmail.com> napisał(a): > You could include some of the bigger classes by checking whether the class > type is bit_cast-able to std::array of bytes, and that bitcasted output is > equal to value-initialized array. > > Regards, > Maciej > > czw., 27 cze 2024 o 14:50 Jonathan Wakely <jwak...@redhat.com> napisał(a): > >> On Thu, 27 Jun 2024 at 13:49, Jonathan Wakely <jwak...@redhat.com> wrote: >> > >> > On Thu, 27 Jun 2024 at 13:40, Maciej Cencora wrote: >> > > >> > > Hi, >> > > >> > > not sure whether I've missed some conditional that would exclude this >> case, but your change seems to incorrectly handle trivial types that have a >> non-zero bit pattern of value-initialized object, e.g. pointer to member. >> > >> > Good point. I started working on this optimization after last week's >> > https://gcc.gnu.org/r15-1550-g139d65d1f5a60a where is_trivial is >> > appropriate, because valarray only supports numeric types, not >> > pointers to members. >> > >> > But the uninitialized memory algos don't have that restriction, so >> > need to be more careful. >> > >> > I think memset is OK for arithmetic types, enums, pointers, nullptr_t, >> > and trivial classes ... except when those trivial classes contain >> > pointers to members. Which we can't tell. >> > >> > So maybe we can only do it for is_trivial && ((is_scalar and not >> > is_member_pointer) or (is_class and is_empty)). >> >> I suppose any trivial class type smaller than sizeof(int T::*) would >> be OK, because it can't hold a member pointer if it's smaller than >> one. >> >>
