>> 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
