On Mon, Sep 11, 2023 at 7:51 AM Jonathan Wakely <jwak...@redhat.com> wrote:
>
> On Thu, 31 Aug 2023 at 13:33, Ken Matsui <kmat...@cs.washington.edu> wrote:
> >
> > On Tue, Aug 8, 2023 at 1:23 PM Jonathan Wakely <jwak...@redhat.com> wrote:
> > >
> > >
> > >
> > > On Wed, 19 Jul 2023 at 20:33, Ken Matsui via Libstdc++ 
> > > <libstd...@gcc.gnu.org> wrote:
> > >>
> > >> This patch defines _GLIBCXX_HAS_BUILTIN_TRAIT macro, which will be used
> > >> as a flag to toggle the use of built-in traits in the type_traits header
> > >> through _GLIBCXX_NO_BUILTIN_TRAITS macro, without needing to modify the
> > >> source code.
> > >>
> > >> libstdc++-v3/ChangeLog:
> > >>
> > >>         * include/bits/c++config (_GLIBCXX_HAS_BUILTIN_TRAIT): Define.
> > >>         (_GLIBCXX_HAS_BUILTIN): Keep defined.
> > >
> > >
> > > I think this would be a little better as:
> > >
> > >         * include/bits/c++config (_GLIBCXX_HAS_BUILTIN): Do not undef.
> > >         (_GLIBCXX_HAS_BUILTIN_TRAIT): Define.
> > >
> > > OK for trunk with that change, thanks.
> > >
> > Thank you for your review! Patrick and I were discussing the naming
> > conventions for the macros _GLIBCXX_HAS_BUILTIN_TRAIT and
> > _GLIBCXX_NO_BUILTIN_TRAITS. It was brought to our attention that these
> > namings might be ambiguous, as there are implementations that have
> > corresponding built-ins but do not have fallback. Therefore, we
> > believe that using _GLIBCXX_USE_BUILTIN_TRAIT instead of
> > _GLIBCXX_HAS_BUILTIN_TRAIT would be more appropriate. Similarly, we
> > think that _GLIBCXX_AVOID_BUILTIN_TRAITS would be a better choice than
> > _GLIBCXX_NO_BUILTIN_TRAITS, as the latter implies that there are no
> > built-ins, when in fact it is meant to express that the use of
> > built-ins should be avoided when defining this macro. Could you please
> > let me know your thoughts on these updated namings?
>
> Yes, I agree that makes sense. I think personally I'd go with
> "DISABLE" instead of "AVOID", or even "DO_NOT_USE" (to mirror "USE" in
> the macro for individual traits), but either is OK.

I like the idea of mirroring "USE", so I would choose "DO_NOT_USE".
Thank you for your response!

> > >
> > >>
> > >>
> > >> Signed-off-by: Ken Matsui <kmat...@gcc.gnu.org>
> > >> ---
> > >>  libstdc++-v3/include/bits/c++config | 10 +++++++++-
> > >>  1 file changed, 9 insertions(+), 1 deletion(-)
> > >>
> > >> diff --git a/libstdc++-v3/include/bits/c++config 
> > >> b/libstdc++-v3/include/bits/c++config
> > >> index dd47f274d5f..984985d6fff 100644
> > >> --- a/libstdc++-v3/include/bits/c++config
> > >> +++ b/libstdc++-v3/include/bits/c++config
> > >> @@ -854,7 +854,15 @@ namespace __gnu_cxx
> > >>  # define _GLIBCXX_HAVE_BUILTIN_LAUNDER 1
> > >>  #endif
> > >>
> > >> -#undef _GLIBCXX_HAS_BUILTIN
> > >> +// Returns 1 if _GLIBCXX_NO_BUILTIN_TRAITS is not defined and the 
> > >> compiler
> > >> +// has a corresponding built-in type trait, 0 otherwise.
> > >> +// _GLIBCXX_NO_BUILTIN_TRAITS can be defined to disable the use of 
> > >> built-in
> > >> +// traits.
> > >> +#ifndef _GLIBCXX_NO_BUILTIN_TRAITS
> > >> +# define _GLIBCXX_HAS_BUILTIN_TRAIT(BT) _GLIBCXX_HAS_BUILTIN(BT)
> > >> +#else
> > >> +# define _GLIBCXX_HAS_BUILTIN_TRAIT(BT) 0
> > >> +#endif
> > >>
> > >>  // Mark code that should be ignored by the compiler, but seen by 
> > >> Doxygen.
> > >>  #define _GLIBCXX_DOXYGEN_ONLY(X)
> > >> --
> > >> 2.41.0
> > >>
> >
>

Reply via email to