[PATCH] Extend std::copy/std::copy_n char* overload to deque iterator

[François Dumont]

I commit yesterday but git hook rejected it in the first attempts. To 
make it pass I avoided to split this file path:

         * 
testsuite/25_algorithms/copy/streambuf_iterators/char/debug/deque_neg.cc:
         New test.

now it is more than 80 chars.

I don't know if it was the reason of the reject as I also use 'New test' 
rather than just 'New' at the same time. If you think it is the reason, 
how such path are supposed to be split to pass the check ?


On 02/06/20 10:15 pm, Jonathan Wakely wrote:
> On 24/05/20 15:43 +0200, François Dumont via Libstdc++ wrote:
>> Now tested in C++98 mode, there was indeed a small problem.
>>
>> I even wonder if I shouldn't have extend the std::copy overload to 
>> any call with deque iterator as the output so that it is transform 
>> into an output to pointer.
>>
>> Ok to commit ?
>
>
>
>> --- a/libstdc++-v3/include/debug/safe_iterator.tcc
>> +++ b/libstdc++-v3/include/debug/safe_iterator.tcc
>> @@ -234,6 +234,12 @@ namespace std _GLIBCXX_VISIBILITY(default)
>> {
>> _GLIBCXX_BEGIN_NAMESPACE_VERSION
>>
>> +  template<typename _Ite, typename _Seq>
>> +    _Ite
>> +    __niter_base(const ::__gnu_debug::_Safe_iterator<_Ite, _Seq,
>> +         std::random_access_iterator_tag>& __it)
>> +    { return __it.base(); }
>> +
>
> I was going to ask if there's a reason this uses "_Ite" and not
> "_Iter", but I see we already have several uses of that.
>
> Thy all seem to be introduced by you though :-)
>
> We definitely have a lot more "_Iter" uses though:
>
> $ git grep -w _Ite -- include/ | wc -l
> 46
> $ git grep -w _Iter -- include/ | wc -l
> 835
>
> When I see "Ite" it looks to me as though it should rhyme with "sight"
> or "white", rather than "Iter" which rhymes with "bitter" (and so is
> the start of "iterator").
>
> Leave it as _Ite for now, I might go through and change every _Ite to
> _Iter later.
>
>
> OK for master, thanks.
>
>