On 8/29/19 3:58 PM, Niall Douglas wrote:
>>> The reason why I really like span<T> for this is because reencoding
>>> benefits greatly from pipelining tricks only possible when input is
>>> guaranteed contiguous.
>>>
>>> I also agree that support for discontiguous input (and output) is also
>>> very important.
>>>
>>> But I'd tend to approach this as span-of-spans i.e. scatter-gather
>>> buffers with resumability. Or, precisely what LLFIO's read()/write()
>>> already implements.
>> That approach would require reconstructing the outer span(s) whenever
>> the input is modified. That doesn't work well for some use cases (e.g.,
>> editors with undo buffers). Ranges offer the proper abstraction for
>> handling all of this transparently with optimum run-time performance.
> I'm actually advocating a low level API, and a high level API. Low level
> API works in terms of resumable span<CharT> (just one span, not span of
> spans). High level API's job is to generate as-long-as-possible
> span<CharT> calls to the low level API, in order to maximise performance.

I should really just let JeanHeyd respond here, but he has also been
pursuing low level C interfaces that fit in with wcsrtombs and friends
and provide translation to/from UTF encodings. Those may end up being a
better fit for your specific needs.

Tom.