Not without having "fun" with the need to distinguish allocations of new blocks and reallocations of existing ones, ignore redundant calls to construct() & co. and other things like that. I still think std::allocator's design is flawed and don't see any [good] reason behind the lack of an equivalent of realloc() from C library even if the default implementation worked in the same way as the one used by containers with current std::allocator. On Sep 4, 2013 4:20 AM, "Alex Malyushytskyy" <alexmal...@gmail.com> wrote:
> >> While I don't want to say that STL is a bad thing (it's not bad at all), > the fact that its allocators (and, as a consequence, everything that > uses them) are by design very friendly to memory fragmentation (the > "allocate new block -> copy data -> free old block" makes it completely > impossible even to shrink a block of memory in-place) makes me a bit sad... > > > You meant allocators used by default. > Such problems can be solved by using custom allocators. > > Regards, > Alex > > > > > On Tue, Sep 3, 2013 at 4:55 PM, Constantin Makshin <cmaks...@gmail.com>wrote: > >> While I don't want to say that STL is a bad thing (it's not bad at all), >> the fact that its allocators (and, as a consequence, everything that >> uses them) are by design very friendly to memory fragmentation (the >> "allocate new block -> copy data -> free old block" makes it completely >> impossible even to shrink a block of memory in-place) makes me a bit >> sad... >> >> On 09/04/2013 03:21 AM, Alex Malyushytskyy wrote: >> > Forgot to add, >> > >> > I am not trying to offend performance or any other aspect of Qt >> container. >> > Personally all my code related to displaying data use them. >> > >> > I just believe it is not replacement for STL. >> > >> > Regards, Alex >> > >> > >> > >> > On Tue, Sep 3, 2013 at 4:16 PM, Alex Malyushytskyy < >> alexmal...@gmail.com >> > <mailto:alexmal...@gmail.com>> wrote: >> > >> > >> STL is first of all an interface and there are various >> > implementations, hence your remark about performances does not make >> > sense. >> > >> > It does. All implementations of STL I ever used are clear about >> > their effectiveness, associated types and complexity guarantees. >> > >> > >> Qt containers are far more than "just convenience" classes >> > >> > They are designed to work within Qt only. >> > As far as I understand they never meant to be one of implementation >> > or replacement of STL, thus it is not provided if not counted rare >> > exceptions . >> > Thus these are 'convenience' classes which provide sufficient in >> > terms of data size and performance support of tasks common for Qt. >> > >> > I would add that Qt containers are designed to work with Qt widgets >> > and carry the same limitations. >> > And until it is impossible for example to fill QCombobox the number >> > of items which exceeds capabilities of Qt container, it does not >> > make sense to change the containers. >> > >> > But I disagree with "99.9% of Qt programmers don't need 64 bit >> > containers." statement. >> > It might be true for mobile devices , but it is false even for home >> > desktops. >> > >> > Even if simply counting % of software which have to handle data >> > exceeding 32 bit limit on the home personal computer you will get >> > higher %. >> > Rising of interest in distributed computing including visualization >> > probably does not meant to solve problems with low memory >> requirements. >> > >> > I would expect most of the scientific programs need to support 64 >> > bit containers even though sometimes they might need that support >> > occasionally . >> > >> > Alex >> > >> > >> > >> > On Tue, Sep 3, 2013 at 2:55 PM, Philippe <philw...@gmail.com >> > <mailto:philw...@gmail.com>> wrote: >> > >> > I could easily guess 99.9% of Qt programmers don't need 64 bit >> > containers... Qt containers are far more than "just convenience" >> > classes. >> > >> > STL is first of all an interface and there are various >> > implementations, hence your remark about performances does not >> > make sense. >> > >> > Philippe >> > >> > On Tue, 3 Sep 2013 14:44:58 -0700 >> > Alex Malyushytskyy <alexmal...@gmail.com >> > <mailto:alexmal...@gmail.com>> wrote: >> > >> > >> > This question appears on the mailing lists since Qt 3 at >> least . >> > >> > At one point I was disappointed with having signed int >> > restriction, but then I decided >> > that QT containers are just a convenience classes which are >> > designed to work with either widgets or data of limited size >> > displayed >> > by that widgets. >> > >> > If guaranteed performance is needed you should use STL >> anyway. >> > >> > Regards, >> > Alex >> > >> > >> > On Tue, Sep 3, 2013 at 11:58 AM, Constantin Makshin >> > <cmaks...@gmail.com <mailto:cmaks...@gmail.com>> wrote: >> > >> > Thanks for the explanation, although I still don't >> > appreciate the choice >> > (mostly regarding the size, not signedness). :) >> > >> > On 09/03/2013 10:48 PM, Thiago Macieira wrote: >> > > On terça-feira, 3 de setembro de 2013 22:18:39, >> > Constantin Makshin wrote: >> > >> Could you please explain (or give a link to an >> article >> > or something like >> > >> that) the reasons Qt developers used to choose signed >> > 32-bit integer for >> > >> this purpose? >> > >> Signed 32-bit container sizes, i.e. number of >> elements >> > in a container, >> > >> would be acceptable (considering the equation 'n * >> > sizeof(T)' for the >> > >> amount of memory consumed by the array alone) but why >> > use them to >> > >> calculate and store sizes of allocated memory blocks? >> > > >> > > For two reasons: >> > > >> > > 1) it's signed because we need negative values in >> > several places in the API: >> > > indexOf() returns -1 to indicate a value not found; >> > many of the "from" >> > > parameters can take negative values to indicate >> > counting from the end. So even >> > > if we used 64-bit integers, we'd need the signed >> > version of it. That's the >> > > POSIX ssize_t or the Qt qintptr. >> > > >> > > This also avoids sign-change warnings when you >> > implicitly convert unsigneds to >> > > signed: >> > > -1 + size_t_variable => warning >> > > size_t_variable - 1 => no warning >> > > >> > > 2) it's simply "int" to avoid conversion warnings or >> > ugly code related to the >> > > use of integers larger than int. >> > > >> > > io/qfilesystemiterator_unix.cpp: >> > > size_t maxPathName = >> > ::pathconf(nativePath.constData(), _PC_NAME_MAX); >> > > if (maxPathName == size_t(-1)) >> > > >> > > io/qfsfileengine.cpp: >> > > if (len < 0 || len != qint64(size_t(len))) { >> > > >> > > io/qiodevice.cpp: >> > > qint64 QIODevice::bytesToWrite() const >> > > { >> > > return qint64(0); >> > > } >> > > >> > > return readSoFar ? readSoFar : >> > qint64(-1); >> > > >> > > >> > >> >> > >> On 09/03/2013 08:42 PM, Thiago Macieira wrote: >> > >>> On terça-feira, 3 de setembro de 2013 19:33:47, >> > Mehmet Ipek wrote: >> > >>>> Btw, size >> > >>>> limit of QVector is 2^31 in 64 bit platforms too? >> > >>> >> > >>> Yes. All Qt container classes use a signed int for >> sizes. >> >> >> _______________________________________________ >> Interest mailing list >> Interest@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/interest >> >> > > _______________________________________________ > Interest mailing list > Interest@qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest > >
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
