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