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 <[email protected]> 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 > [email protected] > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
