Thiago Macieira wrote:
> Ok, I see. You're splitting the deleter from the immutability. Since we do
> have a flag for immutability, we can serve WebKit's use-case, but also do in-
> place modifications.
Yes.
> I find that a nice use-case.
>
> You're going further and suggesting that we could also tell the container how
> much memory was reserved externally, so it could grow around without
> reallocating. I think that's your reason for keeping the alloc member
> together
> with the notify function.
Yes.
> 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."
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?
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" :-)
Cheers,
João
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
