C++ Logo


Advanced search

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 sg16-owner@lists.isocpp.org