[Development] Question about the QDataBuffer from src/gui/painting

[Gunnar Sletta]

The purpose of QDataBuffer is to provide a managed pool of memory that can grow, but does not shrink unless shrunk explicitly. QVector is unusable for this purpose as a resize/clear/append would cause a lot of reallocations for the places where QDataBuffer is used. 

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.

cheers,
Gunnar

> On 25 Oct 2015, at 20:28, Maks Naumov <maksqwe1 at ukr.net> wrote:
> 
> In my small change https://codereview.qt-project.org/#/c/138795/
> Marc Mutz wrote: "This class deserves to die. If you do not believe, copy an instance and you'll see."
> 
> I agree with him, but it will be quite a big change because it is used in many places.
> https://github.com/qtproject/qtbase/search?utf8=%E2%9C%93&q=QDataBuffer
> 
> QDataBuffer is a small version of std::vector with disabilities and the constructor
> with one parameter(array size). It is intended only for the primitive data types.
> https://github.com/qtproject/qtbase/blob/5.6/src/gui/painting/qdatabuffer_p.h
> 
> What do you think is it worth to leave QDataBuffer and update it a little?
> For example to add Q_DECL_NOEXCEPT, Q_DECL_CONSTEXPR ...,
> Type * buffer replace with QScopedPointer with QScopedPointerPodDeleter?
> Or replace QDataBeffer where it is used by the std::vector, of course,
> if it doesn't hurt performance?
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development