Make std::vector<bool> iterator operators friend inline

[François Dumont]

On 10/15/2018 11:36 AM, Jonathan Wakely wrote:
> On 12/10/18 18:25 +0200, François Dumont wrote:
>> Here is the patch for _Bit_iterator and _Bit_const_iterator operators.
>>
>> I noticed that _Bit_reference == and < operators could be made inline 
>> friend too. Do you want me to include this change in the patch ?
>>
>>
>> Â Â Â  * include/bits/stl_bvector.h (_Bit_iterator_base::operator==): 
>> Replace
>> Â Â Â  member method with inline friend.
>> Â Â Â  (_Bit_iterator_base::operator<): Likewise.
>> Â Â Â  (_Bit_iterator_base::operator!=): Likewise.
>> Â Â Â  (_Bit_iterator_base::operator>): Likewise.
>> Â Â Â  (_Bit_iterator_base::operator<=): Likewise.
>> Â Â Â  (_Bit_iterator_base::operator>=): Likewise.
>> Â Â Â  (operator-(const _Bit_iterator_base&, const 
>> _Bit_iterator_base&)): Make
>> Â Â Â  inline friend.
>> Â Â Â  (_Bit_iterator::operator+(difference_type)): Replace member 
>> method with
>> Â Â Â  inline friend.
>> Â Â Â  (_Bit_iterator::operator-(difference_type)): Likewise.
>> Â Â Â  (operator+(ptrdiff_t, const _Bit_iterator&)): Make inline friend.
>> Â Â Â  (_Bit_const_iterator::operator+(difference_type)): Replace member 
>> method
>> Â Â Â  with inline friend.
>> Â Â Â  (_Bit_const_iterator::operator-(difference_type)): Likewise.
>> Â Â Â  (operator+(ptrdiff_t, const _Bit_const_iterator&)): Make inline
>> Â Â Â  friend.
>>
>> Tested under Linux x86_64.
>>
>> Ok to commit ?
>>
>> François
>>
>
>> diff --git a/libstdc++-v3/include/bits/stl_bvector.h 
>> b/libstdc++-v3/include/bits/stl_bvector.h
>> index 19c16839cfa..8fbef7a1a3a 100644
>> --- a/libstdc++-v3/include/bits/stl_bvector.h
>> +++ b/libstdc++-v3/include/bits/stl_bvector.h
>> @@ -182,40 +182,40 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
>> Â Â Â Â Â  _M_offset = static_cast<unsigned int>(__n);
>> Â Â Â  }
>>
>> -Â Â Â  bool
>> -Â Â Â  operator==(const _Bit_iterator_base& __i) const
>> -Â Â Â  { return _M_p == __i._M_p && _M_offset == __i._M_offset; }
>> +Â Â Â  friend bool
>> +Â Â Â  operator==(const _Bit_iterator_base& __x, const 
>> _Bit_iterator_base& __y)
>> +Â Â Â  { return __x._M_p == __y._M_p && __x._M_offset == __y._M_offset; }
>>
>> -Â Â Â  bool
>> -Â Â Â  operator<(const _Bit_iterator_base& __i) const
>> +Â Â Â  friend bool
>> +Â Â Â  operator<(const _Bit_iterator_base& __x, const 
>> _Bit_iterator_base& __y)
>> Â Â Â  {
>> -Â Â Â Â Â  return _M_p < __i._M_p
>> -Â Â Â Â Â Â Â  || (_M_p == __i._M_p && _M_offset < __i._M_offset);
>> +Â Â Â Â Â  return __x._M_p < __y._M_p
>> +Â Â Â Â Â Â Â  || (__x._M_p == __y._M_p && __x._M_offset < __y._M_offset);
>> Â Â Â  }
>>
>> -Â Â Â  bool
>> -Â Â Â  operator!=(const _Bit_iterator_base& __i) const
>> -Â Â Â  { return !(*this == __i); }
>> +Â Â Â  friend bool
>> +Â Â Â  operator!=(const _Bit_iterator_base& __x, const 
>> _Bit_iterator_base& __y)
>> +Â Â Â  { return !(__x == __y); }
>>
>> -Â Â Â  bool
>> -Â Â Â  operator>(const _Bit_iterator_base& __i) const
>> -Â Â Â  { return __i < *this; }
>> +Â Â Â  friend bool
>> +Â Â Â  operator>(const _Bit_iterator_base& __x, const 
>> _Bit_iterator_base& __y)
>> +Â Â Â  { return __y < __x; }
>>
>> -Â Â Â  bool
>> -Â Â Â  operator<=(const _Bit_iterator_base& __i) const
>> -Â Â Â  { return !(__i < *this); }
>> +Â Â Â  friend bool
>> +Â Â Â  operator<=(const _Bit_iterator_base& __x, const 
>> _Bit_iterator_base& __y)
>> +Â Â Â  { return !(__y < __x); }
>>
>> -Â Â Â  bool
>> -Â Â Â  operator>=(const _Bit_iterator_base& __i) const
>> -Â Â Â  { return !(*this < __i); }
>> -Â  };
>> +Â Â Â  friend bool
>> +Â Â Â  operator>=(const _Bit_iterator_base& __x, const 
>> _Bit_iterator_base& __y)
>> +Â Â Â  { return !(__x < __y); }
>>
>> -Â  inline ptrdiff_t
>> -Â  operator-(const _Bit_iterator_base& __x, const _Bit_iterator_base& 
>> __y)
>> -Â  {
>> -Â Â Â  return (int(_S_word_bit) * (__x._M_p - __y._M_p)
>> -Â Â Â Â Â Â Â  + __x._M_offset - __y._M_offset);
>> -Â  }
>
> For the non-member operator- and operator+ this change makes sense,
> but what is the benefit of changing all the others? As members they're
> already not considered as candidates for unrelated types, or am I
> missing something?
>
>
Well, I remember a pretty old conversation about making all operators 
consistent that is to say not sometimes member and sometimes non-member.

So I am trying to make all operators non-member as much as possible. 
That's indeed the only reason.