Add std::copy_n overload for istreambuf_iterator

[Jonathan Wakely]

On 04/10/19 07:01 +0200, François Dumont wrote:
>On 9/27/19 1:00 PM, Jonathan Wakely wrote:
>>On 19/07/19 23:37 +0200, François Dumont wrote:
>>>It sounds reasonable to overload std::copy_n for istreambuf_iterator.
>>I wonder whether it's worth doing:
>>
>>#if __cplusplus >= 201703L
>>Â Â  if constexpr (is_same_v<_OutputIterator, _CharT*>)
>>Â Â Â Â  return __result + __it._M_sbuf->sgetn(__result, __n);
>>Â Â  else
>>Â Â Â Â  {
>>#endif
>>Â Â Â Â  ...
>>#if __cplusplus >= 201703L
>>Â Â Â Â  }
>>#endif
>>
>>We could extend that to also work for basic_string<_CharT>::iterator
>>and vector<_CharT>::iterator too if we wanted.
>>
>>I'm not sure if it will perform any better than the code below (it's
>>approximately equivalent) but it should result in smaller binaries, as we
>>wouldn't be instantiating the code below when outputting to a pointer
>>or contiguous iterator.
>>
>>We don't need to do that now, it can be a separate patch later (if we
>>do it at all).
>
>Very good remark, I hadn't check streambuf to find out if there were 
>better to do. For me it is the streambuf method to target for an 
>std::copy_n overload.
>
>So here is a new proposal much simpler. I see no reason to enable it 
>only for char types, is there ?

The reason to only do this for char-like types and std::char_traits is
that users could specialize istreambuf_iterator on their own types or
their own traits, and the specialization would not declare __copy_n_a
as a friend, and would not have the _M_sbuf member.

So I think we should still limit the optimisation to __is_char types
and std::char_traits. In practice that will help for all reasonable
cases, and unreasonable users who specialize the class can still
compile, but don't get the optimisation.


>>Ideally I'd also like to see tests where the input buffer is larger
>>than the size being read, e.g. read 5 chars from "123456" and verify
>>we don't read the '6'.
>In test01 I am doing something like that.

Thanks.

>>Also, these tests don't exercise the code path that causes an
>>underflow. It would be good to use an ifstream to read from one of the
>>files in the testsuite/data directory, and read a large amount of data
>>(more than fits in a filebuf's read area) so that the underflow logic
>>is tested.
>
>With this new proposal I don't need to do it, I'am counting on sgetn tests.

Agreed.

OK for trunk with the __is_char<_CharT> and char_traits<_CharT>
constraint restored. Thanks!