[Interest] 64 bit capable QVector
Constantin Makshin
cmakshin at gmail.com
Wed Sep 4 05:31:44 CEST 2013
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" <alexmalvtk at 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 <cmakshin at 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 <
>> alexmalvtk at gmail.com
>> > <mailto:alexmalvtk at 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 <philwave at gmail.com
>> > <mailto:philwave at 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 <alexmalvtk at gmail.com
>> > <mailto:alexmalvtk at 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
>> > <cmakshin at gmail.com <mailto:cmakshin at 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 at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest
>>
>>
>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20130904/d186dbb4/attachment.html>
More information about the Interest
mailing list