From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) by sourceware.org (Postfix) with ESMTPS id 4325D3858D28; Tue, 14 Dec 2021 06:53:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4325D3858D28 Received: by mail-wr1-x42f.google.com with SMTP id t9so30707644wrx.7; Mon, 13 Dec 2021 22:53:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=8NwsNb7atIP79w5VB1nTJt9mK4J0TLEI3R7QEcSIkFs=; b=FXN4pitq8HNgUWFACwteACT+iXGCz8l9uCo6uc819Hm+5ogl3nVBZbBj9O9OowYg3m MkLvp25W4cJq11GisdrvRL5ptfPMWVN7DkNKOkklIlgaKTv6kgPMI35eOQg/tp6a7I9T FyRX5kM2i7XEwa/008isu6iFZHy+kkcXzIimPd9BCGZi4JRFBLphMOdyVT18HTj779oJ 0FF7ZgNKE1S/4+uoAjyKV8cbuuZc78s156dUmHTU4mkmgPrt4gPgE2+zaMrSUKqPV4CD TLVIbe7NcChghqOWcF7fLmQFbGsoP1lf+CdMy196IlJx1bosOzX3+XNO2BuvyVpb2eO8 fCXw== X-Gm-Message-State: AOAM533xTh7fJhHr2++RGkFXR4ILzigIBGDU0L2ZkhH+DqYj/mVHuFOr A1X2/HJHq3Lpv3nTJG2SkybA4dx+TTs= X-Google-Smtp-Source: ABdhPJwIfU5WZV9KxzLTmXM22yui1CxYZsuU9ZTKCzhYHESYn8n7hZBoMDknbGdMT4aeFmRx1d2iaQ== X-Received: by 2002:a5d:64ed:: with SMTP id g13mr3708545wri.439.1639464815826; Mon, 13 Dec 2021 22:53:35 -0800 (PST) Received: from ?IPv6:2a01:e0a:1dc:b1c0:fde1:70e6:9323:1daa? ([2a01:e0a:1dc:b1c0:fde1:70e6:9323:1daa]) by smtp.googlemail.com with ESMTPSA id k7sm10144763wri.110.2021.12.13.22.53.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Dec 2021 22:53:35 -0800 (PST) Subject: Re: [committed] libstdc++: Specialize std::pointer_traits<__normal_iterator> From: =?UTF-8?Q?Fran=c3=a7ois_Dumont?= To: Jonathan Wakely Cc: Jonathan Wakely , libstdc++ , gcc-patches References: <57b54891-59ba-394d-3d53-218f5061b8ef@gmail.com> <9ea0770a-54fb-2c17-b527-2797b5fd3b50@gmail.com> <34b34b00-8c96-68c1-e436-ab0f64291c2f@gmail.com> <193032c8-8b9a-3e55-a244-075b0031d758@gmail.com> Message-ID: <5a951a74-5afd-a2da-02fd-9f9e7b33b448@gmail.com> Date: Tue, 14 Dec 2021 07:53:34 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: fr X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libstdc++@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libstdc++ mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2021 06:53:39 -0000 Hi     Any conclusion regarding this thread ? François On 06/10/21 7:25 pm, François Dumont wrote: > I forgot to ask if with this patch this overload: > >   template >     constexpr auto >     __to_address(const _Ptr& __ptr, _None...) noexcept >     { >       if constexpr (is_base_of_v<__gnu_debug::_Safe_iterator_base, _Ptr>) >     return std::__to_address(__ptr.base().operator->()); >       else >     return std::__to_address(__ptr.operator->()); >     } > > should be removed ? > > Or perhaps just the _Safe_iterator_base branch in it ? > > On 06/10/21 7:18 pm, François Dumont wrote: >> Here is another proposal with the __to_address overload. >> >> I preferred to let it open to any kind of __normal_iterator >> instantiation cause afaics std::vector supports fancy pointer types. >> It is better if __to_address works fine also in this case, no ? >> >>     libstdc++: Overload std::__to_address for >> __gnu_cxx::__normal_iterator. >> >>     Prefer to overload __to_address to partially specialize >> std::pointer_traits because >>     std::pointer_traits would be mostly useless. In the case of >> __gnu_debug::_Safe_iterator >>     the to_pointer method is even impossible to implement correctly >> because we are missing >>     the parent container to associate the iterator to. >> >>     libstdc++-v3/ChangeLog: >> >>             * include/bits/stl_iterator.h >> (std::pointer_traits<__gnu_cxx::__normal_iterator<>>): Remove. >>             (std::__to_address(const >> __gnu_cxx::__normal_iterator<>&)): New. >>             * include/debug/safe_iterator.h >>             (std::__to_address(const >> __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<>, >> _Sequence>&)): >>             New. >>             * testsuite/24_iterators/normal_iterator/to_address.cc: >> Add check on std::vector::iterator >>             to validate both __gnu_cxx::__normal_iterator<> >> __to_address overload in normal mode and the >> >> Tested under Linux x86_64. >> >> Ok to commit ? >> >> François >> >> >> On 04/10/21 10:30 pm, Jonathan Wakely wrote: >>> On Mon, 4 Oct 2021 at 21:28, François Dumont via Libstdc++ >>>   wrote: >>>> On 04/10/21 10:05 pm, François Dumont wrote: >>>>> On 02/10/21 10:24 pm, Jonathan Wakely wrote: >>>>>> On Sat, 2 Oct 2021 at 18:27, François Dumont wrote: >>>>>>> I would like to propose this alternative approach. >>>>>>> >>>>>>> In this patch I make __normal_iterator and random iterator >>>>>>> _Safe_iterator compatible for pointer_traits primary template. >>>>>>> >>>>>>> Regarding pointer_traits I wonder if it shouldn't check for the >>>>>>> to_pointer method availability and use per default: return { >>>>>>> std::addressof(__e) }; otherwise. This way we wouldn't have to >>>>>>> provide a >>>>>>> pointer_to method on __normal_iterator. >>>>>> But I would rather not have these members present in >>>>>> vector::iterator >>>>>> and string::iterator, in case users accidentally start to rely on >>>>>> them >>>>>> being present. >>>>> Making pointer_traits friends would help but I do not like it >>>>> neither. >>>>> >>>>> >>>>>> Another option would be to overload std::__to_address so it knows >>>>>> how >>>>>> to get the address from __normal_iterator and _Safe_iterator. >>>>>> >>>>>> . >>>>> I start thinking that rather than proposing not-useful and even >>>>> incorrect code in the case of the _Safe_iterator<> it might be a >>>>> better approach. >>>>> >>>>> Even the rebind for __normal_iterator is a little strange because >>>>> when >>>>> doing rebind on std::vector::iterator for long it produces >>>>> __normal_iterator>, quite inconsistent >>>>> even if >>>>> useless. >>>>> >>>>> >