Subject: Re: [SG16-Unicode] Replacement for codecvt
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2019-08-29 14:58:15
>> 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.
As I say, I'll return to path_view development after Belfast. I'll see
what sort of low level API I can come up with intended for easier
implementation of the high level API.
SG16 list run by email@example.com