[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