[Interest] 64 bit capable QVector

[Alex Malyushytskyy]

>> 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> 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> 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>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/20130903/b78d0675/attachment.html>