[Development] Changing container privates again
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
> 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);
> 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: not available
Size: 190 bytes
Desc: This is a digitally signed message part.
Url : http://lists.qt-project.org/pipermail/development/attachments/20120611/b997cb7f/attachment.bin
More information about the Development