[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