From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout-p-102.mailbox.org (mout-p-102.mailbox.org [80.241.56.152]) by sourceware.org (Postfix) with ESMTPS id 2DED83858025; Mon, 7 Aug 2023 17:38:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2DED83858025 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=aarsen.me Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=aarsen.me Received: from smtp1.mailbox.org (smtp1.mailbox.org [IPv6:2001:67c:2050:b231:465::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-102.mailbox.org (Postfix) with ESMTPS id 4RKNnj2CBcz9sbm; Mon, 7 Aug 2023 19:38:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aarsen.me; s=MBO0001; t=1691429881; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=6MSGZTfTSoU3XOjrahSQA5sNblc7fr607an55v79fAs=; b=fQnhqh669PMInmPcauG5n2IFdwsD9f1/z1jxTVAkXo94tt1c8t5YlAaZyAwKncsKv1B9z8 f+3rPDMdZ3unlrIduRX0pY/jdUiO1O64Bi2zl/xDLZ1RDTnYdrnwZPvPOmPdpsTz3oHLNr SUWtSSbdPs3zycGrrV3UVfDTM+n4EbQHOEQIR2XE8S8fNHJIp/1goGxZlMftxZl8ND4bCJ SA+riWYdlsYwuZrGI8+spML47zzM44yi2wZSxAgIgbLwH2+/qoPRhBGW51nz3rCu5azU5A Ezr1meW12ClrcVD0d4RVRBnU7IDuI//8C8/bMd8FD3j4dfEdJZ7vQL0KYIokQQ== References: <20230429101640.1697750-1-arsen@aarsen.me> <20230429101640.1697750-3-arsen@aarsen.me> From: Arsen =?utf-8?Q?Arsenovi=C4=87?= To: Jonathan Wakely Cc: gcc-patches@gcc.gnu.org, libstdc++@gcc.gnu.org Subject: Re: [PATCH 2/2] libstdc++: Replace all manual FTM definitions and use Date: Mon, 07 Aug 2023 19:34:21 +0200 In-reply-to: Message-ID: <86bkfivjm0.fsf@aarsen.me> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Rspamd-Queue-Id: 4RKNnj2CBcz9sbm X-Spam-Status: No, score=-11.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,KAM_INFOUSMEBIZ,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Jonathan Wakely writes: > On Sat, 29 Apr 2023 at 11:24, Arsen Arsenovi=C4=87 via Libstdc++ < > libstdc++@gcc.gnu.org> wrote: > >> libstdc++-v3/ChangeLog: >> >> * libsupc++/typeinfo: Switch to bits/version.h for >> __cpp_lib_constexpr_typeinfo. >> >> > Does this change have an impact on compilation speed? > With this change we'll be re-including bits/version.h multiple times in > most compilations, and unlike other headers the preprocessor can't optimi= ze > away the second and subsequent times its' included, because the header > isn't idempotent. > It will only affect the preprocessing phase, which is a fraction of the > time taken by template instantiation and middle end optimizations, but I'd > like to know it's not *too* expensive before committing to this approach. > >> @@ -234,9 +234,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION >> return __atomic_test_and_set (&_M_i, int(__m)); >> } >> >> -#if __cplusplus > 201703L >> -#define __cpp_lib_atomic_flag_test 201907L >> - >> +#ifdef __cpp_lib_atomic_flag_test >> _GLIBCXX_ALWAYS_INLINE bool >> test(memory_order __m =3D memory_order_seq_cst) const noexcept >> { >> > > This is more "structured" and maintainable than the current ad-hoc way we > deal with FTMs, but this seems like a readability/usability regression in > terms of being able to open the header and see "ah this feature is only > available for C++20 and up". Instead you can see it's available for the > specified FTM, but now you have to go and find where that's defined, and > that's not even defined in C++, it's in the version.def file. It's also > defined in bits/version.h, but that's a generated file and so is very > verbose and long. > > > diff --git a/libstdc++-v3/include/bits/move_only_function.h >> b/libstdc++-v3/include/bits/move_only_function.h >> index 71d52074978..81d7d9f7c0a 100644 >> --- a/libstdc++-v3/include/bits/move_only_function.h >> +++ b/libstdc++-v3/include/bits/move_only_function.h >> @@ -32,7 +32,10 @@ >> >> #pragma GCC system_header >> >> -#if __cplusplus > 202002L >> +#define __glibcxx_want_move_only_function >> +#include >> + >> +#ifdef __cpp_lib_move_only_function >> > > Here's another case where I think the __cplusplus > 202002L is more > discoverable. > > Although maybe I'm biased, because I look at that and immediately see > "C++23 and up". Maybe the average user finds that less clear. Maybe the > average user doesn't need to look at this anyway, but I know *I* do it > fairly often. > > I wonder if it would help if we kept a comment there with a (possibly > imprecise) hint about the conditions under which the feature is defined. = So > in this case: > > // Only defined for C++23 > #ifdef __cpp_lib_move_only_function > > That retains the info that's currently there, and is even more readable > than the __cplusplus check. > > There's a risk that those comments would get out of step with reality, > which is one of the things this patch set aims to solve. But I think in > practice that's unlikely. std::move_only_function isn't suddenly going to > become available in C++20, or stop being available in C++23 and move to > C++26. > > What do you think? I think that's reasonable. And, yes, I doubt these conditions change much. I'll go over the conditions and insert a hint. =2D-=20 Arsen Arsenovi=C4=87 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iOYEARYKAI4WIQT+4rPRE/wAoxYtYGFSwpQwHqLEkwUCZNEr918UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0RkVF MkIzRDExM0ZDMDBBMzE2MkQ2MDYxNTJDMjk0MzAxRUEyQzQ5MxAcYXJzZW5AYWFy c2VuLm1lAAoJEFLClDAeosST8zMBAP/eXEboP2V39fVMN/6x6f5QLTPw37t128Ys KwnP/G3+AP481P3MZzRq4KAHDLZSrvVeujsTkbpnBMnNAlIkb5fPCQ== =q2Yu -----END PGP SIGNATURE----- --=-=-=--