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

[François Dumont]

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.
>>>
>>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: to_address.patch
Type: text/x-patch
Size: 3255 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc-patches/attachments/20211006/d87a29da/attachment-0001.bin>