On Tue, 18 Jul 2023 at 08:44, Ken Matsui via Libstdc++ < libstdc++@gcc.gnu.org> wrote: > This patch optimizes the performance of the is_compound trait by > dispatching to the new __is_arithmetic built-in trait. > > libstdc++-v3/ChangeLog: > > * include/std/type_traits (is_compound): Use __is_arithmetic > built-in trait. > (is_compound_v): Use is_fundamental_v instead. > > Signed-off-by: Ken Matsui > --- > libstdc++-v3/include/std/type_traits | 11 ++++++++++- > 1 file changed, 10 insertions(+), 1 deletion(-) > > diff --git a/libstdc++-v3/include/std/type_traits > b/libstdc++-v3/include/std/type_traits > index cf24de2fcac..73d9a2b16fc 100644 > --- a/libstdc++-v3/include/std/type_traits > +++ b/libstdc++-v3/include/std/type_traits > @@ -702,9 +702,18 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION > { }; > > /// is_compound > +#if __has_builtin(__is_arithmetic) > + template > + struct is_compound > + : public __bool_constant + || is_void<_Tp>::value > + || is_null_pointer<_Tp>::value)> > + { }; > +#else > template > struct is_compound > : public __not_>::type { }; > +#endif > I think it would be simpler to just do this unconditionally (i.e. just a single definition without using __has_builtin): template struct is_compound : __bool_constant::value> { }; This still avoids instantiating __not_. If is_fundamental is much more efficient now, then I think it's OK to instantiate it here. Otherwise we're duplicating the logic for is_fundamental, and just giving ourselves more code to maintain. Nobody ever uses is_compound anyway! > /// @cond undocumented > template > @@ -3234,7 +3243,7 @@ template > template > inline constexpr bool is_scalar_v = is_scalar<_Tp>::value; > template > - inline constexpr bool is_compound_v = is_compound<_Tp>::value; > + inline constexpr bool is_compound_v = !is_fundamental_v<_Tp>; > template > inline constexpr bool is_member_pointer_v = > is_member_pointer<_Tp>::value; > template > -- > 2.41.0 > >