Re: [committed] libstdc++: Specialize std::pointer_traits<__normal_iterator<I,C>>

["François Dumont" <frs.dumont@gmail.com>]

I forgot to ask if with this patch this overload:

   template<typename _Ptr, typename... _None>
     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++
>> <libstdc++@gcc.gnu.org>  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<int>::iterator for long it produces
>>>> __normal_iterator<long*, std::vector<int>>, quite inconsistent even if
>>>> useless.
>>>>
>>>>