[Development] Question about the QDataBuffer from src/gui/painting
Gunnar Sletta
gunnar at sletta.org
Mon Oct 26 09:27:57 CET 2015
> On 26 Oct 2015, at 09:56, Marc Mutz <marc.mutz at kdab.com> wrote:
>
> On Monday 26 October 2015 08:20:38 Gunnar Sletta wrote:
>> I don't know if std::vector::erase() and std::vector::clear() can guarantee
>> that the data is not reallocated, even if reserve() has been specified. If
>> that can be guaranteed, removing the class would be fine by me.
>
> Since std::vector::erase(f,l) is guaranteed to preserve iterators and
> references to elements before f, no reallocation can occur (unless f ==
> begin()).
Yeah, but that is kinda the point. I wanted a pool that I could reset and start over again and again and it would only reallocate when a previous pool size was exceeded. Using std::vector::erase() would mean a realloc could happen when the thing is cleared.
>
> For clear(), that's not guaranteed, but is a common optimisation. So much so
> that Scott Meyers has an item about how to shed excess capacity in Effective
> STL.
>
> We could add a testcase:
>
> std::vector<int> v;
> v.resize(1024);
> v.clear();
> QvERIFY(v.capacity() >= 1024);
If that passes on all our compilers, then I'm all for switching.
>
> Thanks,
> Marc
>
> --
> Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> Tel: +49-30-521325470
> KDAB - The Qt Experts
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
More information about the Development
mailing list