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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development