[Interest] Strange behaviour of QByteArray reserve/reallocation mechansim

Bernhard private at bernhard-lindner.de
Mon Nov 10 10:58:17 CET 2014


> QByteArray a, b;
> a.reserve(1000);
> a = b;
> 
> There's no way you will ever preserve the reserve(), because that would
> conflict with the implicit sharing.

This is no problem since I don't do this. But I see your point. This surely
limits usability of reserve().

> So in your case you use another operator=. Should that work? Well, if it
does
> I'm sure no one would object. But since another operator= can never hold
> the reserve() promise, I don't really see the point.

I agree.

I still can't understand why clear() could not preserve the previously
reserved space. If clear() would do so, my problems would be solved since I
am using a single reserve() call to reserve the space and then calls of
clear() and append() to collect the data. Does QByteArray have some kind of
reserved-flag?

> reserve() means you can write directly in the byte array data, and then it
> works. I'd suggest that you follow this rule. You can do this by working
> directly on the data() pointer.

So after all I am not supposed to use clear() or operator=() after calling
reserve()? That should be documented. Without that knowledge it obviously is
impossible to use reserve() in a sensible way. 

If you don't have an idea how that could be improved on the code side I
would file a suggestion about extending the documentation a bit.

-- 
Kind Regards
Bernhard Lindner





More information about the Interest mailing list