Limit Debug mode impact: overload __niter_base

François Dumont frs.dumont@gmail.com
Tue Jul 3 05:47:00 GMT 2018


Here is the updated patch.

     * include/bits/stl_algobase.h (__niter_wrap): New.
     (__copy_move_a2(_II, _II, _OI)): Use latter.
     (__copy_move_backward_a2(_BI1, _BI1, _BI2)): Likewise.
     (fill_n(_OI, _Size, const _Tp&)): Likewise.
     (equal(_II1, _II1, _II2)): Use __glibcxx_requires_can_increment.
     * include/debug/stl_iterator.h
     (std::__niter_base(const __gnu_cxx::_Safe_iterator<
     __gnu_cxx::__normal_iterator<>, _Sequence>&)): New declaration.
     * include/debug/vector (__niter_base(const __gnu_cxx::_Safe_iterator<
     __gnu_cxx::__normal_iterator<>, _Sequence>&)): New.

Ok to commit ?


On 02/07/2018 13:57, Jonathan Wakely wrote:
> On 01/07/18 21:20 +0200, François Dumont wrote:
>>     Here is a new proposal between yours and mine.
>>
>>     It is still adding a function to wrap what __niter_base unwrap, I 
>> called it __nwrap_iter for this reason. But it takes advantage of 
>
> Since "niter" refers to __normal_iterator I think a name based on
> "niter" would be better than nsomething_iter.
>
> __niter_wrap
> __niter_rewrap
> __niter_lift (misuse of functional programming term?)
> __niter_raise (misuse of linear algebra term?)
> __make_niter
> __remake_niter
>
>
>> knowing that __niter_base will only unwrap random access iterator to 
>> use an expression to that will do the right thing, no matter the 
>> original iterator type.
>
> OK, since __niter_base only transforms types based on 
> __normal_iterator that seems safe to assume (in theory we could use
> __normal_iterator with non-random access iterators, but we don't).
>
> Could you please add a comment to the __nwrap_iter saying something
> like:
>
>  // Reverse the __niter_base transformation to get a
>  // __normal_iterator back again (this assumes that __normal_iterator
>  // is only used to wrap random access iterators, like pointers).
>
>
>>     I eventually found no issue in the testsuite, despite the 
>> std::equal change. I might have had a local invalid test.
>
> Yes, I *did* test it already :-)
>
>
>
>
>> diff --git a/libstdc++-v3/include/bits/stl_algobase.h 
>> b/libstdc++-v3/include/bits/stl_algobase.h
>> index d429943..003ae8d 100644
>> --- a/libstdc++-v3/include/bits/stl_algobase.h
>> +++ b/libstdc++-v3/include/bits/stl_algobase.h
>> @@ -277,6 +277,18 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>>     __niter_base(_Iterator __it)
>>     { return __it; }
>>
>> +  // Convert an iterator of type _From to an iterator of type _To.
>> +  // e.g. from int* to __normal_iterator<int*, Seq>.
>> +  template<typename _Iterator>
>> +    inline _Iterator
>> +    __nwrap_iter(_Iterator, _Iterator, _Iterator __res)
>> +    { return __res; }
>> +
>> +  template<typename _From, typename _To>
>> +    inline _From
>> +    __nwrap_iter(_From __from, _To __to, _To __res)
>> +    { return __from + (__res - __to); }
>
> Every time you call this function you pass it:
>
>  __nwrap_iter(x, __niter_base(x), y)
>
> So can the __niter_base(x) call happen inside __nwrap_iter?
>
> i.e.
>
>  template<typename _From, typename _To>
>    inline _From
>    __nwrap_iter(_From __from, _To __res)
>    { return __from + (__res - __niter_base(__from)); }
>
>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: niter_debug.patch
Type: text/x-patch
Size: 3982 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20180703/e5194333/attachment.bin>


More information about the Gcc-patches mailing list