From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) by sourceware.org (Postfix) with ESMTPS id B0AAC3858415; Wed, 6 Oct 2021 17:25:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B0AAC3858415 Received: by mail-ed1-x52d.google.com with SMTP id f4so7530689edr.8; Wed, 06 Oct 2021 10:25:21 -0700 (PDT) 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=om8CX8zeXIIjmYR+I1Y2p2zpH/znGBSl9j3QKTbjghM=; b=WM8/FKZsfvnoahvB39hhPMvw/WCQzZ3ojL9e5EoykabXBWhGeBKs6F776AeZmYVAIe QvWbkGCRqL/OSPH+xAX6N7PMjfNGWX5g+T5knCN3N+O6JSh9L7QkzzNsNsixrIdeA716 /KcG4nMjvXHIwDVec2UGMMXe3KoaU4oMx1fxblWPM9aoi5s2e5a23anfDiHpC33jyCPl dkTGu+EoIaZ3aol8KIMUyQ95W5OsUo4uygl7ikQC8B7ugPTPEOZD4+6MF7vgD3yIiiW/ gjV6nvgXVL7wJBpXTuMNlLNBTteImv8UODAc78Gvk3O7y4JwhwmH5KEneRo+3dGEfOxK W7Bw== X-Gm-Message-State: AOAM530MvtIUIXbIracYzZBKXJ7rJpTx8LYworKHoo6mFfLfiUB/E8k2 J1BXn7ZO6OqKNSzVr/HvkhXwLkJ0k9w= X-Google-Smtp-Source: ABdhPJzcmOqtmsf4W5dC82GPac3KK6fAz6kVa3rExKru6+qoqZR7rx18LJ5L581qKWAJMKXB9oBO8w== X-Received: by 2002:a17:906:134e:: with SMTP id x14mr10443886ejb.72.1633541118870; Wed, 06 Oct 2021 10:25:18 -0700 (PDT) Received: from [10.34.5.219] ([109.190.253.15]) by smtp.googlemail.com with ESMTPSA id cr9sm10210075edb.17.2021.10.06.10.25.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Oct 2021 10:25:18 -0700 (PDT) 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: Date: Wed, 6 Oct 2021 19:25:16 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <193032c8-8b9a-3e55-a244-075b0031d758@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: fr X-Spam-Status: No, score=-2.9 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_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no 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: Wed, 06 Oct 2021 17:25:23 -0000 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. >>>> >>>>