[Development] Changing container privates again

Thiago Macieira thiago.macieira at intel.com
Mon Jun 11 16:42:36 CEST 2012


On segunda-feira, 11 de junho de 2012 16.16.59, João Abecasis wrote:
> > However, I don't think that's going to be a very useful use-case. I
> > already
> > think that in-place modification of externally-allocated data is a stretch
> > use- case, but one that could be eventually useful. Allowing the
> > container to use memory around that is too much, IMHO.
> 
> Heh, mpeterss just walked into my office with a QIODevicePrivateLinearBuffer
> issue...
> 
> There, QIODevice manages a read cache. When you call readAll on that, it
> copies all the data to QByteArray and resets its data:
> 
>     QByteArray readAll()
>     {
>         char* data = first;
>         int length = len;
> 
>         QByteArray retVal(data, length);
>         clear();
>         return retVal;
>     }
> 
> Depending on length, it'd be good to relinquish your buffer to QIODevice and
> allocate a new one. Saves the memcpy(): "Here you go, do what you like with
> it but call free() when you're done playing."

The notify thing could do that. I'm not sure about the QIODevice use-case, 
though. QRingBuffer is a scattered buffer and QByteArray cannot manage that 
anyway. You need to consolidate before returning from readAll() and do a lot 
of memcpy. So why not let QByteArray allocate the memory in the first place?

There, we don't have foreign data anymore.

> In this use case mutability might not be the most important thing, but then
> why limit how the buffer can be used if the original owner no longer
> requires any restrictions?

Because we don't know how it was allocated or what's around it. We stored a 
function that does free already. Do you want to store one that does realloc?

> Anyway, I don't think this is a stretch as long as we don't allow these
> decisions to be made implicitly for the user. For instance, we shouldn't be
> changing the semantics of fromRawData as it exists today, but we could
> enable users to be explicit about what's in the "raw" buffer and how it can
> be used. Say, "Hey QString, here's a UTF-16 string *and* it's already
> null-terminated -- just don't change it" :-)

We have bits available to store that extra information if we want to.

But I don't see the point of mutable foreign data with extra buffer.

What's more, we can easily add a new type if we want to. In fact, let's 
discuss the new headers *without* looking at how ForeignData is implemented. 
Let's just assume that there is such a thing.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
     Intel Sweden AB - Registration Number: 556189-6027
     Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120611/b997cb7f/attachment.sig>


More information about the Development mailing list