From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) by sourceware.org (Postfix) with ESMTPS id 72F243858D37; Wed, 24 May 2023 04:51:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 72F243858D37 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-3f606a89795so5935675e9.2; Tue, 23 May 2023 21:51:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684903916; x=1687495916; h=in-reply-to:from:content-language:references:cc:to:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=F5gbFkfcshotk4EMGQp+Ey+0TsQjE1hC+tYoNJbBnpU=; b=NJwhu86GjFkXbo8Z2No35IfipaZfNKS4POio1vGUe9vFuf63OJIx4/trtfDjRQkSLc 0A83ItWQeRnpWYesKTcnQjnm6AbUqtwhDqa+p2DHORXwGTrBs/oyD/TghETPFS23tNId jAoqYMcUH1CYN43J6f11nSBMnM1UEAyaNoH5Ar+BVK9WuQs9Ap3btVNSUp5X+y/kh+Gy 7MXIAc7Ke9xMo/PDXXT6TNu01hbSnKBSYG+zrC6qjHXqd+yx4awonFMk+vkCdXhaVRli GiLCjf6z5zFkMbSb0RMBF8RPXPBnCuIxNMbNhxqAQdOPPPJ2U8dZeVHiGUeFfdpNTOAt i/gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684903916; x=1687495916; h=in-reply-to:from:content-language:references:cc:to:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=F5gbFkfcshotk4EMGQp+Ey+0TsQjE1hC+tYoNJbBnpU=; b=aJQXUH8c7LsUNRMakGS+aIF02aQhiYiPSTA9Rgt/jtGmQv8ucSA0GqPkvFsjY6ySeC DZJ8edCipXIKpPFhuJpNYD3mk2My0qYjrSSgmFAeFpSLQGae8DPHtlTYeXhfRIg2Whvs X1ro9vV/uOUTlERldivDqM3cngY0+NYehGoXx68REhjlfODJE+357ahdx7KXH4GrtS5z /QooPW51CmPEopn/pfOSaHtw3JH45AP7TctdWS1WWKhHtnz3tJs6egKBpo4byrcASsWo u1X8XNemPJ/CYy2NzvfvdQ5sIAuhm/UeXxtAjDlBYjTDSTsA237UmY4pYVK41RNrb1ii p5tA== X-Gm-Message-State: AC+VfDzebj/kNtaA6xe/sdWUkMTbSokGaBlO6kw8GtVfg2+kMXUOIHrm xEwhQITbMPU/X8YpgP3FTZBmLkoSRlo= X-Google-Smtp-Source: ACHHUZ706xVmDreyJHRjMf1RKsGRURyGOaZVLda/GAQGTa0gwa+1JQ77PKoMES1nLDBc0I9j0BEgog== X-Received: by 2002:a05:600c:2209:b0:3f6:2ae:230e with SMTP id z9-20020a05600c220900b003f602ae230emr7639677wml.3.1684903915769; Tue, 23 May 2023 21:51:55 -0700 (PDT) Received: from [10.22.0.67] ([89.207.171.100]) by smtp.gmail.com with ESMTPSA id o4-20020a05600c378400b003f6050d35c9sm906461wmr.20.2023.05.23.21.51.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 23 May 2023 21:51:55 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------GqZFNqvL94kH9N0xB9FHsgCG" Message-ID: <84a7b527-d2b9-c244-8fde-c141cdce23b7@gmail.com> Date: Wed, 24 May 2023 06:51:52 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [PATCH] Replace __gnu_cxx::__ops::__negate with std::not_fn To: Jonathan Wakely Cc: libstdc++ , gcc-patches References: <9fbe09f1-ea49-b520-251b-faba47d74179@gmail.com> Content-Language: en-US From: =?UTF-8?Q?Fran=c3=a7ois_Dumont?= In-Reply-To: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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: This is a multi-part message in MIME format. --------------GqZFNqvL94kH9N0xB9FHsgCG Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 22/05/2023 22:55, Jonathan Wakely wrote: > > > On Mon, 22 May 2023 at 21:51, François Dumont via Libstdc++ > > wrote: > > I was thinking that it might be nice to get rid of > predefined_ops.h content. > > So here is a start with __negate. Drawback is that stl_algo.h has to > include . > > > We definitely don't want that. std::not_fn could be move to its own > header. > > But I'm not sure this is a good change anyway, as we can't do it > unconditionally. Pre-C++17 code would still be using the > predefined_ops.h function objects, so we can't remove that code. And > we'll get template bloat from instantiating the algos twice, once with > the old function objects and once with std::not_fn. True, what do you advise then ? Should I just forget about it ? Introduce a std::__not_fn for pre-C++17 ? I am studying this last proposal, let me know if it is just impossible or a waste of time. > > For now I just get rid of stl_algo.h include in > to rather use stl_algobase.h. But maybe it would be > better > to also isolate std::not_fn in a dedicated header file so that > stl_algo.h do not have to include all . > >      libstdc++: Replace __gnu_cxx::__ops::__negate with std::not_fn > >      Replace the internal __gnu_cxx::__ops::__negate function and > associated >      __gnu_cxx::__ops::_Iter_negate by the C++17 std::not_fn. > >      libstdc++-v3/ChangeLog: > >              * include/bits/predefined_ops.h: Include . > > > No, please don't include anywhere. If you do that, it means > now defines every feature test macro in the entire > library, which makes it look like you can get smart pointers and > ranges and constexpr math all from . Ok, I wasn't aware about the interest of . I see now, limited to user code. I'm testing only the move of std::search to stl_algobase.h to avoid stl_algo.h include in . I'll submit it later. --------------GqZFNqvL94kH9N0xB9FHsgCG--