[Development] Enhancement to QIODevice?
Thiago Macieira
thiago.macieira at intel.com
Wed Sep 16 08:57:56 CEST 2015
On Tuesday 15 September 2015 11:41:10 Andrzej Ostruszka wrote:
> On 09/15/2015 03:53 AM, Thiago Macieira wrote:
> > On Monday 14 September 2015 12:25:20 Andrzej Ostruszka wrote:
> >> So what I'm aiming to is to make the "line" (or more generally "packet")
> >> termination a bit more flexible, that is to allow user to specify the
> >> delimiter. Currently I think the only available solution for my wish is
> >> double buffering - that is to introduce my own buffer that will suck
> >> everything from QIODevice and allow searching for other delimiter but
> >> I'd like to do better than that.
> >
> > You could use peek() to search the buffer, then read() exactly as much as
> > you really need.
>
> I understand that we are talking about
> QIODevicePrivateLinearBuffer::peek() here.
No, I meant QIODevice::peek()
> In your approach I'd be copying data twice, but I can eliminate one with
> peek()ing
> directly to the output buffer and later skip()ping in successful case.
> However in case
> when delimiter is not yet available I'd have unnecessary copying.
Then please provide a patch that avoids the unnecessary second copy when the
read() destination is a null pointer.
> And while peek()ing I'd have to use the min(max size of my output
> buffer, size())
> which would mean that I'd be copying "overlapping" parts more than once.
I didn't understand this.
> This is suboptimal.
>
> Should I drop this proposal? From other replies I gather that I'm not
> the only one
> that would welcome this or similar enhancement.
I think there are easier ways to do this, so I don't think it makes sense to
accept this suggestion.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
More information about the Development
mailing list