C++ Logo


Advanced search

Re: [SG16-Unicode] Replacement for codecvt

From: Niall Douglas <s_sourceforge_at_[hidden]>
Date: Thu, 29 Aug 2019 20:58:15 +0100
>> 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.


Received on 2019-08-29 21:58:18