PR libstdc++/68222 Hide safe iterator operators

[François Dumont]

On 08/08/2018 00:41, Jonathan Wakely wrote:
> On 07/08/18 14:47 +0100, Jonathan Wakely wrote:
>> On 02/08/18 22:16 +0200, François Dumont wrote:
>>> Hi
>>>
>>> Â Â Â  Here is a patch to avoid definition of invalid operators on the 
>>> Debug mode safe iterator type depending on its category.
>>>
>>> Â Â Â  Even if it is limited to the Debug mode code I would like to 
>>> have a feedback before committing. Especially on the following points:
>>>
>>> - _Safe_tagged_iterator: Is the name ok ?
>>
>> Hmm, maybe "strict" instead of tagged?
>>
>> But do we need a new name? Can we just change _Safe_iterator instead
>> of adding a new type?
>>
>> Where is _Safe_iterator still used? Just local iterators in unordered
>> containers?  Is it OK to remove most of the functions that used to
>> support it? (__niter_base etc).
>>
>> Could we add a new type for the local iterators, and just change
>> _Safe_iterator directly so it doesn't expose unsupported operations?
>>
>> That would make the patch *much* smaller, as you wouldn't need to
>> change all the uses of _Safe_iterator.
>>
>>
>> Another approach would be to use mixins to expose the operations:
>>
>> template<typename _Iter, typename _Cat>
>> struct _Safe_iterator_mixin<_Iter, _Cat>
>> {
>> typename iterator_traits<_Iter>::reference
>> operator*()
>> { return static_cast<_Iter*>(this)->_M_deref(); }
>> };
>>
>> template<typename _Iter, typename _Cat>
>> struct _Safe_iterator_mixin<_Iter, forward_iterator_tag>
>> {
>> _Iter& operator++()
>> { return static_cast<_Iter*>(this)->_M_preinc(); }
>> _Iter operator++(int)
>> { return static_cast<_Iter*>(this)->_M_postinc(); }
>> };
>>
>> template<typename _Iter, typename _Cat>
>> struct _Safe_iterator_mixin<_Iter, bidirectional_iterator_tag>
>> {
>> _Iter& operator--()
>> { return static_cast<_Iter*>(this)->_M_predec(); }
>> _Iter operator--(int)
>> { return static_cast<_Iter*>(this)->_M_postdec(); }
>> };
>>
>> etc.
>>
>> then in _Safe_iterator rename the operator functions, so operator*
>> becomes _M_deref, operator++ becomes _M_preinc etc. and then derive
>> from _Safe_iterator_mixin which declares the operators.
>
> FWIW I think your proposal with partial specializations for each
> iterator category is probably better than this mixins idea (although I
> think it requires a lot more code to implement it).
>
> But I would like to know if it's possible to just change
> _Safe_iterator instead of introducing a new _Safe_tagged_iterator
> type.
>
>
Yes, I think I come up to my proposal because I tried many approaches 
and faced different problems which I solved the wrong way.

I think I introduced _Safe_tagged_iterator because I wanted to keep 
_Safe_iterator to host the == and != operators as friend functions. But 
after many tests I think I can do the same on _Safe_iterator.

Thanks for the feedback, I'll submit a new proposal soon.

François